Polkadot OpenGov: Polkadot’s Next Generation of Decentralised Governance

Polkadot’s first decentralised governance system was pretty interesting at the time: a tri-cameral (three-chamber) structure with a technocratic committee managing upgrade timelines, an approval-voted, elected executive “government” to manage parameters, admin and spending proposals as well as a general voting system for everything else which rewarded long-term stakeholders with increased influence. It was loosely based on parliamentary democracy and has been functioning reasonably well over the first 2–3 years of operation, helping ensure good use of treasury funds, keeping a fast clip with the rollout of upgrades, and managing the deployment of more critical fixes in a timely fashion. However, it has its drawbacks.

The elected executive (known as the Council) is centralised and generally not anonymous. This puts both the protocol in some degree of risk as well as the individual councillors who may find themselves pressured to act one way or another. The Technical Committee, while wielding substantially less power, has similar exposure and greater centralisation. In a world where authorities across society (both benign and malevolent), decentralisation is increasingly needed for both the safety and security of all participants.

Furthermore, there exists only a single “all or nothing” referendum model — all referenda carry the maximum amount of power. Partly due to this, there can only be one referendum voted at a time and these votes last multiple weeks by default. This, and the limited bandwidth of the Council means that overall the system favours deep consideration of very few proposals rather than broad consideration of very many. Rather than leveraging the power of the crowd, it inadvertently limits it in its efforts to manage the volume of potential decision throughput.

The nature of coarse-grained delegation means that the system has a degree of exclusivity built-in to it. Barriers to entry within the effective political framework are high, reducing inclusivity and diversity, hurting turnout and legitimacy.

It was always clear that the first version of Polkadot’s governance was just that: something to be iterated on over time. Now, I’m happy to be able to describe in detail our proposal for the next generation of governance within the Polkadot ecosystem.

Introducing Polkadot OpenGov

Polkadot’s next-generation governance system, known while in development as Polkadot OpenGov, aims to solve the issues with the current system. First, what it doesn’t change: it does not break from 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. Similarly, it doesn’t break away from the Conviction Voting pioneered in Polkadot giving greater weight to those who are willing to lock their tokens into the system for longer. Furthermore, there is still use for a technocratic collective, albeit it is somewhat different in importance, size, composition and membership mechanics than the current Technical Committee.

Where it differs most is how it manages the practical means of day-to-day decision-making, making the repercussions of referenda better scoped and agile in order to dramatically increase the number of collective decisions the system is able to take. Let’s look a little deeper into how it works.

Lower the Barriers

Polkadot OpenGov is actually a lot simpler in many ways than the current governance. There are no additional bodies which act as “first class citizens” in the governance such as the Council and Technical Committee. There is no alternating timetable of proposals. There is no public proposal queue. Instead, we only have one first-class decision-making mechanism: the referendum. The main difference in Polkadot OpenGov is that there can be lots of them — perhaps even thousands —all happening simultaneously.

In Polkadot OpenGov, anyone is able to start a referendum at any time, and they can do this as many times as they wish. Anyone can also vote on these referenda. There are no explicit limits on the number of referenda which are open to vote on at any time.

But this could result in more things to vote on that a normal person with a reasonable amount of time could possibly evaluate. This could reduce both inclusivity and security. So, in order make this potential plethora of things to vote on manageable for mere humans, we introduce some interesting novel features to the referendum process.

Origins and Tracks

All referenda are based on a proposal, which is really just another way of saying “an operation” in Polkadot. This is the same kind of thing as what gets described and executed when you make a transaction and it gets included in a block. There are all kinds of operations which Polkadot can do, but a couple which you’re probably already familiar with are transfer which can move assets between accounts and stake which lets an account stake. There are very many others. The thing that makes this governance functionality special is not these proposals/operations, but rather the Origin with which they are executed.

You can think of an Origin as a sort of rich descriptor for a privilege level. It gets passed in when an operation is executed, and the operation’s logic will usually check that it is what it should be. When a regular transaction executes, the Origin parameter is set to a variant known as Signed. This implies that a specific account in the system authorised (generally through signing the transaction) the operation to happen, and it runs with this privilege, further implying e.g. that funds controlled by this account and this account only may be spent.

Governance-level stuff works to allow operations to run with other, more privileged, Origins. The most privileged of them all is the Root Origin, which is all-powerful. This is the Origin from which the proposals of all approved referenda in the old governance system were dispatched. In Polkadot OpenGov, we have many different Origins, all enjoying some exotic privileges, but with many being significantly less powerful and more niche than Root.

In Polkadot OpenGov, we allow the proposer to specify which Origin they would like their proposal to be executed with. Every supported Origin is associated with a single referendum class (i.e. a type of referenda), and most of these classes will correspond to exactly one origin, but there might be some which are comprised of multiple Origins. Each class has its own Track, which is basically a pipeline in which the proposal lives in and proceeds through, and it is completely independent from other class’s tracks.

