OpenGov: What is Polkadot Gov2

OpenGov, formerly referred to as Gov2, is the proposed next phase of Polkadot governance, bringing the next generation of decentralized, secure, and democratic governance to Polkadot. OpenGov is live on Kusama and coming to Polkadot if approved by the community.

The need for a strong governance process is at the core of crypto communities because it helps further decentralization, security, and equity. Community stakeholders have an interest in ensuring treasury funds are allocated appropriately, upgrades are rolled out, and issues are managed. Unlike many communities, governance decisions for Polkadot and the parachainsGo to page https://moonbeam.network/education/what-is-a-parachain/ are performed on-chain, making them transparent.

Polkadot’s original governance structure was loosely based on parliamentary democracy and was always meant to be improved as the needs of the network grew. Originally called Gov2Go to page https://medium.com/polkadot-network/gov2-polkadots-next-generation-of-decentralised-governance-4d9ef657d11b, OpenGov is Polkadot’s upgraded approach to governing the network.

Polkadot and all the parachains are inherently upgradeable. We use WebAssembly to make this stuff adaptable and changeable and evolve over time. But in order to come to a decision about what should be changed, we need a decision-making process. This is governance.

Decentralization Through Governance

The structure of OpenGovGo to page https://wiki.polkadot.network/docs/learn-polkadot-opengov echoes the decentralization of the crypto landscape. There are layers of decentralization in blockchain, beginning with the technical layer of infrastructure, operation, and development, up to the broader level of governance. OpenGov is a form of decentralized decision-making that uses the newly-released Substrate governance pallet, which provides users with the opportunity to directly participate in decentralized decision-making and voting processes.

Making decisions as a network relies on a governance process that continues to grow and change as it meets new challenges and considers feedback from users and builders. If approved, Polkadot will use OpenGov as outlined here, and it will be up to the parachains communities to decide how this will affect parachain governance.

Decentralization

On-chain governance in the form of voting with tokens held by stakeholders in the network decentralizes and democratizes the decision-making process. The decisions about the direction of the network affect everyone that uses it. For this reason, every token holder has a say in how the network is managed.

Allowing GLMR holders to make decisions about the Moonbeam network, for example, is a key part of supporting a proof-of-stake network and keeping it safe from outside parties seeking to damage the network with nothing to lose. OpenGov on-chain voting is both inclusive and transparent, making it as accessible as possible for the Polkadot community to participate.

Security

The structure of governance is designed to prevent harmful decisions from being executed. When a network is decentralized, checks and balances are installed to prevent bad actors from taking over and controlling the majority of the vote.

Equity

As crypto communities grow, increased flexibility in the governance process through more granular decision-making can be helpful. The decision-making process is based on the gravity of the proposed changes because some decisions are more technical and significant than others and should be considered critically.

Updates to Governance with Polkadot OpenGov

OpenGov is a matured version of Polkadot Governance v1. Overall, Gov v2 works to match the level of importance of a proposalGo to page https://moonbeam.network/blog/opengov/#proposal to the amount of time and participation needed to approve it or not. Streamlining democracy in this way is secure and ensures participation in important proposals through increased time a requirement that a minimum number of tokens are represented.

OpenGov improves governance version 1 in some ways and removes or changes other aspects. The original Polkadot governance tenet, which holds that 50% of the total stake in the system should, if they have sufficient strength of convictionGo to page https://moonbeam.network/blog/opengov/#conviction in their opinion, be able ultimately to command the system’s future remains intact, but the process of getting to that point is updated.

One of the big changes coming in with OpenGov is that it does away with the existing Council and Technical Committee, instead passing full control to the community via proposal paths and the creation of the Fellowship. This change has been made on Kusama.

Overall, Gov v2 works to match the level of importance of a proposal to the amount of time and participation needed to approve it or not.

In general, the proposal of referenda and their approvalGo to page https://moonbeam.network/blog/opengov/#approval and organization, along with the timetable and queuing mechanisms involved have been adjusted, as have the processes for canceling referenda.

