Interpretation of Polkadot’s next-generation decentralized governance system Gov2

The first version of Polkadot’s decentralized governance system was very interesting at the time: a tricameral structure; a technical committee to manage the upgrade schedule; a voted, elected executive “government” to manage parameters, admins, and spending proposals; A universal voting system governs everything else, rewarding long-term stakeholders with increased influence. Loosely based on parliamentary democracy, the system worked well for the first 2-3 years of launch, helping to ensure proper use of treasury funds, maintaining rapid upgrades, and deploying more critical fixes in a timely manner. However, it also has its drawbacks.

The elected executive layer (council) is centralized and mostly non-anonymous. This exposes the protocol to a degree of risk, as well as the possibility that individual council members may find themselves forced to behave in a certain way. Technical committees, while exercising significantly less power, have similar risk exposures and a higher degree of centralization. In a world full of authority (both good and bad), there is an increasing need for decentralization for the safety and security of all participants.

Furthermore, there is only one model of “all or nothing” referendums – all referendums carry the most power. Partly for this reason, only one referendum can be held at a time, and voting defaults to several weeks. This, combined with the limited bandwidth of the Council, means that the system as a whole tends to consider very few proposals in depth rather than many proposals broadly. Instead of harnessing the power of crowds, it inadvertently limits the power of crowds by managing potential decision throughput.

Coarse-grained delegation means that a degree of exclusivity is built into the system. Barriers to entry into an effective political framework are high, reducing inclusion and diversity, and hurting turnout and legitimacy.

Clearly, the first version of Polkadot governance is something that needs to be iterated over time. Now, I’m excited to detail our proposal for the next generation of governance in the Polkadot ecosystem.

Introduction to Gov 2

Polkadot’s next-generation governance system (called Gov2 at the time of development) aims to solve the problems of the current system. First of all, what it doesn’t change is that it doesn’t violate the original Polkadot governance principle, which held that 50% of the total stake in the system should be able to ultimately dictate the future of the system, as long as it’s confident enough of its own point of view. Likewise, it does not depart from the belief vote pioneered by Polkadot of giving greater weight to those who are willing to lock their tokens in the system for longer periods of time. Furthermore, the technocratic collective is still useful, although it differs from the current technocommittee in terms of importance, size, composition, and membership.

Where it differs most is how it manages the actual means of day-to-day decision-making, making the referendum wider and more flexible to significantly increase the number of collective decisions the system can make. Let’s take a deeper look at how it works.

lower the threshold

Gov2 is actually much simpler than current governance in many ways. No other institutions act as “first-class citizens” in governance, such as councils and technical committees. There is no alternate proposal timeline. There is no public proposal queue. Instead, we have only one first-class decision-making mechanism: a referendum. The main difference with Gov2 is that there can be many, possibly thousands, of referendums happening at the same time.

In Gov2, anyone can initiate a referendum at any time, and any number of times. Anyone can also vote on these referendums. There is no explicit limit to the number of referendums open to voting at any one time.

But this could lead to more things to vote on than any normal person with limited time can assess. This may reduce inclusivity and safety. So to make these potentially excessive voting events more manageable, we’ve introduced some interesting new features into the referendum process.

source and track

All referendums are based on motions, which are really just another word for “operations” in Polkadot. Make a transaction with you and include it in the block, describe and execute the same thing. Polkadot can do a variety of operations, but some of the operations you may already be familiar with are “transfer” to move assets between accounts, and “staking” to allow accounts to be pledged. Besides that, there are many other operations. What is special about this governance function is not the motions/actions, but the Origin they execute.

You can think of Origin as a rich descriptor of privilege level. It is passed in when the action is performed, and the logic of that action will usually check that it matches. When executing a regular transaction, the Origin parameter setting is set to the Signed variant. This means that a particular account in the system (usually by signing a transaction) authorizes the action to take place, and it operates with that privilege, which further means that, say, funds controlled by (and only by) that account can be spent.

Governance levels allow operations to run alongside other, more privileged sources. The most privileged among them is the Root source, which is omnipotent. All approved referendum proposals in the old governance system happened through Root. In Gov2, we have many different sources, all with some unique perks, many of which are far less powerful than Root, but more subdivided.

Interpretation of Polkadot's next-generation decentralized governance system Gov2

In Gov2, we allow proposers to specify which source they wish to use to execute their proposal. Each supported source is associated with a single referendum category (i.e. a category of referendum), most categories will correspond to a single source, but there may be some categories composed of multiple sources. Each category has its own track (Track), which is actually a pipeline for the existence and process of proposals, and each track is completely independent of the tracks of other categories.

Having separate tracks allows us to tailor the dynamics of the referendum based on its implied level of privilege. Referendums that implement proposals from stronger (read: dangerous!) bills will have tighter safeguards, higher thresholds and longer consideration periods. Root sources have the highest threshold and strongest safeguards. Those sources with relatively less power (such as Tip sources, which can spend up to 10 DOT from the treasury) have correspondingly shorter consideration periods and lower thresholds for passing.

open referendum

When a referendum is created, anyone in the community can immediately vote on it. However, it is not yet in a state where it can be closed, votes counted, approved and enforced. Instead, a referendum must meet a number of criteria before it can enter “Deciding” status. Until the referendum was in this state, it was still “pending”.

There are three criteria that need to be met: First, all referendums have a lead-in period. This is the time that must pass before the proposal can begin. This provides an initial notice period during which votes can be submitted to mitigate the possibility of “decision sniping”, where an attacker controlling a large amount of voting power may seek to pass a proposal as soon as it is presented, without giving the overall voting population consideration and time to vote.

Interpretation of Polkadot's next-generation decentralized governance system Gov2

Second, there must be room for decision. All tracks have their own limits on the number of referendums that can be decided simultaneously. The stronger the source of orbital availability, the tighter this limit will be. Root-level sources are limited to one, which means only one super-dangerous motion can be decided at a time. Conversely, the relatively low-power Tipping track is much more lenient, because too many of these kinds of motions cause much less damage, and it is more practical to decide on many Tipping at the same time than many Root-level calls at the same time. much more. When space is available, the (legitimate) referendum with the most upvotes in that category is elevated to “decision” status.

Finally, a Decision Deposit must be paid. Creating a referendum is cheap, just pay the deposit required to keep track of it on-chain. However, deciding to go to a referendum carries more risk and takes up limited space because we limit the number of referendums that can be decided simultaneously on each track. Therefore, higher (but refundable) deposits must be paid to mitigate spam or overload the system.

Decide and confirm proposals

The referendum is eligible for ratification once it reaches decision status. This eligibility only lasts for a limited time (28 days on Polkadot), at which point if it is not approved, it is denied by default. To be approved, a referendum must meet two criteria (and enter “coming soon” status when met), and it must continue to meet those criteria for at least the confirmation period. Different orbitals have different confirmation period lengths, with stronger orbits taking longer to confirm. This is an additional defense against attempts by whale voters to “snipe” the referendum, ie raiding the approval criteria by mass voting.

Interpretation of Polkadot's next-generation decentralized governance system Gov2

There are two pass criteria, Approval and Support. Gone is the adaptive turnout bias of past referendums. Now that we have a more flexible system, these requirements can be tailored at a finer-grained level. The approval rate is defined as the ratio of the approval vote weight (i.e. adjusted for belief) to the total vote weight (including approval and rejection). Approval is the ratio of the total number of votes approved (i.e. ignoring the belief adjustment) to the total number of votes possible in the system.

Each type of referendum has different requirements for these values. Most interestingly, though, these requirements can be reduced over time on a well-defined schedule. This means that as the vote takes place within 28 days, we can configure so that the required support and overall approval for the bill to pass will be lower and lower. In general, they always start and end in roughly the same way, starting with the highest threshold and ending with the lowest threshold, which still fits the general principle: at least 50% approval.

What happens in the middle determines how easy it is to get the bill approved before the 28-day deadline. Proposals that use less privileged sources (such as tips) will reduce the required turnout to a more realistic amount earlier than those using a highly privileged category (such as Root). Likewise, categories that are more political will tend to receive less controversy early on and thus require higher approval levels.

After approval

Proposals not approved after 28 days will be considered rejected by default. At this point, the decision deposit can be refunded. On the other hand, if a proposal is successfully passed within these 28 days and remains approved during the confirmation period, the proposal is considered approved and is scheduled to begin execution according to the source after the Enactment Period has elapsed.

The execution period is also specified at the proposal referendum, but is subject to the constraints of a minimum, which depends on the track. Some stronger tracks enforce extended enforcement periods to ensure that the network has enough time to prepare for any changes that the proposal might bring.


Sometimes a bill that has been voted on (and may be about to pass) contains obvious issues and people want to cancel it. An example of this is when a chain schedules an upgrade, only to later discover that it contains some kind of problem. While this is not common, it does happen from time to time.

In Gov2, there is such a special operation for intervening, called cancellation. This action immediately rejects an ongoing referendum, regardless of that referendum’s status. It actually comes in two forms, one that only operates, and one that also penalizes the initial proposer’s deposit for the referendum.