Having independent tracks allows us to tailor the dynamics of referenda based upon their implied privilege level. Referenda which execute their proposals from more powerful (read: dangerous!) Origins will have more stringent safeguards, higher thresholds and longer consideration periods. The Root Origin has the highest such thresholds and safeguards. Those Origins which convey relatively little power (e.g. the Tip Origin, able to spend at most 10 DOT from the treasury), have accordingly shorter consideration periods and lower thresholds for approval.

Kicking off

When a referendum is initially created, it is immediately votable by anyone in the community. However, it is not in a state where it can end, or otherwise have its votes counted, be approved and summarily enacted. Instead, referenda must fulfil a number of criteria before they are moved into a state known as Deciding. Until they are in this state, they remain undecided.

The criteria which need to be met are threefold: Firstly, all referenda have a lead-in period. This is an amount of time which must have elapsed after proposal before deciding can begin. This provides for an initial notice period in which votes can be submitted to mitigate against the possibility of “decision sniping” where an attacker controlling a substantial amount of voting power might seek to have a proposal passed soon after proposing it, not allowing the overall voting population time to consider and vote.

Secondly, there must be room for the decision. All tracks have their own limit on the number of referenda which can be deciding simultaneously. The more potent the Origins allowed on the track, then the lower this limit. The Root level Origin has a limit of one, implying that only a single über-dangerous proposal may be being decided at once. Conversely, the rather underpowered Tipping track has far less stringent limits since any damage done through over-population of is minimal and it is far more useful to have many tips being decided at once over many Root-level calls. When there is space available, then it is the (otherwise eligible) referendum of the class which has the most votes in favour of approval which is elevated into the deciding state.

Finally, a Decision Deposit must be paid. Creating a referendum is cheap, with the deposit needing to be paid relating only to the on-chain storage needed to track it. However, having a referendum be decided upon carries greater risk and uses up limited space since we limit the number of referenda which can be being decided simultaneously on each track. Thus a larger (though refundable) deposit must be paid to mitigate against spamming or bloating the system.

Deciding and Confirming a Proposal

Once a referendum enters the state of deciding, then it is eligible to be approved. This eligibility lasts only a finite time (28 days on Polkadot), at which point if it is not approved then it is rejected by default. To be approved, it must fulfil two criteria (in which case we say it is passing) and it must continue fulfilling these criteria for a minimum of the Confirmation Period. Different tracks have different lengths of Confirmation Period, with the more powerful ones taking longer to confirm. This is additional defence against a whale voter attempting to “snipe” the referendum by placing a large enough vote that approval criteria are hit unexpectedly.

The two passing criteria relate to approval and support. Gone is the adaptive quorum biasing of past referendums. Now we have a more flexible system where these requirements may be customised at a much more fine-grained level. Approval is defined as the share of approval vote-weight (i.e. after adjustment for conviction) against the total number of vote-weight (for both approval and rejection). Support is the total number of votes in approval (i.e. ignoring any adjustment for conviction) compared to the total possible amount of votes that could be made in the system.

Each class of referendum has different requirements for these values. However what is most interesting is that these requirements are able to reduce over time on a well-defined schedule. What this means is that as the voting proceeds over the 28 days, we can configure things so that an increasingly lower amount of support and overall approval for the proposal are needed for it to pass. In general, they will always begin and end in roughly the same way, starting with the highest thresholds and ending with the lowest which are still in line with the overall tenets: at least 50% approval.

What happens in between determines how easy it is for an approval to be made before the 28-day deadline. With proposals which use less privileged origins (e.g. the Tip class, which is only able to command a payment from the treasury of up to 10 DOT) it is far more reasonable to drop the required turnout to a more realistic amount earlier than those which use highly privileged classes such as Root. Similarly, classes which command more political significance will tend to accept less controversy (and thus require a higher approval) early on.

After Approval

Proposals which are not approved after 28 days are considered rejected by default. At this point, the Decision Deposit can be refunded. If, on the other hand, the proposal manages to become and remain passing for the Confirmation Period during these 28 days, then it is considered approved and it is scheduled to execute from the origin is was duly proposed with, after some Enactment Period.

The Enactment Period is also specified when the referendum is proposed but is subject to a minimum value which is dependent on the track. Some of the more powerful tracks force a larger Enactment Period to ensure the network has ample time to prepare for any changes that the proposal might bring.

Interventions

Sometimes it becomes apparent that a proposal which is already being voted on (and perhaps is already passing) contains a problem and it is desirable to cancel it. An example of this would be a chain upgrade which was later discovered to contain some sort of issue. While this is not very common, it is also not entirely unheard of.

In Polkadot OpenGov, there is a special operation for intervening in this way known as Cancelation. This operation immediately rejects an ongoing referendum regardless of its status. It actually comes in two forms, with one just doing the bare operation and the other also slashing the initial proposer of the deposit(s) paid for the referendum.

Cancelation is itself a governance operation which must be voted upon by the network in order to execute. This poses a possible problem of timeline, and in order to be useful, getting a cancelation proposal passed must generally be quite a lot faster than any possible target proposal passed. As such, cancelation comes with its own Origin and track, which has a low lead-time and approval/support curves with slightly sharper reductions in their thresholds for passing.

Agile Delegation

In a perfect world, where everyone had unlimited time and virtuosity, everybody would research, discuss, consider and carefully vote on every proposal. However, in a perfect world we do not live. Not everyone has the time or inclination to make a well-researched vote on every matter. Out of this realisation, the Council was born into Polkadot’s original governance: a body delegated by voters to make up for the fact that many of them did not want to take part in the day-to-day of governance. However, with the Council gone in Polkadot OpenGov, we need an alternative means of ensuring “passive” voters are heard.

The original governance system had a feature called Vote Delegation, which we have retained and improved upon in Polkadot OpenGov. For those not familiar, this is similar to premise of liquid democracy: you are able to delegate your voting power to another voter in the system. When your delegate votes, they wield not just their own voting power but yours too. This works with conviction voting, allowing you to lock up your tokens in order to increase the level of voting power your delegate wields on your behalf. Of course the tokens in question never leave your control and you are free to switch delegates or regain direct control back whenever you please.

Polkadot OpenGov, however, improves on this with a rather special feature called Multirole Delegation. This allows you to specify a different delegate for every class of referendum in the system. If you do not want to delegate for a particular class of referendum then you can also retain direct control for that class.

This means you can delegate to one individual for any referenda on dealing out small tips to ecosystem contributors, another entity for referenda on more substantial treasury spending, another entity for purely technical network upgrades and parameterisations and finally retain direct control for any other decisions!

The Fellowship and Whitelist

Well-informed “expert” opinion plays an important role in any well-functioning governance system. A technocracy comes with its own rather serious flaws and thus we would not want “experts” to be placed in a position of command: it introduces risks of centralisation, unaccountable authority and lays the groundwork for what could become ultimately a ruling cabal. It was for this reason that Polkadot’s original governance’s Technical Committee has no “deciding power” but only the ability to reduce the voting period.

That all said, oraclising well-informed opinion and allowing it to help optimise the decision-making process, even if it has no direct effect on the decision-making outcome seems like a reasonable goal to strive for. Crucially, and for the sake of all involved, it must not be possible in any way for the expert body to subvert the overall stakeholder decision.

Root-Origin proposals are the sort which are needed for upgrades, fixes and rescues, but which necessarily have the power to arbitrarily break and corrupt the system. In Polkadot OpenGov, because they are so dangerous, we err on the side of safety and have extremely high levels of approval and support needed for early-passing and which reduce to their final levels only slowly. The lead-in and enactment periods are also large. In general the process is slow, and this is to give everybody in Polkadot the maximum amount of notice to ensure that bad proposals don’t make it through.

However, there are occasions where it is important to roll out a fix, upgrade or rescue logic in a shorter period of time. We may be able to assume there is broad consensus in these times, but the safeguards on the voting process above mean that executing such a fix can be difficult or impractical due to time constraints alone. Oraclising the idea that “the experts agree: this is both safe and time-critical” can be a very useful tool in forming a clear process which is well-considered in the general case but able to make decisions on a tight timeline when there is good reason to believe that circumstances require it.

