Skip to content

Governance on Moonbeam

Introduction

The goal of Moonbeam’s governance mechanism is to advance the protocol according to the desires of the community. In that shared mission, the governance process seeks to include all token holders. Any and all changes to the protocol must go through a referendum so that all token holders, weighted by stake, can have input on the decision.

Governance forums like the Moonbeam Community Forum and Polkassembly enable open discussion and allow proposals to be refined based on community input. Autonomous enactments and forkless upgrades unite the community towards a shared mission to advance the protocol.

With the rollout of OpenGov (originally referred to as Gov2), the second phase of governance in Polkadot, several modifications have been introduced to the governance process. You can read the OpenGov: What is Polkadot Gov2 blog post, which provides an overview of all of the changes made in OpenGov.

As of runtime 2400, all Moonbeam networks use OpenGov as their governance system.

Principles

Guiding "soft" principles for engagement with Moonbeam's governance process include:

  • Being inclusive to token holders that want to engage with Moonbeam and that are affected by governance decisions
  • Favoring token holder engagement, even with views contrary to our own, versus a lack of engagement
  • A commitment to openness and transparency in the decision-making process
  • Working to keep the greater good of the network ahead of any personal gain
  • Acting at all times as a moral agent that considers the consequences of action (or inaction) from a moral standpoint
  • Being patient and generous in our interactions with other token holders, but not tolerating abusive or destructive language, actions, and behavior, and abiding by Moonbeam’s Code of Conduct

These points were heavily inspired by Vlad Zamfir’s writings on governance. Refer to his articles, especially the How to Participate in Blockchain Governance in Good Faith (and with Good Manners) Medium article.

On-Chain Governance Mechanics

The "hard" governance process for Moonbeam will be driven by an on-chain process that allows the majority of tokens on the network to determine the outcomes of key decisions around the network. These decision points come in the form of stake-weighted voting on proposed referenda.

Some of the main components of this governance model include:

  • Referenda — a stake-based voting scheme where each referendum is tied to a specific proposal for a change to the Moonbeam system including values for key parameters, code upgrades, or changes to the governance system itself
  • Voting — referendum will be voted on by token holders on a stake-weighted basis. Referenda which pass are subject to delayed enactment such that people that disagree with the direction of the decision have time to exit the network
  • Council & Technical Committee Governance V1 — a group of community members who have special voting rights within the system. With the deprecation and removal of Governance v1, both of these committees were dissolved as of the runtime 2800 release
  • OpenGov Technical Committee — a group of community members who can add certain proposals to the Whitelisted Track

For more details on how these Substrate frame pallets implement on-chain governance, you can checkout the Walkthrough of Polkadot’s Governance blog post and the Polkadot Governance Wiki.

Governance v2: OpenGov

This section will cover everything you need to know about OpenGov on Moonbeam.

General Definitions

  • Origin - an authorization-based dispatch source for an operation, which is used to determine the Track that a referendum is posted under
  • Track - an Origin-specific pipeline that outlines the life cycle of proposals. Currently, there are five Tracks:

    Origin Track Description Referendum Examples
    Root Highest privilege Runtime upgrades, Technical Committee management
    Whitelisted Proposals to be whitelisted by the Technical Committee before getting dispatched Fast-tracked operations
    General Admin For general on-chain decisions Changes to XCM fees, Orbiter program, Staking parameters, Registrars
    Emergency Canceller For cancellation of a referendum. Decision Deposit is refunded Wrongly constructed referendum
    Emergency Killer For killing of bad/malicious referendum. Decision Deposit is slashed Malicious referendum
    Fast General Admin For faster general on-chain decisions HRMP channel management

    Please refer to the Governance Parameters section for more information

  • Decide Period - token holders continue to vote on the referendum. If a referendum does not pass by the end of the period, it will be rejected, and the Decision Deposit will be refunded

  • Confirm Period - a period of time within the Decide Period where the referendum needs to have maintained enough Approval and Support to be approved and move to the Enactment Period
  • Enactment Period - a specified time, which is defined at the time the proposal was created, that an approved referendum waits before it can be dispatched. There is a minimum amount of time for each Track

