Polkadot Governance

“Living is motion, and motion is change and alteration and therefore the only alternative to motion is un-motion, stasis, death.” — Faulkner

Polkadot and its parachains will all need to change over time to stay relevant, and we designed Polkadot to have a transparent and sophisticated process to not only approve or reject changes, but to enact them automatically.

All systems evolve or they die, and blockchains are not exempt from this universal law. The ease of administering change, the knowledge that someone can fix a problem or add a new feature, is one of the draws toward centralized systems. But to be sustainable over a long time, systems must decentralize. Economies that cut off trade flow, dictatorships that stop migration, and languages that don’t accept new words all die, or are already dead.

The common thread among these examples is a lack of agency, whether perceived or real. When people do not have the means to organize or express their voices, or when they think their voices are powerless, they exit. With a centralized company’s product, user agency could be as simple as feeling like product feedback, e.g. privacy concerns, is heard. In a nation state, agency could mean having the freedom to make your own future. Much debate over wealth inequality doesn’t revolve around inequality per se, but that the system is rigged.

Effecting change depends on what is changing. While change in decentralized systems takes different forms than centralized systems, humans have evolved ways to manage change. Languages, perhaps the most decentralized systems of all, can change by myriad methods, some prescriptive (e.g. l’académie française) and some descriptive, in which a language’s users take control and create a collective understanding of what a word means. Prescriptive changes often follow descriptive ones; for example, most English style guides now permit the “singular they”.

In linguistics, the idea of death relates to the rate of change of a language, not whether people still speak it. Linguists classify Latin as a “dead language”, even though it has speakers. Languages change over time because people invent or discover new things that they want to communicate, people want to express feelings in new ways, or new generations challenge long-standing worldviews.

Blockchains themselves challenge entrenched worldviews, and in order to do so, they need a way to evolve. This evolution has already happened; blockchains started out as a way to express financial transactions but quickly evolved to express zero-knowledge operations or abstract logic. Nobody knows how people will use blockchains in the future — but launching a new one with every new idea is not sustainable.

Blockchain governance frameworks have, so far, faced several problems. Forks split communities as well as software, and the dependence on security and adoption creates a zero-sum game where only one chain emerges. Some claim to have no governance at all, and groups can fork the network over parameters like block size and must defend their forks with religious fervor. Others use off-chain collectives that organize over phone calls or at conferences, which either leads to shadow hierarchies where only a few, unwritten people make decisions or, lacking a framework to make a decision, the collective never advances. These problems have led some to implement coin-voting protocols to make decisions. Coin voting is a good first step toward transparent, open, on-chain governance, but low turnouts make it susceptible to large voters controlling a vote. In all blockchains to date, governance stops at decision making. Even if a collective or a coin vote leads to an agreement, they lack the means to enact their decision; the true power still lies outside the protocol, for example with miners or validators. Just because a country holds elections, for example, doesn’t mean people consider it a democracy; the system must include the means to enact the outcome. The same applies to blockchains. Coin voting is not sufficient if it is not binding.

With Polkadot’s main goal of uniting blockchains, we designed Polkadot so that users can express their wishes on-chain in a way that will maintain and update the system without forking.

The Origin of Collectives

Polkadot has several ways for users to express their wishes for change. Besides making it easy for users to propose changes, Polkadot provides the structure for users to form collective groups that carry unique privileges. The motivation behind collectives comes from seeing votes in other decentralized protocols or applications controlled by a single voter. These decisions have included sensitive topics like killing the application.

Stakeholders should ultimately have the control, which is why all changes in Polkadot go through public referenda, but stakeholders should also have the capability to elect representation for such decisions. Collectives protect masses of more passive users from the whims of a single, large token holder.

Polkadot has two special collectives related to governance: the Council and the Technical Committee. By meeting certain criteria, these two collectives can call privileged functions that affect how a proposed change goes to a referendum. Polkadot expresses privilege using origins. In most cases, e.g. your typical balance transfer, the origin is just the account that sent the transaction. But Polkadot can express different origins under certain conditions, like having two-thirds of a collective submit the same transaction, and call functions once they have attained the elevated origin.

As an example of a privileged function, the Nominated Proof of Stake (NPoS) system has a function that cancels queued slashes [1] and requires a “Slash Cancel” origin, which exists when at least 75% of the Council approves of canceling the slashes.

