Ideation: Trustless Notary Design Space + Guidelines

This document outlines an opportunity for developers within the FVM ecosystem to create a smart contract project that enables the issuance of datacap in the Filecoin network. The Fil+ team has included specific requirements that we recommend developers follow when creating smart contracts to achieve this goal. The purpose of these requirements is not to limit creativity but rather to ensure that the resulting smart contract can easily integrate with the current Fil+ community.

Trustless notary design space

We define a “Trustless notary” as any program that issues datacap allocations to clients based on the logic specified in a smart contract on the FVM. At a high level, this logic determines the following:

• Whether a client should receive datacap
• How much datacap should be allocated to a client
• How FIL should be allocated if it enters the smart contract

After the deployment of the smart contract, the logic should only be upgraded through a governance process.

Note: When referring to a “smart contract,” we are referring to possibly a set of smart contracts, as projects within the FVM typically consist of multiple contracts. “Upgrading” the smart contract would involve having a proxy smart contract point to an updated version of the smart contract(s).

Trustless Notary vs Normal Notary

When comparing a trustless notary to a normal notary, the following differences are notable:

• The logic of a Trustless notary is clearly defined in the smart contract, allowing anyone to read and understand the process by which clients can receive datacap. However, if changes need to be made to this logic, there may be additional engineering and governance costs to make the smart contract adaptable.
• Smart contracts enable clients and notaries to stake Fil in a transparent manner, with the contract specifying exactly how the staked Fil will be used. This can help to keep service providers, notaries, and clients be more accountable and prevent collusion between parties.
• Governance can be structured to change the business logic of the smart contract, requiring multiple parties to agree before any changes are made to how datacap is distributed. This can help prevent collusion and ensure fairness.
• Trustless notaries are much more scalable than normal notaries, as there is less blockage on waiting for a human to approve a certain action. Onchain transactions are triggered instantly as the logic dictates.

Recommended guidelines

These are the recommended guidelines suggested by the Fil+ team for creating a Trustless notary. While some may feel that these guidelines go against the decentralized ethos, given the nascent state of Fil+, we believe some form of supervision is necessary to ensure the integrity of the system. The guidelines are as follows:

• The owner of the Trustless notary should undergo notary elections similar to other notaries and demonstrate in their application why the proposed logic and governance process to change that logic are sufficiently fair.
• Once in production, there should be at least x other notaries who “own” the private keys to upgrade the logic of the smart contract. This means that multiple stakeholders must agree before a proxy contract points to a new upgraded contract.
• Like other notaries, a Trustless notary must be granted datacap by the root key holders and is subject to the same penalties as other notaries. The root key holders can remove datacap from the smart contract.
• The Trustless notary must have clear documentation, and its code must be open-source for anyone to view.
• The Trustless notary should include a “kill switch” that instantly pauses all operations of the contract.