Governance Parameters

Variable Value
Preimage base deposit 500 GLMR
Preimage deposit per byte 0.01 GLMR
Proposal Submission Deposit 1000 GLMR
Variable Value
Preimage base deposit 5 MOVR
Preimage deposit per byte 0.0001 MOVR
Proposal Submission Deposit 10 MOVR
Variable Value
Preimage base deposit 5 DEV
Preimage deposit per byte 0.0001 DEV
Proposal Submission Deposit 10 DEV

General Parameters by Track

Track Track ID Capacity Decision
Deposit
Root 0 5 proposals 2000000 GLMR
Whitelisted 1 100 proposals 200000 GLMR
General Admin 2 10 proposals 10000 GLMR
Emergency
Canceller
3 20 proposals 200000 GLMR
Emergency
Killer
4 100 proposals 400000 GLMR
Fast General Admin 5 10 proposals 10000 GLMR
Track Track ID Capacity Decision
Deposit
Root 0 5 proposals 100000 MOVR
Whitelisted 1 100 proposals 10000 MOVR
General Admin 2 10 proposals 500 MOVR
Emergency
Canceller
3 20 proposals 10000 MOVR
Emergency
Killer
4 100 proposals 20000 MOVR
Fast General Admin 5 10 proposals 500 MOVR
Track Track ID Capacity Decision
Deposit
Root 0 5 proposals 100000 DEV
Whitelisted 1 100 proposals 10000 DEV
General Admin 2 10 proposals 500 DEV
Emergency
Canceller
3 20 proposals 10000 DEV
Emergency
Killer
4 100 proposals 20000 DEV
Fast General Admin 5 10 proposals 500 DEV

Period Parameters by Track

Track Prepare
Period
Decide
Period
Confirm
Period
Minimum
Enactment Period
Root 7200 blocks
(1 day)
100800 blocks
(14 days)
7200 blocks
(1 day)
7200 blocks
(1 day)
Whitelisted 50 blocks
(10 minutes)
100800 blocks
(14 days)
50 blocks
(10 minutes)
150 blocks
(30 minutes)
General Admin 300 blocks
(1 hour)
100800 blocks
(14 days)
7200 blocks
(1 day)
7200 blocks
(1 day)
Emergency
Canceller
300 blocks
(1 hour)
100800 blocks
(14 days)
900 blocks
(3 hours)
50 blocks
(10 minutes)
Emergency
Killer
300 blocks
(1 hour)
100800 blocks
(14 days)
900 blocks
(3 hours)
50 blocks
(10 minutes)
Fast General Admin 300 blocks
(1 hour)
100800 blocks
(14 days)
900 blocks
(3 hours)
50 blocks
(10 minutes)
Track Prepare
Period
Decide
Period
Confirm
Period
Minimum
Enactment Period
Root 7200 blocks
(1 day)
100800 blocks
(14 days)
7200 blocks
(1 day)
7200 blocks
(1 day)
Whitelisted 50 blocks
(10 minutes)
100800 blocks
(14 days)
50 blocks
(10 minutes)
150 blocks
(30 minutes)
General Admin 300 blocks
(1 hour)
100800 blocks
(14 days)
7200 blocks
(1 day)
7200 blocks
(1 day)
Emergency
Canceller
300 blocks
(1 hour)
100800 blocks
(14 days)
900 blocks
(3 hours)
50 blocks
(10 minutes)
Emergency
Killer
300 blocks
(1 hour)
100800 blocks
(14 days)
900 blocks
(3 hours)
50 blocks
(10 minutes)
Fast General Admin 300 blocks
(1 hour)
100800 blocks
(14 days)
900 blocks
(3 hours)
50 blocks
(10 minutes)
Track Prepare
Period
Decide
Period
Confirm
Period
Minimum
Enactment Period
Root 14400 blocks
(1 day)
201600 blocks
(14 days)
14400 blocks
(1 day)
14400 blocks
(1 day)
Whitelisted 100 blocks
(10 minutes)
201600 blocks
(14 days)
100 blocks
(10 minutes)
300 blocks
(30 minutes)
General Admin 600 blocks
(1 hour)
201600 blocks
(14 days)
14400 blocks
(1 day)
14400 blocks
(1 day)
Emergency
Canceller
600 blocks
(1 hour)
201600 blocks
(14 days)
1800 blocks
(3 hours)
100 blocks
(10 minutes)
Emergency
Killer
600 blocks
(1 hour)
201600 blocks
(14 days)
1800 blocks
(3 hours)
100 blocks
(10 minutes)
Fast General Admin 600 blocks
(1 hour)
201600 blocks
(14 days)
1800 blocks
(3 hours)
100 blocks
(10 minutes)

