Skip to content

Governance on Moonbeam

Governance Moonbeam Banner

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. OpenGov has launched on Moonriver, and once it has been rigorously tested, a proposal will be made for it to be launched on Moonbeam. Until then, Moonbeam still uses Governance v1.

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
  • 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 Moonriver and Moonbase Alpha. If you're looking for governance-related information on Moonbeam, please refer to the Governance v1 section.

General Definitions

  • Proposal — an action or item, defined by the preimage hash, being proposed by a token holder and open for consideration and discussion by token holders
  • Referendum — a proposal that is up for token-holder voting. 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

  • Preimage hash — hash of the proposal to be enacted. The first step to make a proposal is to submit a preimage. The hash is just its identifier. The proposer of the preimage can be different than the user that proposes that preimage as a formal proposal

  • Preimage deposit — amount of tokens that the proposer needs to bond when submitting a preimage. It is calculated as the sum of a base deposit per network plus a fee per byte of the preimage being proposed

  • 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
  • Voting — a tool used by token holders to either approve ("Aye") or reject ("Nay") a proposal. The weight a vote has is defined by two factors: the number of tokens locked and lock duration (called Conviction)

    • Conviction — the time that token holders voluntarily lock their tokens when voting: the longer they are locked, the more weight their vote has
    • Lock balance — the number of tokens that a user commits to a vote (note, this is not the same as a user's total account balance)

    Moonbeam uses a concept of voluntary locking that allows token holders to increase their voting power by locking tokens for a longer period of time. Specifying no Lock Period means a user's vote is valued at 10% of their lock balance. Additional voting power can be achieved by specifying a greater conviction. For each increase in Conviction (vote multiplier), the Lock Periods double.

  • Approval — minimum "Aye" votes as a percentage of overall Conviction-weighted votes needed for an approval

  • Support — minimum number of "Aye" votes, not taking into consideration Conviction-weighted votes, needed as a percent of the total supply needed for an approval

  • Lead-in Period — the initial proposal voting and discussion period. At this stage, proposals are in an undecided state until they pass some criteria for the given Track. The criteria include:

    • Prepare Period — the minimum time the referendum needs to wait before it can progress to the next phase after submission
    • Capacity — limit for the number of referenda on a given Track that can be decided at once
    • Decision Deposit — the minimum deposit amount required for a referendum to progress to the decision phase after the end of the Lead-in Period. Since each Track has a defined Capacity, this deposit is larger than the submission deposit, and its goal is to mitigate spam

    Tracks have different criteria parameters that are proportional to their level of Origin class. For example, more dangerous and privileged referenda will have more safeguards, higher thresholds, and longer consideration periods for approval. 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

  • Vote Delegation — a voter can give their voting power, including Conviction voting, to another token holder (delegate) who may be more knowledgable and able to make specific decisions

  • Multirole Delegation — the ability to delegate voting power on a Track-by-Track basis, where a token holder can specify different delegates for each Track

Governance Parameters

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 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
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

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)
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)

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: 50%
Day 7: 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%
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%

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

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.

Cancellation 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 are two Cancellation Origins, one for use against referenda that contain an unforeseen problem called Emergency Canceller, and one for bad referenda intending to harm the network called Emergency Killer. Both of these Tracks have a short lead time and Approval and Support requirements, with reductions in the threshold for passing.

The Emergency Canceller track results in a rejected proposal and Decision Deposit refund, and the Emergency Killer track results in cancellation and a deposit slash, meaning the deposit amount is burned.

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 Governance v2

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

Governance v1

While OpenGov is being tested on Moonriver, Moonbeam will continue to use governance v1. This section will cover everything you need to know about governance v1 on Moonbeam.

General Definitions

