This article provides a high-level description of the major parts of the Cere Governance system - Version 1.0 (v1). To learn how to participate in Cere Governance, check our Cere Governance Guide for detailed instructions. Check the Governance Glossary for additional details.
Cere Network uses a governance system that allows it to evolve gracefully overtime at the ultimate behest of its assembled stakeholders. The stated goal is to ensure that the majority of the stake can always command the network. Cere Governance v1 is based on 💜 Polkadot OpenGov v1.
Cere Network brings together various novel mechanisms, including an amorphous (abstract) form of state-transition function stored on-chain defined in a platform-agnostic language (i.e. WebAssembly). It also allows for several on-chain voting mechanisms, such as referenda with the novel concept of Adaptive Quorum Biasing and batch approval voting. All changes to the protocol must be agreed upon by stake-weighted referenda.
To make any changes to the network, the idea is to compose active token holders and the council together to administrate a network upgrade decision. No matter whether the proposal is proposed by the public (token holders) or the Council, it finally will have to go through a vote on a referendum to let all holders, weighted by stake, make the decision.
There are different paths for submitting a proposal that can potentially be voted on as a referendum. The Public, and the Council.
The public (i.e. token holders) can submit a proposal that gets added to the proposal queue. Here, proposals are endorsed, and the one that gets the most support will climb to the top of the queue. When it is time, the proposal at the top of the queue will become a Public Referendum. For instance, the proposal with 11 endorsements is shown at the top of the queue in the figure, which is ready to become a referendum.
The public can also submit a treasury proposal, which must be evaluated by the Council through a motion. If the Council motion passes, the treasury proposal can be directly executed or go to the external queue, which will be voted on through a Council Referendum. See the figure's green horizontal path from the Public (green) to the Council (yellow). Treasury proposals and Council proposals can be directly executed (horizontal yellow arrows) or go to the external queue, where they will become a referendum.
Note that the external queue always consists of a single proposal. A proposal in the external queue can be fast-tracked by the Technical Committee. The fast track can contain as many proposals as possible (also called emergency proposals) that can be voted on simultaneously with with the referenda introduced either by the Council or the Public.
The Council can also submit proposals that will end up in the external queue. Voting on Council and Public proposals subject to an alternating timetable, shown in the figure as the "on" and "off" toggles on the external and proposal queues. In this example, the Public proposal will be voted on together with the fast-tracked Council Proposal. Voting on non-fast-tracked Council Proposals will be blocked until the alternating timetable switches the toggles, which stops Public proposals from becoming a referenda.
Referenda will follow an adaptive quorum biasing mechanism for deciding whether they get enacted, and if they do, they will be executed after an enactment period.
Token holders can delegate their votes (with a conviction multiplier) to another account belonging to a trusted entity voting on their behalf.
Referenda can be started in different ways: