Polkadot Governance V2

Polkadot employs a sophisticated governance mechanism that can gracefully evolve according to the needs of stakeholders. Its goal is to ensure that the majority of stakes always have control over the network.

The content introduced in this article may change. The governance protocol has undergone several iterations (v1 and v2), and there will be more changes in the future (v2.5).

The first-generation decentralized governance system of Polkadot (v1) consists of three main parts:

• Technical Committee: Manage Upgrade Schedule
• Council: The executive body responsible for managing parameters and the election of management and expenditure proposals.
• Referendum: Universal voting system that grants greater influence to long-term stakeholders.

The system ran well in the early stages, but as it developed, further improvements were needed. Thus, "Governance v2" was born.

"Governance v2"(Gov2) has changed the way daily decisions are made, making the scope of referendums broader and more flexible, significantly increasing the number of collective decisions the system can make.

Gov2 has been launched on the Kusama network. After testing on Kusama, a proposal will be made to deploy it on Polkadot.

The following content will introduce the core governance principles of the Polkadot network. Understanding Governance v1 helps to grasp the direction of the second iteration. Each section will highlight the differences between the two.

It is worth noting that the governance protocol is still evolving. With the governance v2 update, plans for governance v2.5 are also being developed.

Premise

Polkadot brings together various innovative mechanisms, including on-chain stored state transition functions, multiple on-chain voting mechanisms, and more.

All protocol changes must reach consensus through a token-weighted vote.

Mechanism

In Governance v1, active token holders and the council jointly manage decisions on network upgrades. Regardless of whether proposals are put forward by the public or the council, they must ultimately go through a public referendum, where decisions are made based on the amount of stake and belief value as weights.

Governance v2 has several changes that reflect decentralized characteristics:

• Transfer the responsibilities of the council to token holders through democratic voting
• Dissolve the current board of directors
• Allow users to delegate voting rights to community members in more ways.

Referendum

The referendum is a simple and inclusive voting scheme based on staking. Each referendum has a specific proposal, presented in the form of a runtime privilege function call.

A referendum is a discrete event with a fixed voting period. After the voting period ends and the ballots are counted, if approved, the corresponding function will be called.

In Governance v1, a referendum can be initiated in the following ways:

• Publicly submitted proposals
• Proposals passed by a majority or unanimous vote of the council
• Proposal submitted as part of the previous referendum execution.
• Emergency proposals submitted by the Technical Committee and approved by the Board of Directors.

All referendums have an execution delay period. This is the period of time from the end of the referendum to the actual implementation of the proposal.

In Gov2, anyone can initiate a referendum at any time, with no limit on the number. Gov2 introduces the concepts of Origins( and Tracks) to assist the referendum process.

Origin is a descriptor for a given privilege level. Proposers need to select the appropriate Origin based on the proposal requirements.

Each Origin is associated with a voting category, and each category is associated with a Track. The Track outlines the lifecycle of the proposal, independent of other categories. Different tracks allow for adjustments to the voting dynamics based on privilege levels.

Proposal Referendum

Anyone can propose a referendum by depositing a minimum amount of tokens within a certain period. If someone agrees, they can deposit the same amount of tokens to show support, which is called an "endorsement." The proposal that receives the highest amount of bound token support will become the referendum for the next voting cycle.

In Gov2, the community can vote immediately after the referendum is created. However, the referendum must meet certain criteria to enter the "decided" status; until then, it remains pending.

The criteria for entering a decision state include:

• After the import period
• There is still room for decision
• Payment decides the deposit

Referendum Vote ( Governance v2)

In Gov2, proposals are approved if they meet the approval rate and support rate requirements.

The approval rate is the ratio of the approved voting weight to the total voting weight.

The support rate is a comparison of the total number of approvals to the potential total number of votes in the system.

Proposals must meet these standards in the shortest time within the confirmation period. Different tracks have different confirmation periods and requirements.

Proposals that have not been approved after 28 days will be rejected. Approved proposals will be executed after the formulation period.

Voluntary Lockup

Polkadot uses the concept of "voluntary locking" to allow token holders to increase their voting power by locking their tokens. The formula for calculating the voting count is:

Vote Count = Token * Belief Multiplier

Every doubling period increases the faith multiplier by 1. A maximum of 32 periods can be locked for 28 days/period.

Polkadot Fellowship

Fellowship is a fundamentally autonomous expert institution that represents individuals with knowledge of Polkadot network and protocol technologies. It classifies members through "levels".

Becoming a candidate member is easy; just deposit a small amount. Members can vote on Fellowship proposals, and the aggregated opinions ( are weighted by level ) to form the considerations of the Fellowship.

To prevent a small number of people from controlling the network, the system follows three principles:

1. Fellowship does not possess hard power over the network.
2. Higher-level members have greater weight in their opinions, but it should not be so high that it cannot be surpassed by the unanimous opinions of lower-level members.
3. Fellowship should increase the development of members and their professional level.

The Fellowship will establish a charter outlining the requirements for obtaining and maintaining levels. Higher-level personnel may promote lower-level personnel according to the charter.

If a member cannot prove their status, they will be automatically downgraded. Suspension can only occur through a referendum. Achieving the highest level requires a referendum.

Whitelist

The whitelist mechanism allows Fellowship to authorize a new source (Whitelisted-Root) to execute specific commands with Root-level permissions. This enables shorter voting cycles while being deemed safe and urgent by the Polkadot expert community.

Blacklist

Proposals can be blacklisted from the Root source. Blacklisted proposals and related referendums will be immediately canceled and cannot be resubmitted. This helps to eliminate erroneous proposals, but it is not a foolproof solution to prevent invalid proposals.