The Council

The Council is an on-chain collective that exists to represent passive stakeholders. It does this by proposing important changes and canceling uncontroversially dangerous proposals. Any DOT token holder can run for Council, but their reputation is at stake to act in good faith for the network.

Polkadot will launch with a Council with thirteen seats and gradually expand to 23. Council elections use an approval voting scheme where users can vote for any number of candidates that they support. The election uses the same Phragmen process as validator selection to choose councillors by selecting the most-backed configuration. Phragmen is an approval voting method where users select all acceptable candidates and the vote counting algorithm finds the set of councillors that have the most cumulative backing, the most acceptable Council.

The Council election also accounts for the order that users vote for councillors by scoring them based on how many they are ranked ahead of. The councillor with the highest score is the prime councillor; if the prime votes aye, then that applies to all abstainers at the end of a Council voting period. [2]

The Council keeps its own proposal queue, separate from the public, and votes on which one should have the top priority for the next referendum. Besides normal proposals and special Council proposals (like canceling slashes), the Council also has access to Polkadot’s Treasury. The Treasury is an account that accumulates funds by inflation as well as by taking a portion of transaction fees and slashes. The Council can make and pass proposals to spend these funds for developers, community engagement, or more complex activities like using bridges and decentralized exchanges to trade its own DOTs for other tokens.

When the Council votes on its own proposals, votes are counted by member, not by stake. This makes it difficult for large holders to exercise undue power in Polkadot’s governance; they may be able to get themselves on the Council, but they can’t swing a low-turnout referendum.

In addition to its normal proposals and Treasury operation, the Council can send transactions from two more special origins. First, if the Council approves of a proposal with a unanimous vote, then the proposal will have a lower passing threshold in the public referendum. Second, a two-thirds majority can decide to cancel a proposal that it finds dangerous. A dangerous proposal could either be malicious or simply a bug discovered in a proposal that is already in referendum. [3]

The Technical Committee

The Technical Committee serves as Polkadot’s last line of defense against software errors. Unlike the Council, the Technical Committee is not elected by vote, but rather selected by the Council based on having provided a formal specification or client implementation of the Polkadot protocol.

The Technical Committee cannot make proposals themselves, but rather can fast track existing proposals to happen in a shorter time frame than normal. If unanimous, then the Technical Committee can skip the enactment delay (more on that later) and enact the proposal as soon as it passes.

Although the Technical Committee is not elected, they have a limited scope, and the proposals that they fast track still need to go through a public referendum. They can only make governance for critical bug fixes happen faster than normal, but cannot control the network.

Proposals: The Seeds of Change

All governance decisions begin as a proposal and pass through a public referendum. A proposal can be any one of a set of privileged functions that are not available to most users. Some of these are simple, like setting the balance of an account. Others set system parameters like the number of validators. The most powerful functions can change the logic of Polkadot itself.

Proposals can start in three ways, namely:

• From the public, as in any DOT token holder
• From the Council, which consists of publicly-elected DOT token holders
• As the result of the enactment of another proposal

Regardless of the origin, a proposal starts as merely the hash of the privileged function call; the actual proposal — the preimage of the hash — must be registered separately with a fee relative to its size. This separation prevents an attack where a user could make proposals that take up large amounts of space in the chain’s database. The proposer can supply the preimage off-chain for token holders to discuss. With this method, a user with little funds still has the power to make large proposals, as long as some larger token holder supports it enough to register its preimage and make the deposit necessary to place it on chain.

Any number of public proposals can exist simultaneously, but only one can make it to a public referendum during each voting period to avoid conflicts, e.g. one proposal to set the validator count to 500, and another to set the validator count to 600. Users can “second” proposals that they support by locking tokens behind them, and the governance logic will select the most-supported proposal for a referendum.

Public Referenda

A core tenet of Polkadot is that a majority of stake, defined as the total number of tokens in issuance, can always command the network. Blockchains are economic vehicles and do not understand democratic one-person-one-vote systems. [4] Those who want influence in the direction of the system must take an active stake in it.

Proposals must pass through a public referendum where all stakeholders can express their opinion. Every thirty days, Polkadot’s governance system autonomously selects the next proposal to go to referendum by alternating between awaiting Council and public proposals to ensure that public proposals have an equal chance of reaching referendum.