Cancellation is itself a governance operation that must be voted on by the network to execute. This brings up a possible timing issue, and to be practical, the passing of the cancellation motion must usually be much faster than the passing of the corresponding target motion. As a result, cancellations have their own sources and tracks, with shorter lead-in periods and faster drop-off thresholds for the approval/approval curve.

Flexible delegation

In a perfect world, everyone would have unlimited time and virtuosity, and everyone would research, discuss, consider, and vote on every proposal discreetly. However, we do not live in a perfect world. Not everyone has the time or willingness to dig into everything before voting. The Council in Polkadot’s original governance was born out of this realization: an institution commissioned by voters to compensate for the fact that many of them did not want to be involved in day-to-day governance. However, with the abolition of the council in Gov2, we need another way to ensure a voice for “passive” voters.

The original governance system had a feature called “voting delegation”, which we kept and improved in Gov2. If you’re not familiar with the concept, here’s an explanation, which is similar to the premise of liquid democracy: you can delegate your voting power to another voter in the system. When your delegates vote, they not only have their vote, but yours as well. This applies to belief voting, allowing you to lock your tokens to increase the level of voting weight your delegates exercise on your behalf. Of course, these tokens never leave your control, and you can switch delegates at any time, or take back direct control.

However, Gov2 improves upon this by introducing a rather special feature called “multi-role delegation”. This allows you to designate a different delegate for each type of referendum in the system. If you don’t want to delegate a referendum to a particular category, then you can also retain direct control over that category.

This means that you can delegate someone to handle a referendum on rewards for ecological contributors, an entity to handle a referendum involving large treasury expenditures, another entity to handle purely technical network upgrades and parameter setting, and retain control over any Direct control of other decisions!

Fellowship and Whitelisting

The opinion of knowledgeable “experts” plays an important role in any well-functioning governance system. Expert rule has its own rather serious flaws, so we don’t want “experts” to be put in command: this introduces the risk of centralization, irresponsible authority, and lays the groundwork for the eventual formation of a ruling group. Because of this, the technical committee of the first version of Polkadot has no “decision power”, only the ability to shorten the voting cycle.

All in all, it seems like a reasonable goal to make an informed opinion and allow it to help optimize the decision-making process, even if it has no direct impact on the outcome of the decision. It is crucial that the expert body must not in any way subvert the overall decision of the stakeholders for the benefit of all involved.

Root source motion is the type needed for upgrades, repairs, and remediation, but it necessarily has the ability to disrupt and destroy systems at will. In Gov2, because they are very dangerous, we pay special attention to safety, and early passing requires a very high level of approval and support, and can only be slowed down to the final level. The import and execution periods are also long. In general, this process will be slow, and this is to give everyone in Polkadot maximum notice to ensure that ineligible proposals don’t go through.

However, in some cases it is important to roll out the fix, upgrade or remediation logic in a shorter period of time. We might be able to assume broad consensus at these times, but the safeguards of the voting process described above mean that implementing such a fix may be difficult or impractical due to time constraints alone. Oraclizing the idea of ​​”experts agree: this operation is both safe and time-critical” can be a very useful tool for forming a clear process — a process that is generally well thought out, However, when there is sufficient evidence that the situation is urgent, decisions can be made within a tight timetable.

There are two more important questions to answer here: the chain (the deterministic block of logic) does not have the inherent ability to express or observe the concepts of “safety” and “time crunch”, so how does it recognize this situation? Even if it knows this is the case, how can we adjust our logic without compromising overall tractability and simplicity?


The answer to the first question lies in a new governing body. For those familiar with the old governance system, this body can be thought of as the logical successor to the technical committee.

It is named Polkadot Fellowship, and in general it is a very rich and complex structure, which can be detailed in another article. It will initially run on the Kusama network, as Gov2 will be deployed there first for live testing, but it will migrate to Polkadot when Gov2 is finally deployed, and it will then serve both networks via the Polkadot/Kusama bridge.

The Fellowship is a largely autonomous expert body whose primary goal is to represent people who are well-versed in the technical knowledge base of the Polkadot network and protocol. Unlike current technical committees, it has a wider membership (i.e. can accommodate tens of thousands of members) and has a much lower barrier to entry (both in terms of administrative processes and expectations of expertise). Becoming a Fellowship candidate is easy with a small deposit.

Given that membership is so broad, to help ensure high-quality collective decision-making, members are associated with ranks to represent the degree to which the system expects their views to be sensible, technically grounded, and in the interests of Polkadot. Members of the Fellowship may vote on any given Fellowship proposal, and the combined opinions of the members (weighted by their rank) constitute Fellowship’s consideration.