With great power comes great responsibility. Some important parameters to understand before engaging with Moonbeam's governance include:

  • Proposals — actions or items being proposed by token holders. There are two main ways that a proposal is created:
    • Democracy Proposal - a proposal that is submitted by anyone in the community and will be open for endorsements from the token holders. The Democracy Proposal that has the highest amount of bonded support will be selected to be a referendum at the end of the Launch Period
    • External Proposal - a proposal that is created by the Council and then, if accepted by the Council, is submitted for token holder voting. When the Council submits an External Proposal, the Council sets the Vote Tallying Metric
      • Fast-tracked Proposal - the Technical Committee may choose to fast-track an External Proposal which means changing the default parameters such as the Voting Period and Enactment Period. A fast-tracked referendum can be created alongside existing active referenda. That is to say, an emergency referendum does not replace the currently active referendum
  • Referendum — a proposal that is up for token-holder voting. 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
  • Launch Period — the time period before a Voting Period that publicly submitted proposals will gather endorsements
  • Voting Period — time token holders have to vote for a referendum (duration of a referendum)

  • Voting — a tool used by token holders to either approve ("Aye") or reject ("Nay") a proposal. The weight a vote has is defined by two factors: the number of tokens locked and lock duration (called Conviction)

    • Conviction — the time that token holders voluntarily lock their tokens when voting: the longer they are locked, the more weight their vote has
    • Lock balance — the number of tokens that a user commits to a vote (note, this is not the same as a user's total account balance)

    Moonbeam uses a concept of voluntary locking that allows token holders to increase their voting power by locking tokens for a longer period of time. Specifying no Lock Period means a user's vote is valued at 10% of their lock balance. Additional voting power can be achieved by specifying a greater conviction. For each increase in Conviction (vote multiplier), the Lock Periods double.

  • Vote tallying metric — there are three types of vote tallying metrics: (i) Positive Turnout Bias (Super-Majority Approve), (ii) Negative Turnout Bias (Super-Majority Against), or (iii) Simple Majority. See Polkadot’s Wiki on Tallying for more information about how these different vote tallying metrics work

    • The vote tallying metric applied depends on the type of referendum:
  • Enactment Period — time between a proposal being approved and enacted (make law). It is also the minimum period necessary to lock funds to propose an action
  • Lock Period — time (after the proposal enactment) that the tokens of the winning voters are locked. Users can still use these tokens for staking or voting.
  • Cool-off Period — duration a veto from the technical committee lasts before the proposal may be submitted again
  • Delegation — act of transferring your voting power to another account for up to a certain conviction

Governance Parameters

The governance parameters on Moonbeam are as follows:

Variable Value
Launch Period 50400 blocks (7 day)
Voting Period 100800 blocks (14 days)
Enactment Period 14400 blocks (2 days)
Cool-off Period 50400 blocks (7 days)
Preimage base deposit 500 GLMR
Preimage deposit per byte 0.01 GLMR
Proposal deposit 400 GLMR
Maximum proposals 100
Maximum referenda (at a time)* 2

*The maximum number of referenda at a time does not take fast-tracked referenda into consideration.

Note

The Voting Period and Enactment Period are subject to change for External Proposals.

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 Moonbeam are:

Lock Periods After Enactment Conviction Multiplier Approx. Lock Time
0 0.1 None
1 1 7 days
2 2 14 days
4 3 28 days
8 4 56 days
16 5 112 days
32 6 224 days

Note

The lock time approximations are based upon regular {{ no such element: dict object['block'] }}-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.

When the proposal is ready to be submitted on-chain, a preimage for the proposal needs to be submitted on-chain. The preimage defines the action to be carried out. The submitter pays a fee-per-byte stored: the larger the preimage, the higher the fee. Once submitted, it returns a preimage hash.

The proposer can submit the proposal using the preimage hash, locking tokens in the process. Once the submission transaction is accepted, the proposal is listed publicly. So, you'll be able to view the proposal on Polkassembly.

Once the proposal is listed, token holders can second the proposal (vouch for it) by locking the same amount of tokens the proposer locked. The most seconded proposal moves to public referendum. When this happens, the referendum will be listed on the On-chain proposals page in Polkassembly.

Once in referendum, token holders vote Aye or Nay on the proposal by locking tokens. Two factors account the vote weight: amount locked and locking period. If the proposal passes, it is enacted after a certain amount of time.

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

Proposal Roadmap

Rights of the Council and the Technical Committee

The Council and Technical Committee are two collectives that have the following special voting rights:

Collective Can submit
External Proposals
Can submit
Fast-tracked Proposals
Can cancel malicious
Democracy Proposals
Can veto
External Proposals
Council X X
Technical Committee X

Fast-tracked Proposals with a Voting Period of one day or more require one-half of the Technical Committee's approval. Fast-tracked Proposals with a Voting Period of less than a day are called "Instant Fast-tracked Proposals" and require three-fifths of the Technical Committee's approval.

As seen in the above table, the Technical Committee can veto an External Proposal. Any single member of the Technical Committee can veto the proposal only once, and only for the duration of the Cool-off Period.

Positive Turnout Bias

Public referenda use a positive turnout bias metric, that is, a Super-Majority approval formula. The equation is the following:

Positive Turnout Bias

Where:

  • Approve — number of "Aye" votes (includes the Conviction multiplier)
  • Against — number of "Nay" votes (includes the Conviction multiplier)
  • Turnout — the total number of voting tokens (without including the Conviction multiplier)
  • Electorate — the total number of tokens issued in the network

In the previous example, these numbers were:

Variable Value
Approve 10800 (1800 x 6)
Against 80 (800 x 0.1)
Turnout 2600 (1800 + 800)
Electorate 1.22M
Result 1.5 < 9.8 (Aye wins!)

In short, a heavy Super-Majority of "Aye" votes is required to approve a proposal at low turnouts, but as turnout increases, it becomes a simple majority.

Related Guides on Governance v1

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

Last update: March 27, 2023
| Created: February 10, 2021