Note

As of runtime 2800, asynchronous backing has been enabled on Moonbase Alpha. As a result, the target block time was reduced from 12 seconds to 6 seconds, which may break some timing-based assumptions. Note that this is for Moonbase Alpha only.

Support and Approval Parameters by Track

Track Approval Curve Approval Parameters Support Curve Support Parameters
Root Reciprocal Day 0: 100%
Day 4: 80%
Day 14: 50%
Linear Day 0: 25%
Day 14: 0.5%
Whitelisted Reciprocal Day 0: 100%
Day 1: 96%
Day 14: 50%
Reciprocal Day 0: 2%
Hour 1: 1%
Day 14: 0%
General Admin Reciprocal Day 0: 100%
Day 4: 80%
Day 14: 50%
Reciprocal Day 0: 50%
Day 7: 10%
Day 14: 0%
Emergency
Canceller
Reciprocal Day 0: 100%
Day 1: 96%
Day 14: 50%
Reciprocal Day 0: 10%
Day 1: 1%
Day 14: 0%
Emergency
Killer
Reciprocal Day 0: 100%
Day 1: 96%
Day 14: 50%
Reciprocal Day 0: 10%
Day 1: 1%
Day 14: 0%
Fast General Admin Reciprocal Day 0: 100%
Day 4: 80%
Day 14: 50%
Reciprocal Day 0: 50%
Day 5: 1%
Day 14: 0%
Track Approval Curve Approval Parameters Support Curve Support Parameters
Root Reciprocal Day 0: 100%
Day 4: 80%
Day 14: 50%
Linear Day 0: 25%
Day 14: 0.5%
Whitelisted Reciprocal Day 0: 100%
Day 1: 96%
Day 14: 50%
Reciprocal Day 0: 2%
Hour 1: 1%
Day 14: 0%
General Admin Reciprocal Day 0: 100%
Day 4: 80%
Day 14: 50%
Reciprocal Day 0: 50%
Day 7: 10%
Day 14: 0%
Emergency
Canceller
Reciprocal Day 0: 100%
Day 1: 96%
Day 14: 50%
Reciprocal Day 0: 10%
Day 1: 1%
Day 14: 0%
Emergency
Killer
Reciprocal Day 0: 100%
Day 1: 96%
Day 14: 50%
Reciprocal Day 0: 10%
Day 1: 1%
Day 14: 0%
Fast General Admin Reciprocal Day 0: 100%
Day 4: 80%
Day 14: 50%
Reciprocal Day 0: 50%
Day 5: 1%
Day 14: 0%
Track Approval Curve Approval Parameters Support Curve Support Parameters
Root Reciprocal Day 0: 100%
Day 4: 80%
Day 14: 50%
Linear Day 0: 25%
Day 14: 0.5%
Whitelisted Reciprocal Day 0: 100%
Day 1: 96%
Day 14: 50%
Reciprocal Day 0: 2%
Hour 1: 1%
Day 14: 0%
General Admin Reciprocal Day 0: 100%
Day 4: 80%
Day 14: 50%
Reciprocal Day 0: 50%
Day 7: 10%
Day 14: 0%
Emergency
Canceller
Reciprocal Day 0: 100%
Day 1: 96%
Day 14: 50%
Reciprocal Day 0: 50%
Day 1: 1%
Day 14: 0%
Emergency
Killer
Reciprocal Day 0: 100%
Day 1: 96%
Day 14: 50%
Reciprocal Day 0: 10%
Day 1: 1%
Day 14: 0%
Fast General Admin Reciprocal Day 0: 100%
Day 4: 80%
Day 14: 50%
Reciprocal Day 0: 50%
Day 5: 1%
Day 14: 0%