Once a referendum begins, users can begin voting. But unlike other blockchains, votes are not strictly the number of tokens in an account. Every vote comes with some conviction, some skin in the game. By default, users who voted for a passed proposal must lock tokens up until the proposal’s enactment. This lock makes them stay in the network and endure the ramifications of their vote, while those on the losing side of the referendum are free to exit. But users can increase their voting power by committing to the decision for a longer period of time and thereby increasing their exposure to the outcome. Each doubling of the lock time increases the power of a user’s vote, all the way up to six times the account’s balance (which would be a lock of 32 enactment periods). [5] This mechanism exists to ensure that users with little stake but strong opinions can express their conviction in referenda.

At the end of the voting period, Polkadot tallies the votes and calculates the result. If the proposal passes, then Polkadot’s logic automatically schedules it for enactment, normally 30 days later to give time for external services to make any necessary adjustments and for those who oppose the decision to exit. Fast-tracked referenda, presumably for an emergency technical fix, can take effect immediately.

Adaptive Quorum Biasing

In the name of decentralization, Polkadot allows anyone to propose new ideas, but this comes with a certain volatility. One of the comforts of a centralized system is that not anyone can propose new ideas. Adaptive quorum biasing allows Polkadot to facilitate efficient change in a way that protects against volatility.

All public proposals use what is called positive adaptive quorum biasing, meaning that as the referendum turnout increases, the threshold of aye votes required to pass it lowers. Since making a protocol change comes with risk, this system was designed to favor the status quo. The outcomes of many controversial votes — e.g. Brexit, U.S. elections — would reverse only days later. Positive biasing ensures that only uncontroversial proposals pass. Even though referenda that use positive adaptive quorum biasing require a supermajority to pass when voter turnout is low, as turnout increases the passing threshold becomes a simple majority. This preserves the core tenet that a majority of stake can always command the network.

Council proposals normally use a simple majority vote threshold. Since the proposal has already been vetted by the Council, Polkadot accepts the risks of a simple majority vote to make the decision. The only referenda that use a negative bias are those for which the Council has passed a unanimous vote. These require a supermajority of the public to reject the change, but again, as turnout increases it becomes a simple majority.

Enactment

So far, a proposal has moved from some origin, whether that be the Council or the public, and through Polkadot’s voting system, where stakeholders either approved or rejected the proposal. Governance structures must make those in power account for their decisions, and Polkadot does this through two mechanisms: token locking and autonomous enactment.

After voting on a referendum ends, successful proposals enter a lock period prior to enactment; rejected proposals are simply discarded. Remember that all votes in a referendum have an associated conviction. Those on the winning side are locked in and cannot transfer their tokens until the end of their lock period.

After waiting through the enactment period, a successful proposal’s journey reaches its apotheosis: autonomous enactment. In other systems, miners or validators often have unilateral power to prevent protocol changes by refusing to upgrade software. Not so in Polkadot. At the end of the enactment period, Polkadot executes the proposal without any human interference.

Enacting System Upgrades

The most powerful governance act of all is a runtime upgrade. A blockchain’s runtime contains the types of information it stores and the logic that users can access to change that data. It is the interface to the user, the state transition function, the business logic, the DNA.

Most proposal enactment takes place by updating the appropriate storage items in the blockchain’s database, e.g. changing the validator count. Runtime upgrades are the same — Polkadot stores the runtime logic in its own database and includes a privileged function to change it — but upgrades also rely on one more facet of Polkadot’s design. From a high level, a Polkadot client has two parts: the host and the runtime. The host contains all the infrastructure to execute the runtime, specifically a WebAssembly execution environment. There are infinite ways to implement a host, and indeed several teams building Polkadot hosts. But there is only one runtime: because the runtime exists in state, nodes must agree on it to be on the same chain. In this way, Polkadot can upgrade without users installing upgrades.

Kusama was the first blockchain to enact an upgrade in such a way. Autonomous enactment makes Polkadot an autopoietic system — one capable of generation through its interactions and processes — like a programming language that compiles itself or an organism that evolves. More important, on-chain governance and autonomous enactment give the token holders agency, the vehicle to express their opinions and the guarantees about the impact that their expression has. External groups cannot cause a hard fork just because they don’t like the proposal. Validators must verify transactions in the protocol, and changing the protocol itself is a transaction, making any validator who manually prevents enactment in violation of the protocol.

