The Celo mainnet recently launched with over 50 validating entities participating after a successful multi-stage incentivized testnet competition. Celo is an open platform seeking to give access to decentralized financial tools to anyone with a mobile phone. Part of that vision is a sophisticated on-chain governance process that decentralizes power over protocol features and parameters, including Celo’s stablecoin stability mechanism. This post will provide an overview over the currently implemented governance mechanism that was already used to activate transfers and staking rewards on the network.
Any Celo account can submit a proposal to change features or parameters on Celo by sending a transaction containing all the necessary data such as a title and link to the proposal description together with a deposit of currently 100 Celo, the network’s native token, to the network. Once issued on-chain, proposals enter a queue and Celo holders can signal their belief that this proposal should be voted on by the entire network for up to 28 days [1]. Locked Celo tokens can simultaneously partake in staking with validator groups, as well as signaling and voting in governance.
Every day, three proposals with the highest amount of upvotes, measured in locked Celo signaled by token holders, can leave the proposal queue and move into the referendum stage in which the entire network will decide on whether the proposal should be implemented.
However, the referendum stage is not initiated automatically. There exists a multi-signature address that must approve the promotion of proposals to the referendum stage (“the approver”). This step is an extra protection to quality check proposals before they are voted on by Celo holders. At launch, the approver is controlled by the Celo Foundation, the plan is to decentralize it to be controlled by a DAO.
Once approved, proposals enter a two day referendum stage [2]. During this phase, Celo holders are able to vote “Yes”, “No”, or “Abstain” on each proposal. Votes are weighted by the accounts locked Celo balance. There is currently no delegated voting contract meaning every Celo account is responsible to vote themselves. When a proposal enters the referendum phase, the deposited proposal collateral can be reclaimed by the proposer.
At the end of the referendum stage, the blockchain executes a tally of votes to determine whether the proposal has met the passing criteria to be implemented on-chain. This passing criteria consists of two factors:
If the tally at the end of phase 2 concludes that the proposal has been accepted, there is a final stage in which the proposal needs to be executed on-chain. This can be done by any Celo account by issuing a special transaction on-chain. This transaction then upgrades the protocol code meaning the change is implemented. Should no Celo account issue the execution transaction for three days, the proposal will automatically be rejected.
Finally, Celo’s governance protocol also specifies a different upgrade path for hotfixes like urgent security patches. For such upgrades, a quorum of validators [5] and the approver need to approve the hash of the hotfix proposal to execute updates immediately. Additionally, upgrades that require a hard fork, such as changes to the underlying consensus protocol, will set a “Minimum Client Version” parameter on the chain to inform nodes about the software version required to correctly operate on the network.
At Chorus One we seek to empower token holders to shape the networks they are invested in. Our staking platform Anthem will soon support Celo and allow Celo holders to stake, vote, and get access to portfolio data including staking rewards and transaction history.
Chorus One offers staking on Celo. Support our work by voting for our validator group and earn rewards knowing your tokens are staking on infrastructure that has been securing millions of dollars for more than a year. Visit https://chorus.one/networks/celo to learn more.
Thanks to zviad from Wotrust and Tim Moreton from C Labs for clarifying a bunch of the questions I had writing this post.
Governance Forum: https://forum.celo.org/c/governance/12
Governance Proposals Statistics: https://thecelo.com
Governance Documentation: https://docs.celo.org/celo-codebase/protocol/governance
CLI Instructions: https://docs.celo.org/celo-gold-holder-guide/voting-governance
[1] In practice Celo utilizes epochs to structure time. Every epoch consists of a certain amount of blocks targeting to correspond to a day in human time.
[2] An extension of this parameter to 2 weeks is already in discussion.
[3] Source: mainnet adaptive quorum code (formula)
[4] Proposals can even pass when the quorum was not met. This can take place when the ratio of “Yes” votes exceeds the constitutional threshold after counting votes that were missing to reach the quorum as “No” votes, i.e. if
Yes / (Yes+No+Votes Missing to Reach Quorum) > Constitutional Voting Threshold.
(sources: mainnet constitution code (parameter values), proposals contract code)
[5] ⅔ + 1 of all elected validator nodes.
Originally published at https://blog.chorus.one on May 20, 2020.