Conviction Multiplier

The Conviction multiplier is related to the number of Enactment Periods the tokens will be locked for after the referenda is enacted (if approved). Consequently, the longer you are willing to lock your tokens, the stronger your vote will be weighted. You also have the option of not locking tokens at all, but vote weight is drastically reduced (tokens are still locked during the duration of the referendum).

If you were to vote 1000 tokens with a 6x Conviction, your weighted vote would be 6000 units. That is, 1000 locked tokens multiplied by the Conviction, which in this scenario would be 6. On the other hand, if you decided you didn't want to have your tokens locked after enactment, you could vote your 1000 tokens with a 0.1x Conviction. In this case, your weighted vote would only be 100 units.

The Conviction multiplier values for each network are:

Lock Periods After Enactment Conviction Multiplier Approx. Lock Time
0 0.1 None
1 1 1 day
2 2 2 days
4 3 4 days
8 4 8 days
16 5 16 days
32 6 32 days
Lock Periods After Enactment Conviction Multiplier Approx. Lock Time
0 0.1 None
1 1 1 day
2 2 2 days
4 3 4 days
8 4 8 days
16 5 16 days
32 6 32 days
Lock Periods After Enactment Conviction Multiplier Approx. Lock Time
0 0.1 None
1 1 1 day
2 2 2 days
4 3 4 days
8 4 8 days
16 5 16 days
32 6 32 days

Note

The lock time approximations are based upon regular 12-second block times. Block production may vary and thus the displayed lock times should not be deemed exact.

Roadmap of a Proposal

Before a proposal is submitted, the author of the proposal can submit their idea for their proposal to the designated Democracy Proposals section of the Moonbeam Governance discussion forum for feedback from the community for at least five days. From there, the author can make adjustments to the proposal based on the feedback they've collected.

Once the author is ready, they can submit their proposal on-chain. To do so, first, they need to submit the preimage of the proposal. The submitter needs to bond a fee to store the preimage on-chain. The bond is returned once the submitter unnotes the preimage. Next, they can submit the actual proposal and pay the Submission Deposit, which is enough to cover the on-chain storage cost of the proposal. Then the Lead-in Period begins and the community can begin voting "Aye" or "Nay" on the proposal by locking tokens. In order for the referendum to advance and move out of the Lead-in Period to the Decide period, the following criteria must be met:

  • The referendum must wait the duration of the Prepare Period, which allows for adequate time to discuss the proposal before it progresses to the next phase
  • There is enough Capacity in the chosen Track
  • A Decision Deposit has been made that meets the minimum requirements for the Track

If a referendum meets the above criteria, it moves to the Decide Period and takes up one of the spots in its designated Track. In the Decide Period, voting continues and the referendum has a set amount of days to reach the Approval and Support requirements needed for it to progress to the Confirm Period.

