Policy Framework
To support the protocol infrastructure and its governance, Eco creates a network of labels that allow contracts to look each other up and give privileged access to one another without hard coding an address. This supports rote actions such as incrementing the Generation, as well as special ones like upgrades of the system. This is almost entirely an automation path, with no user action going through the policy system with the exception of the final result of Community Governance.
Root Policy Contract
The Eco Protocol manages most of the contracts in the system from a "Root Policy Contract" (Policy.sol in the codebase), which manages protocol upgrades, holds protocol funds, writes to the ERC1820 registry, and manages the lookups for the other contracts. It is colloquially referred to in this documentation as the Root Policy contract and also referred to as the Community Treasury, as it holds the funds allocated to the protocol for distribution by the community.
ERC1820 Registry
An important part of the Policy Framework is that contracts do not use each others' addresses as a source of truth when looking up other parts of the system to interact with them. Instead, all the important contracts are registered to ERC1820 which acts as a registry and repository where functionality can be given constant identifiers, even if the actual contract is changed out underneath. This is critical for simplifying Eco's full system upgradability as well as allowing for using a Clone → Register → Use → Discard pattern for reused contract flows, as described in the next section. Only a very small number of contracts have the ability to edit the ERC1820 registry.
Some of the core contracts (ECO.sol and ECOx.sol, for example), are hosted behind proxies with static proxy addresses. This may make it easier for developers trying to interface with the contracts.
Cloning
To facilitate the many repeating processes in Eco's system, many contracts exist as templates for these recurring actions. These templates exist at static addresses in the storage of the contract that clones them, and they are cloned each generation (or when needed) to facilitate the actions of that generation. The clone is registered to ERC1820 so that it can be found and recognized as authorized, not only by the other contracts but by any external user interface.
Most of the functionality of the template contract either requires the privileges of being registered in the policy system or some kind of additional setup that is performed each cloning. While users could potentially interact with a template contract, they will, at worst, be able to write to its store which is not copied when creating the clone. When the function of the clone is complete, it is left in an inert state and is replaced by the next clone when that is created.
The cloning system uses EIP-1167, which is a simple and cheap way to clone contract functionality in an immutable method. The cloning itself is done through the code in PolicedUtils.sol which utilizes the implementation of EIP-1167 called CloneFactory which is taken from this repository.
The following core contracts are cloned each generation:
PolicyProposals.sol
PolicyVotes.sol
CurrencyGovernance.sol
RootHashProposal.sol*
RandomInflation.sol*
Lockup.sol*
VDFVerifier.sol*
*dependent on Monetary Governance decision.
For more information about the cloning system, see the GitHub Repository.
Proxy Framework
The proxy framework allows contracts to be upgraded while keeping their state intact and maintaining accessibility without the need to publicize a new address. The following core contracts are proxied:
Policy.sol
ECO.sol
ECOx.sol
ECOxStaking.sol
TimedPolicies.sol
CurrencyTimer.sol
TrustedNodes.sol
For more information about the proxy system, see the GitHub Repository.
Finding Active Contracts
Due to the dynamic nature of the ERC1820 registry, contracts frequently look up the active contracts in the registry when performing actions. Contracts typically use the policyFor(bytes32 _interfaceIdentifierHash) function in the Root Policy contract to do this. The _interfaceIdentifierHash is a keccak256 hash of the identifier in the ERC1820 lookup contract.
For example, to find the active contract for the ECOx token, one would call keccak256("ECOx") and use the 32-byte output as the input for the PolicyFor(bytes32 _interfaceIdentifierHash) function of the Root Policy Contract. Not every contract in the system has this kind of identifier. In order to see those too, check out the PolicedUtils.sol contract.
Last updated