Vote conviction has stayed the same, and the Council and Technical Committee have been dissolved in favor of a Fellowship on Kusama. A number of new items have been introduced including OriginsGo to page https://moonbeam.network/blog/opengov/#origin and TracksGo to page https://moonbeam.network/blog/opengov/#tracks, Whitelisting, Blacklisting, and the installment of the Polkadot Fellowship. The changes to the approval process make it more open and easier for the community to lead and approve proposals themselves.

What’s Changed in OpenGov at-a-Glance

A Guide to What’s New in Polkadot OpenGov

OpenGov maintains Polkadot-pioneered conviction voting which takes place in the same way it has before, using WebAssembly and several on-chain voting mechanisms. That said, OpenGov moves the process toward decentralization by lowering barriers to manage the day-to-day decision-making of the network better. The real focus is on aligning the scope of the proposals to the way they go through the governance process.

The original Polkadot governance tenet, which holds that 50% of the total stake in the system should, if they have sufficient strength of conviction in their opinion, be able ultimately to command the system’s future remains intact, but the process of getting to that point is updated.

Polkadot OpenGov Proposal Process

Polkadot governance just became a lot simpler. When it comes to submitting a proposal, there is no longer a launch period where proposals need to gain supportGo to page https://moonbeam.network/blog/opengov/#support before moving to the referendum phase for general voting. This means any community member can make a referendum without any delay. Unlike Gov1, with OpenGov there can be thousands of decisions happening at the same time. This first-class decision-making mechanism is called a referendumGo to page https://wiki.polkadot.network/docs/learn-polkadot-opengov#referenda.

Referendum: A general vote by the community on a single idea called a proposal

With OpenGov Referenda:

• Can start at any time
• Can be started by anyone
• Can be started as many times as the proposer wants
• Can be voted on by any DOT token holder
• Are not limited in number at one specific time

Proposal: A formal written plan or suggestion put forward for consideration and discussion by the community

Referenda are based on proposals. Community members put together an idea they want to see implemented on Polkadot and submit it for the community to vote on in a referendum.

“Proposal” is another way of saying “operation,” on Polkadot (like how the operation of making a transaction is proposed by the user). This distinction matters because Polkadot can do many different operations (like transfer, stake, etc) and OpenGov proposals are organized according to their operation privilege level.

Some operations on Polkadot need more power (think, computing power — deeper levels of logic and security authorization), and some are less critical. For example, an upgrade to underlying technology layers would be a more critical operation/proposal than adding a night-mode feature on a dApp. These levels of complexity or privilege are described by the word Origin.

Origins and Tracks for Streamlining Proposals and Referenda

Origin: A description of a level of privilege. In the context of OpenGov, an Origin is an authorization-based transaction source used to determine the track that a referendum is posted under. There are different levels of Origin, ranging from the most privileged Root Origin to Tip Origin with less privilege.

Before OpenGov, every democracy referendum proposed was run as Root Origin. This is the most powerful level parameter, and overkill for lower-priority referenda. The result of running every referendum this way was a backlog of proposals and end-to-end 28-day voting windows, which gave each proposal equal time and attention, even if some were more significant than others. Missing the voting window meant waiting until the next spot opened in the queue to put a proposal on-chain, causing further delays and confusion.

In OpenGov, the proposer chooses which Origin class they want their proposal executed with. Each Origin is associated with a type of referenda (i.e. maintenance mode activation, runtime upgrades, XCM channels opening) with different criteria.

Tracks: An Origin-specific pipeline that proposals process through during a referendum.

Tracks are specific to Origins, so they are separate from each other Origin track, allowing proposals in different tracks to run alongside (at the time same!) proposals in other tracks. Less critical Origin tracks can have multiple referenda running at the same time because the changes in the proposals are not as dangerous as on the Root Origin track which only has one at a time.

Track Maximum Deciding or Capacity: A limit for the number of referenda on this track that can be decided at once.

Referenda in different tracks follow different rules that are proportional to their level of Origin class. I.e. More dangerous and privileged referenda will have more safeguards, higher thresholds, and longer consideration periods for approval.

How Proposals Are Approved in Polkadot OpenGov

