Community Governance

The Community Governance process executes admin-level actions of the Root Policy contract by democratic decision. This allows for modification of the underlying smart contracts that run the Eco Protocol. The modifications are approved via a phased voting process, where proposals are submitted to the protocol, and voted on if they reach enough staked support. The Community Governance process can also be used for a variety of other actions, like electing Trustees, distributing the Community Treasury, and more. A flowchart for Community Governance is below.

Phases of Community Governance

1. Community Governance first starts with the Proposal Phase, where proposals are submitted to the Eco Protocol, and ECO and ECOx holders can choose to stake support for any number of the proposals using their voting power.

2. Once a support threshold is reached for one of the proposals (15%), the Voting Phase is deployed using a Supervisor Function. In the Voting Phase, ECO and ECOx holders vote "For" or "Against" the proposal.

3. If the vote passes — meaning a majority of participating voting power votes "For," or if 50% of all system voting power votes for the proposal, the proposal is executed in the Vote Enactment phase. Enacting the vote comes with a 1-day delay if the vote is a plurality, and is instant with a 50% majority.

Generational Voting Power

Voting Power is tracked on a generational basis, with voting power snapshots corresponding to each address's relative voting power at the generation change. A couple of notes about voting power:

• In aggregate, ECO and ECOx have the same total voting power at launch.

  • ECO has 0.1 voting power per unit and a 10 billion initial supply. *

  • ECOx has 1 voting power per unit and 1 billion initial supply. *

• Over time, as the number of ECO grow (while the number of ECOx remains static or decreases), the voting power of ECO holders will grow relative to ECOx holders. This presumes an overall inflationary monetary policy for ECO.

• Voting with snapshotted voting power does not require the lockup or staking of any tokens. Users can still transact with ECO and ECOx and maintain the same voting power they started with at the start of the generation.

• The total voting power in a generation is the sum of all potential voting power on the network (including unstaked ECOx).

• To check an address's voting power, call the votingPower(address _who, uint256 _blockNumber) function in the PolicyProposals.sol or PolicyVotes.sol contracts. To find the current _blockNumber read the blockNumber variable from either contract.

• To check total voting power for a generation, call the totalVotingPower(uint256 _blockNumber) function in the PolicyProposals.sol or PolicyVotes.sol contracts. The _blockNumber is the block number when the generation started, and is found by reading the blockNumber variable from either contract.

*In the contracts, voting power is stored as a uint256 number with one decimal. Therefore, when reading the voting power per ECO from the contract, it is displayed as 1, and the voting power per ECOx is displayed as 10.