Once in the Confirm Period, a referendum must continuously meet the Approval and Support requirements for the duration of the period. If a referendum fails to meet the requirements at any point, it is returned to the Decide Period. If the referendum meets the Approval and Support requirements again, it can progress to the Confirm Period again and the Decide Period will be delayed until the end of the Confirm Period. If the Decide Period ends and not enough Approval and Support was received, the referendum will be rejected and the Decision Deposit will be returned. The proposal can be proposed again at any time.

If a referendum continously receives enough Approval and Support during the Confirm Period, it will be approved and move to the Enactment Period. It will wait the duration of the Enactment Period before it gets dispatched.

The happy path for a proposal is shown in the following diagram:

A happy path diagram of the proposal roadmap in OpenGov.

Proposal Example Walkthrough

A proposal (with its preimage) is submitted for the General Admin Track on Moonriver would have the following characteristics:

  • The Approval curve starts at 100% on Day 0, goes to 80% on Day 4
  • The Support curve starts at 50% on Day 0, goes to 10% on Day 7
  • A referendum starts the Decide Period with 0% "Aye" votes (nobody voted in the Lead-in Period)
  • Token holders begin to vote and the Approval increases to a value above 80% by Day 4
  • If the Approval and Support thresholds are met for the duration of the Confirm Period (7200 blocks, approximately 1 day), the referendum is approved
  • If the Approval and Support thresholds are not met during the Decision Period, the proposal is rejected. Note that the thresholds need to be met for the duration of the Confirm Period. Consequently, if they are met but the Decision Period expires before the completion of the Confirm Period, the proposal is rejected

The Approval and Support percentages can be calculated using the following:

Approval = 100 * ( Total Conviction-weighted "Aye" votes / Total Conviction-weighted votes ) 
Support = 100 * ( Total non-Conviction-weighted votes / Total supply )

Proposal Cancellations

In the event that a proposal already in the voting stage is found to have an issue, it may be necessary to prevent its approval. These instances may involve malicious activity or technical issues that make the changes impossible to implement due to recent upgrades to the network.

Cancellations must be voted on by the network to be executed. Cancellation proposals are faster than a typical proposal because they must be decided before the enactment of the proposal they seek to cancel, but they follow the same process as other referenda.

There is a cancellation Origin for use against referenda that contain an unforeseen problem, called the Emergency Canceller. The Emergency Canceller Origin and the Root Origin are allowed to cancel referenda. Regardless of the Origin, if a proposal is cancelled, it gets rejected and the Decision Deposit gets refunded.

In addition, there is a Kill Origin, which is for bad referenda intending to harm the network, called Emergency Killer. The Emergency Killer Origin and the Root Origin have the ability to kill referenda. In this case, a proposal is cancelled and the Decision Deposit is slashed, meaning the deposit amount is burned regardless of the Origin.

Rights of the OpenGov Technical Committee

On Polkadot, the Technical Committee from Governance v1 was replaced with the Fellowship, which is a "mostly self-governing expert body with a primary goal of representing humans who embody and contain the technical knowledge base of the Kusama and/or Polkadot networks and protocol," according to Polkadot's wiki.

For Moonbeam's implementation of OpenGov, instead of the Fellowship, there is a community OpenGov Technical Committee that has very similar power to that of the Fellowship. Their power in governance resides in their ability to whitelist a proposal. OpenGov Technical Committee members may only vote to whitelist a proposal if whitelisting that proposal would protect against a security vulnerability to the network. The passing threshold of the OpenGov Technical Committee members on whether to whitelist a proposal is determined by governance. As such, the OpenGov Technical Committee has very limited power over the network. Its purpose is to provide technical review of urgent security issues that are proposed by token holders.

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 Moonriver or Moonbeam token holders through governance and cannot be changed by the OpenGov Technical Committee.

The OpenGov Technical Committee is made up of members of the community who have technical knowledge and expertise in Moonbeam-based networks.

Related Guides on OpenGov

For related guides on submitting and voting on referenda on Moonbeam with OpenGov, please check the following guides:

Last update: June 10, 2024
| Created: February 10, 2021