Polkadot OpenGovGo to page https://wiki.polkadot.network/docs/learn-polkadot-opengov#proposing-a-referendum provides a framework and process for organizing the overarching governance system to give users the ability to change the network in a democratic and fair way. The process is designed to create a consistent dynamic of holding community discussions prior to voting on and enacting a proposal. Different Origin Tracks have different criteria for approval. Still, the general process of being approved is the same for all Origin Tracks.

The On-Chain Proposal Overview for Any Origin Tracks

In OpenGov referenda are completed by a common process, while the details of the requirements for approval are Track specific. Within the Track the parameters differ in regard to:

• The period of time for Deciding Period, Confirming Period, Minimum Enactment Period, and Preparation.
• The Curve, or amount of approval and support required for a referendum to pass
• The number of referenda that can happen at the same time, or capacity.

The OpenGov Proposal Approval Process:

1. Proposal/ Referenda Creation: A community member must specify the Origin of the transaction and add the proposal idea.
2. Leading Period: Voting begins, but proposals at this stage are “undecided” until they pass the criteria for their assigned track (i.e. minimum length of voting time met, space available in the track, decision depositGo to page https://moonbeam.network/blog/opengov/#decision-deposit paid).
3. Deciding Period: The community continues to vote on “deciding” the proposal using tokens for a limited time.
4. Confirming Period: Proposals will pass that receive approval and enough support (a minimum number of DOT) and maintain this status throughout the track-specific confirming period inside the set Deciding Period.
5. Approval or Rejection: If the proposal is not approved before the Deciding Period ends, it is rejected. If the proposal is passing for its Confirming Period it is approved, even if the Deciding Period is not over.
6. Enactment: The approved proposal waits for a specified time (laid out in the original proposal) to be put into action.

Lead-in Period

When a proposal is put forth for a referendum the community begins voting. This is called the “Lead-in Period”. In general, the “Lead-In Period” is a time period for discussion. There needs to be space on the Track for a proposal to move on. The community votes on proposals in this period, which will move them to the front of the line if there are multiple proposals waiting for space on the track, but these votes are not part of the Deciding period.

Criteria To Move from Lead-in to Deciding

1. Referendum has been posted for a minimum amount of time
   • This allows votes to come in and prevents a proposal from being passed to the next phase without discussion.
2. There is space for the proposal in the chosen Track
   • Tracks have different limits for the number of referenda that can run at the same time (i.e. Root Origins need more consideration given the security implications of root origin referendum, so only one referendum can be in the Root Origin Track’s Deciding period at a time).
3. A Decision Deposit has been made
   • To complete the criteria, a deposit must be paid. This deposit may vary depending on the track. The purpose of deposits is to cover the on-chain storage of the referendum and to deter spamming.

Decision Deposit: Amount that must be placed on deposit before a decision can be made.

Deciding Period and Confirming Period

Once a proposal has met the Lead-In criteria, it has a spot on its designated Track and the voting continues in the Deciding Period. In order for a proposal to progress from the Deciding Period to the Confirming Period, it must meet two criteria: approval and support. The Confirming Period is a shorter amount of time than the Deciding Period and can be “met” at any time within the designated Deciding Period.

Approval and Support

Approval and Support criteria are used in both the Deciding Period and Confirming Period. In general, these criteria require that there is a majority vote by weighted conviction (i.e. the weights of the votes are in favor of the proposal), and also that a large enough portion of DOT tokens available has participated.

Approval refers to the percent of “aye” votes required for a proposal to progress from the Deciding Period to the Confirming Period, and ultimately to being approved in the Confirming Period. Unlike Support, Approval takes into account vote conviction.

Support refers to the minimum number of votes needed to participate in the referenda. Support criteria are reflected as a percent of the total supply, i.e. [x]% of DOT’s total supply needs to cast a vote on whether it is Aye, Nay, or Abstain.

Conviction: Locking tokens to increase their vote multiplier to increase voting power. I.e. tokens locked for a maximum of 32 lock periods (896 days) multiply their vote by 6.

Approval: the share of the approval vote-weight after adjustments for conviction against the title number of vote-weight for both approval and rejection.

Support: The total number of votes in approval (ignoring adjustments for conviction) compared to the total possible amount of votes that could be made in the system. Support also takes into account abstained votes.

The approval and support criteria are determined by the approval curveGo to page https://moonbeam.network/blog/opengov/#approval-curve and support curveGo to page https://moonbeam.network/blog/opengov/#support-curve, respectively.

Approval Curve: The curve specifying the minimum AYE votes as a percentage of overall conviction-weighted votes needed for approval as a function of time into the decision period.

Support Curve: The curve specifying the minimum pre-conviction AYE-votes (“support”) as a percentage of the overall population that is needed for approval as a function of time into the decision period taking into account abstained votes.

The Deciding Period

A proposal in the Deciding Period has a set amount of days to reach the approval and support requirements needed for it to progress to the Confirming Period. If a project fails to meet these requirements it will be rejected.

A rejected proposal can be proposed again, as many times as desired, assuming it is not malicious. Upon rejection, the Decision Deposit is typically returned. If the proposal is approved, it moves to the Enactment Period.

Deciding Period: Amount of time that a decision may take to be approved to move to Confirming Period prior to rejection.

The Confirming Period

Once a proposal moves to the Confirmation PeriodGo to page https://moonbeam.network/blog/opengov/#confirmation-period, it must continue meeting the approval and support requirements for a set amount of time. This amount of time that a proposal needs to be passing continuously. The requirements to pass the approval and support requirements evolve over time based on the voting curve. Each track will have a specific voting curve.

The Confirming Period prevents proposals from being manipulated to get approved quickly by a heavily weighted vote that momentarily spikes the approval criteria. If the votes to maintain approval are not present, the proposal can not sustain its status as approved and supported for the required amount of time and it will have to begin the Confirmation Period again.

Referendums in the Root Origin could have a significant impact on the network security and so the Confirmation Period is longer than a Track that wouldn’t have as big of an impact on the network.

If a proposal passes for its required amount of confirming time, it will be considered “approved” and will move to the Enactment Phase. If the proposal does not pass, it will return back to the Deciding Phase to seek new approval and support for the Confirming Period, if the Deciding Period is not over.

Confirmation Period: Amount of time that the approval and support criteria must hold before it can be approved.

Criteria to Move from Deciding to Confirmed

1. Approval
   • Required voting result in compliance with the Approval Curve of the Origin Track which includes conviction
2. Support
   • Enough of the voters approved the proposal compared to the total number of possible votes in compliance with the Support Curve and taking into account the voters that have abstained from voting.
3. Confirmation Period
   • Proposals that have approval and support for the set amount of time required within the referendum Deciding period are approved
   • Proposals that do not meet the criteria within the Deciding period and remain approved and supported for the confirmation period are rejected.

A rejected proposal can be proposed again, as many times as desired, assuming it is not malicious. Upon rejection, the Decision Deposit is returned. If the proposal is approved, it moves to the Enactment PeriodGo to page https://moonbeam.network/blog/opengov/#enactment-period.

Enactment Period

When a proposal gets to this stage in the process, it is approved and will be dispatched after a waiting or Enactment Period. This amount of time for the Enactment Period is suggested by the proposer in the initial referendum proposal, but there are also minimums set for each Origin Track.

Enactment Period: Minimum amount of time that an approved proposal must be in the dispatch queue after approval.

The time reserved in the Enactment Period ensures that the network is ready for the proposed changes. Root Origin approvals require a longer waiting period after approval because of the depth of the changes that may need to be accommodated by the Polkadot network.

OpenGov Interventions For Bad Proposals

No process is perfect, and in anticipation of challenges, there are some measures built into OpenGov to manage these difficulties. There are cases where a proposal contains problems or malicious intent.

Cancelation

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.

Cancelation: A governance operation with its own Origin track that can immediately reject an ongoing referendum regardless of status is passed.

There are two CancelationGo to page https://wiki.polkadot.network/docs/learn-polkadot-opengov#canceling-referenda 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.

The Emergency Canceler 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.

Cancellation must be voted on by the network to execute. Cancellation 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. The Cancellation Origin Tracks have a short lead time and approval and support curves with reductions in the threshold for passing.

Voting Delegation in OpenGov

Keeping up with everyone going on in Polkadot is a full-time job. Many token holders do not have the bandwidth to research, discuss, and consider every proposal, but they still have a stake in the network and therefore, a say in the decisions made regarding it.

Polkadot’s original Council was a body delegated by voters to make up for the absentee vote. In Gov2 or OpenGov on Kusama and Polkadot, there is no Council, but the Vote DelegationGo to page https://moonbeam.network/blog/opengov/#vote-delegation feature has been retained and improved to ensure that absent voters’ voices are heard.

Vote Delegation: A voter can give the power of his vote, including conviction voting, to another voter.

Multirole Delegation: Users can specify different delegates for each track or class of referendum in the system.

OpenGov Voting Delegation is optimized for flexibility, and Multirole Delegation is introduced. 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.

The special feature added to Voting Delegation in Gov2 is Multirole Delegation. To ensure that the right person is voting on the right proposals on a user’s behalf, Multirole Delegation can be used to put voting power in a different entity depending on the proposal.

A user might delegate his vote to a more technical entity for Root Origins track proposals, for example, and another for less critical tracks. These delegations can be made for one referendum or per Track at the user’s discretion.

So, for example, a user could delegate voting for technical decisions (like runtime upgrades) while retaining voting rights for other decisions (like grants approvals or major changes to the network) and revoke or change the delegations whenever the delegator wants.

How OpenGov Protects the Polkadot Network

In the first version of Polkadot governance, the Technical Committee had no deciding power but maintained the ability to reduce the voting period. This feature was used to optimize decision-making without interfering with the outcome of the governance process. The expert body was not able to subvert stakeholder decisions.

In Polkadot OpenGov, the Technical Committee is gone, and a new governance body called the Polkadot Fellowship has been formed. The responsibilities of the Fellowship include the management of proposals that affect the safety of the network and require time-critical decision-making.

Root Origin Safeguards

Root Origin Proposals Involve upgrades, fixes, and network rescues. These decisions are dangerous, and for this reason, require the highest thresholds for approval and support. Root Origin referenda have the longest lead-in and enactment periods. The process is slower to allow the most consideration time and reduce the acceptance of bad proposals.

A bad proposal can also be blacklistedGo to page https://wiki.polkadot.network/docs/learn-polkadot-opengov#blacklisting by Root Origin. This action immediately cancels the referendum and prevents the proposal’s hash from rejoining the proposal queue. This function is used when proposals are submitted in error or contain problems.

That said, on occasions when an important fix or upgrade is required, sometimes changes need to be made quickly. This is where the Fellowship plays a role in OpenGov.

The Polkadot Fellowship

The Polkadot FellowshipGo to page https://wiki.polkadot.network/docs/learn-polkadot-opengov#polkadot-fellowship is a self-governing body of experts well-informed with a sound technical understanding of Polkadot. One need for this Fellowship is the safeguarding of the network in regard to Root Origin proposals.

The membership in the Polkadot Fellowship is broad. Anyone can become a candidate member by placing a deposit. Members are associated with a rank based on their level of expertise. Members of the Fellowship can vote on any Fellowship proposal using the same means as Polkadot stakeholders do in referenda, and the results of the vote will count as the Fellowship’s considered option.

The Polkadot Fellowship has some additional options beyond voting for securing the network. These include authorizing a new Whitelisted-Root Origin when there is a need to escalate the privilege of another Origin for a specific operation.

More detail about the structure of the Fellowship will be published to explain the nuances of rank and candidate selection. In the meantime, the logic has been deployed on Kusama for testing. More information about how Fellowship members have ranked can be found on the Polkadot wiki.Go to page https://wiki.polkadot.network/docs/learn-polkadot-opengov#ranking-system

When to Expect OpenGov to be Up and Running on Polkadot

Polkadot continues to evolve and governance will keep up. At this time, OpenGov is live on Kusama and a Polkadot vote is upcoming. Parachain community members have begun to initiate governance to determine if and how they will implement OpenGov into their own governance structures. Parachain ecosystems will participate in deciding the elements of OpenGov they wish to implement, with their own parameters, likely different from the general overview provided here. Likewise, Polkadot token holders will vote to decide if and how to implement OpenGov on Polkadot.

Additional features and functionality would need to be rolled out in an update to the overall governance system referred to as “Gov2.5.”