On-chain governance and autonomous enactment give the token holders agency, the vehicle to express their opinions and the guarantees about the impact that their expression has.

Governance Beyond the Relay Chain

This article has focused on governance of the Relay Chain. Governance, however, operates alongside other systems like staking, which locks tokens to secure the network. Users can lock the same tokens for multiple purposes, meaning the same account can have its tokens bonded to participate in NPoS and still vote in referenda. The proposal enactment delay of 30 days is longer than the staking unbonding period of 28 days so that stakers who are unhappy with the outcome of a referendum can stop staking and unbond.

In addition, Polkadot isolates staking and governance. Other PoS protocols apply transitive rights to validators to vote on behalf of their backers. In Polkadot, nominating a set of validators does not give them any voting power in referenda or prevent the nominator from voting on their own. Validators exist to guarantee availability and validity of state transitions for Polkadot’s shards, its parachains and parathreads, not to govern the changes of the Relay Chain’s runtime.

To date, most accounts on blockchains represent either individuals or smart contracts. So one might make the tacit assumption that users and stakeholders are individual token holders. But in Polkadot, parachains are the primary user of Polkadot’s security and they have their own accounts on the Relay Chain with locked tokens. With Polkadot’s locking system, parachains can have their own logic of how to use their locked tokens to vote in referenda. Further, parachain logic could control an individual’s DOT tokens but still allow them to express their votes through the parachain. [6] For example, a parachain without its own native token could give users a deposit address for DOTs and issue local representative tokens for use within the parachain.

Looking beyond the Relay Chain, each of Polkadot’s parachains also has its own runtime that it stores in its own state. When a validator checks a parachain block, the validator executes the block according to the unique runtime of the parachain to which the block belongs. But to the validator, the parachain’s runtime is just an abstract “blob” of bytes, a WebAssembly function called “execute block”; in this sense, all parachains look the same. The magic here is that each parachain can implement its own governance logic, totally free of Relay Chain influence, to update its runtime. The ability to secure unique and independent blockchains makes Polkadot a united network of sovereign systems.

Polkadot’s governance system provides several mechanisms to effect change, a transparent and open voting system that prevents individual holders from wielding too much power, and an autonomous enactment system that ensures that the people’s decisions are binding. To learn more about Polkadot and the topics covered in this article like Phragmen elections and adaptive quorum biasing, visit the Polkadot Wiki↗.

Notes

[1] When the system detects slashable behavior, it puts those slashes in a queue and applies them later, so there is a chance to cancel a slash after detection but before application. Why Polkadot doesn’t immediately apply slashes is a story for another article.

[2] Council proposals come with a cardinal-based passing threshold, e.g. “16 of 23”, so abstaining is equivalent to voting nay.

[3] In the case of controversy, the Council can only cancel a proposal once, so the public can still override the Council by voting on a cancelled proposal again.

[4] This deserves a big fat footnote because in the introduction I used the example of a sham democracy to forward the argument that a person’s vote must come with some power. Blockchains have no way to hold one-person-one-vote elections and remain permissionless at the same time. A blockchain can’t understand citizenship the way a democratic country can. Rather, a blockchain understands its own tokens as its primary means of interaction with the outside world. The counter to that is that the blockchain has no means of preventing a person from becoming a “citizen” the way a country does, meaning anyone can have a voice. Certainly some global democratic superpower makes decisions that affect your life but does not provide you the means to express your voice in the matter unless you are a citizen. Anyone can take a stake in Polkadot, and the protocol provides the primitives that make holding stake meaningful.

[5] Users can also vote without a lock, but receive only 10% of the normal vote strength.

[6] One thing parachains cannot do with these accounts is participate in staking. The opportunity cost of not staking is the cost of leasing a parachain slot.

Stay up to date

To keep up with the continuing governance changes on Polkadot, join the Polkadot Direction Riot↗ channel.

We have provided lots of ways for members of the wider Polkadot community to keep up to date with what’s going on. Join us on your favorite Medium.

Join the discussion on Telegram↗ and Riot↗, or subscribe to Polkadot’s newsletter↗. Learn more about Polkadot in the Polkadot Lightpaper↗ and the Polkadot Wiki↗. Looking to validate on Polkadot? Join Polkadot’s validator lounge↗ on Riot.