There remain two big questions to answer here: how could the chain (a deterministic blob of logic with no inherent ability to express or observe concepts as “safe” and “time-critical”? And even if it could know of such circumstances, how do we adapt our logic without compromising our overall tractability and simplicity?

The Fellowship

The answer to the first question lies in a new governance body. For those familiar with the old governance system, this body can be thought of as the logic successor to the Technical Committee.

It is named the Polkadot Fellowship, and in totality is a sufficiently rich and sophisticated structure that it will form the subject of a whole other article. It will initially run on the Kusama network, since Polkadot OpenGov will be deployed there for live-testing purposes, however it will be migrated over to Polkadot with the final Polkadot OpenGov deployment and once there it will serve both networks via the Polkadot/Kusama bridge.

The Fellowship is a mostly self-governing expert body with a primary goal of representing the humans who embody and contain the technical knowledge base of the Polkadot network and protocol. Unlike the current Technical Collective it is designed to be far broader in membership (i.e. to work well with even tens of thousands of members) and with far lower in barriers to entry (both in terms of administrative process flow and expectations of expertise). Becoming a candidate member in the Fellowship is as easy as placing a small deposit.

In order to help ensure a high quality of collective decisions in light of such a broad membership, members are associated with a rank to designate the degree to which the system expects their opinion to be well-informed, of a sound technical basis and in line with the interests of Polkadot. The members of the Fellowship can vote on any given Fellowship proposal and the aggregate opinion of the members (weighted by their rank) constitutes the Fellowship’s considered opinion.

Beautifully enough, the technical means by which the Fellowship votes is actually exactly the same code (Substrate pallet) as the means by which the Polkadot stakeholders vote in a referendum and it has exactly the same facilities (multiple tracks, agile delegation, &c).

Ranks and Pitfalls

Introducing the concept of rank is fraught with pitfalls. However, we are presented with relatively few options if decentralisation, accountability and safety for all involved are our requirements. We believe it is reasonable to utilise the openness, transparency and corruption-resistance that decentralised consensus brings to ensure that any “rulers” are not themselves above the “rules” and that rank comes with clear expectations, rules and accountability. The downsides of rank are not just bad for the network but also, in light of some recent decentralised-technology policy positions of politicians, are also bad for the participants: if rank allowed a small group of participants to have effective control over the network they could be considered in effective control of it and thus responsible for what happened on it.

As such, we adhere to three principles: firstly, the Fellowship must never have hard power over the network: it cannot change parameters, conduct rescues, or move assets. Concerning governance over the network, the only thing in its power is to reduce the effective timeline on which a referendum takes place.

Secondly, the rank system and weights must be designed so that we would not expect small groups of individuals to be able to capture and control overall decision-making capacity. While the Fellowship weights those with higher rank more in the aggregate opinion, the weight should not be so high as to make a small number of higher members’ opinions be insurmountable when compared to a coherent opinion coming from lower-ranked membership.

Thirdly, the Fellowship should be designed to grow and develop its membership and their aggregate levels of expertise and in doing ensure that its overall decision-making capacity gets stronger over time. For long-term success, the Fellowship must be an effective meritocracy where those with commitment, talent and expertise rise to greater levels of influence. To achieve this, we must give clarity and transparency to the process of entry and promotion through the ranks. To the highest degree possible, an individual’s identity should not form a consideration, only their ability.

In light of this, the Fellowship will have a constitution which describes in specific terms the requirements and expectations for individuals to attain and retain any given rank. Higher ranks are able to vote and promote lower ranks voting based on this constitution. Demotion happens automatically after a period in which a member is unable to defend their position to their peers. Suspension can happen only through general (Polkadot) referendum, providing a means of ensuring that controversy or unpopularity within the Fellowship does not (necessarily) result in expulsion. Furthermore, to guard against the chance of the Fellowship becoming a cabal, entrance into the top tiers of ranks also requires a full (Polkadot) referendum and cannot be bestowed merely by ones Fellowship peers.

The Whitelist

While the Fellowship may be able to represent Polkadot’s body of human experts on-chain and provide a piece of deterministic logic from which to source their aggregate opinion, it may be unclear how we can integrate this into the overall referendum system. In fact, this is achieved using a combination of concepts we already know and a wonderfully simple piece of on-chain logic called the Whitelist pallet.

The Whitelist pallet does one thing: it allows one Origin to escalate the privilege level of another Origin for a certain operation. In terms of Polkadot OpenGov, it allows the Fellowship to authorise a new origin (which we will call Whitelisted-Root) to be executed with Root-level privileges. You can think of it as a sort of Unix sudo, except that it only works with specific commands that the Fellowship have pre-authorised. What this means is that we can have a new track in Polkadot’s governance which is for proposals which will have been whitelisted by the Fellowship. If the referendum passes, then they will be executed inside of the Whitelist pallet with this Whitelisted-Root origin. The Whitelist pallet verifies two things: that this origin really is the Whitelisted-Root (i.e. that the referendum passed on this track) and that the proposal has indeed been whitelisted by the Fellowship. If so then it goes ahead and executes the operation with Root-level privileges.

With this we don’t need to change anything about how the referendum system works (yey!). We now have a new track (for the Whitelisted-Root origin) whose parameters allow for a shorter voting turnaround, safe in the knowledge that through an open and transparent process, a body of global experts on the Polkadot protocol has determined that this is both safe and time-critical.

Timeline & Future work

Polkadot OpenGov is set to launch on Kusama imminently, following final professional audit of its code. Once tested on Kusama, a proposal will be made for the Polkadot network to vote on.

An update to this overall governance system is planned for eventual deployment some months afterwards. It will two bring key features: firstly a “collect-call” feature for vote delegation, essentially allowing users (via their wallets) to offer their funds up for delegation without paying any transaction fees; instead the delegate would be able to optionally pay the transaction fees to get the funds delegated. Secondly, a free undelegation transaction will be introduced, able to be used in a limited capacity by all delegating users. Together these features enable wallets to offer a highly streamlined and zero-cost governance integration to their users, which we hope will entice more involvement in the overall governance process from users.