Interface for scheduling, executing and challenging contract executions based on off-chain approval
ERC-3000 presents a basic on-chain spec for contracts to optimistically enact governance decisions made off-chain.
The standard is opinionated in defining the 6 entrypoint functions to contracts supporting the standard. But it allows for any sort of resolver mechanism for the challenge/response games characteristic of optimistic contracts.
While the authors currently believe resolving challenges using a subjective oracle is the right tradeoff, the standard has been designed such that changing to another mechanism is possible (a deterministic resolver like Optimism's OVM uses), even allowing to hot-swap it in the same live instance.
Some data structures are defined which are later used in the standard interfaces:
Given the data structures above, by taking advantage of the Solidity ABI encoder v2, we define four required functions and two optional functions as the interface for contracts to comply with ERC-3000.
All standard functions are expected to revert (whether to include error messages/revert reasons as part of the standard is yet to be determined) when pre-conditions are not met or an unexpected error occurs. On success, each function must emit its associated event once and only once.
The authors believe that it is very important that this standard leaves the other open to any resolver mechanism to be implemented and adopted.
That's why a lot of the function and variable names were left intentionally bogus to be compatible with future resolvers without changing the standard.
ERC-3000 should be seen as a public good of top of which public infrastrastructure will be built, being way more important than any particular implementation or the interests of specific companies or projects.
The standard allows for the resolver for challenges to be configured, and even have different resolvers for coexisting scheduled payloads. Choosing the right resolver requires making the right tradeoff between security, time to finality, implementation complexity, and external dependencies.
Using a subjective oracle as resolver has its risks, since security depends on the crypto-economic properties of the system. For an analysis of crypto-economic considerations of Aragon Court, you can check the following doc.
On the other hand, implementing a deterministic resolver is prone to dangerous bugs given its complexity, and will rely on a specific version of the off-chain protocol, which could rapidly evolve while the standard matures and gets adopted.
Copyright and related rights waived via CC0.