Even better, the technical means of voting in Fellowship are actually the same as the way Polkadot stakeholders vote in the referendum, with the exact same code (Substrate Pallet), and with the exact same facilities (multi-track, flexible delegation, etc.).

Levels and traps

Introducing the concept of hierarchy is fraught with pitfalls. However, if we demand decentralization, accountability, and the safety of all involved, we face relatively few choices. We believe that the openness, transparency, and anti-corruption afforded by decentralized consensus are used to ensure that no “ruler” itself is above the “rules” and that this hierarchy has clear expectations, rules, and accountability system, then it is reasonable. The downside of hierarchies is not only bad for the network, but also for the participants given some of the politicians’ recent policy stances on decentralization: if hierarchies allow a small group of participants to effectively control the network, they may be considered effective against the network. control and thus be responsible for what happens on the network.

So we stick to three principles: First, Fellowship must never have too much power over the network: it cannot change parameters, remediate, or move assets. With regard to network governance, its only power is to shorten the time it takes to conduct a referendum.

Second, the hierarchy and weights must be designed accordingly so that we do not expect a small group of people to capture and control the overall decision-making ability. While Fellowship gives more weight to those with higher ranks in the overall opinion, the weight should not be so high as to make the opinion of a few higher-ranking members insurmountable compared to the consensus opinion from members of the lower ranks.

Third, the Fellowship should be designed to increase and develop its members and their level of expertise, and to ensure that its overall decision-making ability strengthens over time. For long-term success, Fellowship must be an effective meritocracy that empowers those with commitment, talent and expertise to make a greater impact. To achieve this, we must make the process of admission and promotion clear and transparent. To the greatest extent possible, an individual’s identity should not be a consideration, but rather their abilities.

With this in mind, Fellowship will have a charter that specifically describes the requirements and expectations for individuals to attain and maintain any particular grade. According to this charter, higher tiers can vote and drive lower tier votes. Relegation occurs automatically when a member is unable to prove to his peers that he is competent for a period of time. Suspensions can only happen through a general (Polkadot) referendum, ensuring that disputes or unpopularity within Fellowship do not (necessarily) lead to dismissal. Also, in order to prevent Fellowship from becoming a Cabal, entry to the top ranks would also require a full (Polkadot) referendum that cannot be granted solely by Fellowship peers.


While Fellowship could potentially represent Polkadot’s community of human experts on-chain and provide a deterministic logic to capture their overall opinion, it may not be clear how this would be integrated into the overall referendum system. In fact, this is achieved by combining the concepts we already know with a very simple on-chain logic called the Whitelist Pallet.

The whitelist module does one thing: it allows one origin to elevate another origin’s permission level for specific actions. In Gov2, it allows Fellowship to authorize a new source (we’ll call it Whitelisted-Root) to execute with Root-level permissions. You can think of it as a kind of Unix sudo, but it only works with specific commands that Fellowship pre-authorizes. This means we can open up a new track in Polkadot’s governance for proposals to be whitelisted by Fellowship. If the referendum passes, then they will be executed within the whitelisted module with this Whitelisted-Root origin. The whitelisting module verifies two things: the source is indeed Whitelisted-Root (ie the referendum is indeed passed on that track), and that the proposal is indeed whitelisted by Fellowship. If so, it will go ahead and perform the operation with Root level permissions.

With this, we don’t need to change the way the referendum system works (great!). We now have a new track (for the Whitelisted-Root source) with parameters that allow for a shorter voting cycle, knowing that through an open and transparent process, the global body of experts on the Polkadot protocol has determined that this is both safe and time-critical.

Timeline and future work

Gov2 is about to launch on Kusama after a final professional audit of its code. Once tested on Kusama, a proposal is proposed for voting by the Polkadot network.

An update to the overall governance system, codenamed “Gov2.5,” is scheduled for final deployment in a few months. It will bring two key features: the first is a “pay-to-your-own” voting delegation feature, which allows users (through their wallets) to provide their funds for delegation without paying any transaction fees; instead, delegates can choose to pay transaction fees to Obtain entrusted funds. Second, free de-delegation transactions will be introduced, available to all delegating users within limits. These features allow the wallet to provide its users with a highly simplified and zero-cost governance integration, which we hope will attract more user participation in the overall governance process.

Posted by:CoinYuppie,Reprinted with attribution to:
Coinyuppie is an open information publishing platform, all information provided is not related to the views and positions of coinyuppie, and does not constitute any investment and financial advice. Users are expected to carefully screen and prevent risks.

Like (0)
Donate Buy me a coffee Buy me a coffee
Previous 2022-07-25 22:46
Next 2022-07-26 11:49

Related articles