Moonbeam has released OpenGov on Moonriver as part of runtime 2100 after the passing of referendum 128. The OpenGov rollout on Moonbeam will begin with this Moonriver implementation for community feedback. Future referenda will be held to allow the community to decide how OpenGov will evolve and move to Moonbeam.
OpenGov on Moonriver
Moonriver and Moonbeam have adopted an on-chain governance process from launch, and continue to use community feedback to strengthen the process. This is where OpenGov comes in. Please note that this is the first implementation of OpenGov on Moonriver. The governance changes will be battle-tested and adjusted (through governance) as required before OpenGov is considered for Moonbeam implementation. Expect OpenGov to evolve over time as the community proposes and votes on adjustments.
Governance sets the Polkadot ecosystem apart from most other chains that do not provide an opportunity for the community to participate in decision-making on-chain. Decentralization is a core part of Web3 that Moonriver and Moonbeam work to uphold in addition to security and scalability as Kusama and Polkadot parachains, respectively.
Recently Kusama has implemented the second generation of governance, OpenGov. Formerly referred to as Gov2, OpenGov is in the process of moving to Polkadot if it is approved by the community.
For a detailed outline of OpenGov on Polkadot, please refer to OpenGov: What is Polkadot Gov2. Each parachain has autonomy over its governance process, and the Parachains may choose to implement any part of OpenGov, or not.
OpenGov strives to be more inclusive, transparent, and secure. Any MOVR token holder can propose changes for the network, and all holders can vote. All referenda, including proposals and voting results, are visible on-chain, and decisions are made by majority vote. Deciding referenda in OpenGov is based on a curve configured to ensure that the majority, defined by a percentage of yes vs. no votes prevails.
OpenGov on Moonriver has been discussed in the Community Forum, and an off-chain signal vote was taken to document the communities opinions and suggestions. The governance process and referenda resulted in the approval of the Moonriver OpenGov proposal. An outline of OpenGov on Moonriver is provided below. The parameters are expected to adjust to community feedback over time.
Origins and Tracks in Moonriver OpenGov
In version one of governance, most proposals were processed in the same way. Some proposals could be fast-tracked and the Council had some different voting standards. With OpenGov, the nature of the proposal determines the amount of time and participation required to approve or reject proposals. This streaming ensures the governance process can help support the growth and needs of the community.
OpenGov on Moonriver uses origins and tracks to organize proposals into streams. Each origin has a specified number of tracks that determine the number of referenda that can happen at the same time and the parameters for approval.
Think of origins as the level of permission needed for a change to be implemented. The โdeepestโ origin is called Root Origin, which is where the most significant changes to the network can happen.
The various tracks each serve a specific purpose and have different requirements for capacity, decision deposit, preparation, confirmation, and enactment periods. A number of factors have been taken into consideration in determining these requirements. These parameters will be audited after deployment and adjusted as required via democracy.
Capacity refers to the number of referenda that can happen at the same time. Larger capacities prevent spam attacks from clogging the tracks, and smaller capacities make it simpler for the community to consider the referenda since there are fewer happening at one time.
Decision deposit amounts are meant to deter malicious proposals. Slashing means that malicious proposals will not be refunded, so a higher deposit amount means a greater consequence for bad actors. For decentralization, it was also taken into consideration that community members with fewer MOVR should be able to make proposals. Participation in the Community Forum is free, all deposit tokens are returned whether a proposal is approved or rejected (unless it is deemed malicious).
The lead-in preparation period is the time provided for the community to discuss a proposal and act on bad proposals.
The decision and confirmation periods are balanced to prevent โsnipingโ (a large vote made at the last minute to sway results) with longer required durations, and shorter times to allow for efficient execution.
Through the duration of a referendum, the requirements for approval adjust. The timelines and requirements, as well as descriptions and examples for all Moonriver tracks, are outlined below.
Description, Parameters, and Examples of Moonriver OpenGov
| Track | Description | Parameters | Curve | Referendum Examples |
|---|---|---|---|---|
| Root | Track with highest privilege | Decision period 14 days Confirmation period Minimum Enactment period Capacity Decision deposit Preparation |
Approval: RECIPROCAL 0 days โ 100% 4 days โ 80% 14 days โ 50% Support: |
Runtime upgrades, OpenGov technical committee management |
| Whitelist | Track where proposals should be whitelisted by the OpenGov technical committee before being dispatched | Decision period 14 days Confirmation period Minimum Enactment period Capacity Decision deposit Preparation |
Approval: RECIPROCAL 0 days โ 100% 1 day โ 96% 14 days โ 50% Support: |
Fast-tracked operations |
| General Admin | Track designed for general on-chain decisions | Decision period 14 days Confirmation period Minimum Enactment period Capacity Decision deposit Preparation |
Approval: RECIPROCAL 0 days โ 100% 4 days โ 80% 14 days โ 50% Support: |
XCM fees, orbiter program, parachain staking, registrar |
| Emergency Canceler | Track used for cancelation of wrong referenda. Deposit refunded. | Decision period 14 daysConfirmation period 3 hoursMinimum Enactment period 10 minutes Capacity Decision deposit Preparation |
Approval: RECIPROCAL 0 days โ 100% 1 day โ 96% 14 days โ 50%Support: RECIPROCAL 0 days โ 10% 1 day โ 1% 14 days โ 0% |
Wrong referenda |
| Emergency Killer | Track used for killing bad referenda. Deposit slashed. | Decision period 14 daysConfirmation period 3 hoursMinimum Enactment period 10 minutes Capacity Decision deposit Preparation |
Approval: RECIPROCAL 0 days โ 100% 1 day โ 96% 14 days โ 50%Support: RECIPROCAL 0 days โ 10% 1 day โ 1% 14 days โ 0% |
Bad referenda |
For detailed explanations about how approval and support are calculated, please view the proposal, or OpenGov: What is Polkadot Gov2.
Moonriver OpenGov Process Overview
Moonriver OpenGov marks the first integration of an updated governance process. Modeled on Polkadot OpenGov currently live on Kusama, Moonriver OpenGov is expected to evolve and adjust as the community needs grow and change.
Proposals
Token holders propose network changes on Moonriver using the off-chain Community Forum. This is done by navigating to the forum, then the Governance discussion category, and selecting Democracy Proposal where instructions and support are provided to begin the process.
In the Community Forum, community members ask questions and discuss proposals, and can submit polls to gauge sentiment.
A signal vote is taken to record the sentiment.
Once the deposit is made and there is space available on the appropriate track, a referendum moves to on-chain voting to begin the deciding period. Community members use their MOVR tokens to vote via Polkassembly or Polkadot.js.
When the criteria for approval and support are met, the referendum is confirmed and moves into the enactment period where preparations are made for the implementation of the changes. If there are not enough โayeโ votes during the set length of the deciding period, a proposal is rejected.
Vote Delegation
Moonriver governance version two brings multirole delegation. This feature allows token holders to delegate their tokens for voting purposes to other voters, based on tracks.
Vote delegation was an option before OpenGov, but with multirole delegation, voting power for technology upgrades in the Root origin might be delegated to an expert while voting for the general admin track could be maintained by the token owner, or delegated to a different party.
Tokens locked in conviction votes, even through delegation, do not leave their home wallet. Voters using delegation can change delegates or take back their voting power at any time.
Safeguards
As the network and its decision-making process evolve, safeguards remain in place. Bad or malicious proposals can be canceled to protect the network, and critical technical upgrades or changes can be fast-tracked using the Whitelist track.
On Moonriver there are two Cancelation Origins, one for use against referenda that contain an unforeseen problem called Emergency Canceler, and one for bad referenda intending to harm the network called Emergency Killer.
Cancelation must be voted on by the network to execute. Cancelation proposals are faster than a typical proposal because they must be decided before the enactment of the proposal they seek to cancel, but follow the same process as other referenda.
If a wrong proposal is in referendum, an Emergency Canceler referendum can be held to end the wrong proposal. If a bad referendum is up, the Emergency Killer track will host a referendum to vote to end the bad referendum.
The Moonriver OpenGov Technical Committee has the power to whitelist a proposal that lands on the Whitelist track. A proposal landing on the whitelist track will behave like any other proposal but when it should be enacted, if it was not whitelisted by the technical committee, it will fail. This is used to safeguard the network in the case that a proposal moves to referendum that is not technically sound, or there is an immediate need for a network upgrade that must be fast-tracked.
OpenGov Technical Committee
In Polkadot OpenGov, the Technical Committee is dissolved in favor of the newly formed Polkadot Fellowship, the Moonriver OpenGov Technical Committee remains. No Moonriver Fellowship will be formed at this time.
The OpenGov Technical Committee is introduced as part of the first rollout of OpenGov on Moonriver. The Technical Committee never had hard power over the network and it still does not. The OpenGov Technical Committee is made up of members with technical knowledge of Moonriver and Moonbeam to help make well-informed decisions on a technical basis. The technical committee members can be added or removed through governance in the Root track as needed.
While still subject to governance, the idea behind the Whitelist track is that it will have different parameters to make it faster for proposals to pass. The Whitelist Track parameters including approval, support, and voting are determined by the Moonbeam stakeholders and cannot be changed by the OpenGov Technical Committee. Members can vote on whether to whitelist any proposal.
Members of the TC are added or removed from the TC through governance in the Root Track. The composition, size, and process for being a Member of the OpenGov Technical Committee may evolve, subject to governance, as OpenGov matures and the community learns more from experience.
Here are the names of prospective OpenGov Technical Committee members that will be put up for vote as part of runtime 2200. These community members were chosen because of their technical knowledge of Moonriver and Moonbeam and their dedication to the network(s).
- Alan Sapede (@Alan_PureStake) – VP Engineering at PureStake. Over 20 years programming experience. Has deep technical and hands-on knowledge of the Moonbeam protocol. Is an active contributor to the Moonbeam codebase and has a large amount of Substrate and Polkadot expertise.
- Gorka Apecechea (@girazoki) – Research Developer. Developer actively working on the Moonbeam protocol with specific expertise in relay chain interaction, XCM, and other Moonbeam subsystems. PhD in Computer Science / Cryptography.
- Aaron Evans (@aaron.mbf ) – Director of the Moonbeam Foundation. Engineering Executive background. Has 20 years of experience in software engineering and technical leadership roles. Has been working with Moonbeam and ecosystem projects since 2021.
- Sicco Naets (@sicco-moonbeam) – Director of the Moonbeam Foundation. Software Engineering Leadership background. Has led teams implementing and designing complex software for over 20 years.
- Linkou (@linkou) – Runs the MoonEntropy collator on Moonriver and Moonbeam. IT & Security background and is engaged in governance votes on the Moonriver and Moonbeam networks.
- Boony (@Boony) – Runs the MoonWorld collator on Moonbeam network. IT background and engaged in governance votes on the Moonbeam network.
- Jim Farley (@Jim_CertHum) – Runs the CertHum Collator on Moonriver and Moonbeam. Setup the independent collator coalition where collators support each other to stay in the active set. Also providing a snapshot service as a public good to the network, so collators can sync new nodes faster with known good images.
- Blackk Magiik (@blackk_magiik) – Runs the Paradoxx collator on the Moonriver/Moonbase networks. Extensive network security engineering and architecture background. Active in Discord and governance discussions.
- Tim Baldwin (@tdb) – VP Engineering at PureStakeย – Technical Lead for Dapps and Infrastructure. Familiar with Moonbeam APIs, SDKs, and development applications on Moonbeam. Has been working with Moonbeam since 2020. Over 25 years of experience in software engineering and IT.
