Note: Everything described here is subject to change before Polkadot’s initial mainnet launch, which is targeted for the end of 2019 depending on security audits and launch provisions outside of our control. It is also very likely that once Polkadot goes live, the network will upgrade the governance mechanisms described here. To stay up-to-date, follow Polkadot on Twitter for future announcements or keep an eye on the Polkadot Wiki, where the details of the governance mechanisms will be updated
Polkadot institutes a cutting-edge governance model designed to achieve a healthy network that adapts to its users' needs. It is designed to enable rapid and representative community engagement by leveraging blockchain technology for transparency and accountability. The DOT token enables low-friction engagement in Polkadot and provides an innovative level of sophistication and participation in distributed global governance.
Making upgrades to distributed protocols is an undertaking that traditionally requires massive coordination efforts, creating expensive overhead for enacting new features and making it difficult for changes to be adopted, regardless of how contentious a proposal may be.
Evolvability is paramount to the long-term viability of any useful product and blockchains are no different. Being decentralized, there is no trivial means to determine how the network product should evolve over time: governance is critical to ensure orderly and schism-free evolution. Decentralized crypto-economic systems will become the new states of the internet world and governance is key in ensuring these crypto-economic systems’ resources work in its (and its stakeholders’) interests.
There are many definitions of governance, especially as of late in the blockchain space, so it is important to agree on the foundational principles of governance. Wikipedia defines governance as, “the way rules, norms and actions are structured, sustained, regulated and held accountable.” The United Nations says, “Governance has been defined as the rules of the political system to solve conflicts between actors and adopt decision.”
The common factors boil down to governance being:
- A system of rules
- To make decisions
- With participants being held accountable
These factors make up the rules that govern a system, or the rules over a system, rather than within a system. For example, the rules that define a valid transaction in Polkadot do not fall under “governance,” but the rules that decide how to change the rules of a transaction format do fall under the notion of governance.
A clearly outlined governance system allows participants to clearly understand the methods, requirements and steps to enact a change. A formalized system that is encoded on-chain ensures that these rules are followed and actors are accountable. Because adopting formalized rules for informalized systems in-situ is extremely difficult, Polkadot will launch with a sophisticated set of formalized rules upon genesis.
At the core of Polkadot governance is the notion of stake-weighted voting, where DOT holders vote with their stake on referenda proposed by the community. All changes to Polkadot require a stake-weighted majority to be agreed upon. This is performed using sophisticated mechanisms, detailed later in this article, that differentiate highly from other recent coin-voting mechanisms appearing in this early stage of on-chain governance blockchains.
Keep in mind, however, the rules set at the beginning of Polkadot can change later to provide improved representation and enactment as the community learns from experiences in governing a large network.
Participants in Polkadot governance
So who are the participants in Polkadot governance?
At the heart of Polkadot governance is the DOT token, enabling low-friction and direct interaction with proposals set forth by the community. DOT holders vote on proposals with their tokens, and increase the weight of their vote by locking up DOTs with their vote for extended periods of time.
DOT holders can use their DOTs in Polkadot governance in the following ways:
- Propose a public referendum
- Prioritize public referenda
- Vote on all active referenda
- Vote for council members
- Become a council member
DOTs also allow participants to stake their DOTs to validate on the network, or engage in the voting for validators, called “nominating”. More details of Polkadot’s Nominated-Proof-of-Stake system can be found here.
Decentralized public networks that have attempted to formalize specific voting methods often run into the issue of low voter turnout. This is also an issue in traditional governance systems, where unless highly politicized issues are given to the public, public referenda are very unlikely to gain a sizable turnout.
To represent passive stakeholders who may not be able to vote on every referenda, Polkadot introduces the Council, a body of 6-24 members who will gain prioritized voting rights over the Polkadot network. The council will be elected with the ambition of proposing sensible referenda, as council members will stake their expertise and experience in developing, maintaining and using decentralized networks.
Council members have the ability to veto incoming proposals. After a cool-down period, however, these proposals can be re-submitted and the council member that vetoed the proposal cannot veto this proposal again.
Council members are elected in rolling elections, with one council member up for election every two weeks from a list of candidates who nominate themselves. The term of each council member is determined by the size of the council, which will change over time due to the adaptive nature of Polkadot governance. This means that one council member’s term length is equal to 2 weeks times the number of council members. For example, if there are 6 council members, one council member’s term lasts for 12 weeks (6x2).
DOT holders vote for council members to represent them. We introduce a loss-weighted function to benefit the runners-up in each election so that council members with a long history of applying themselves as candidates will benefit from their continued support by the community.
Prospective council members elect themselves to be a part of the council’s candidates list. Every two weeks the council member with the highest amount of DOTs used to vote for them are elected. In the following round, council candidates keep their votes from the previous round as long as DOT holders do not change their position. Furthermore, the DOTs voted for losing council members accumulate a portion of this “wasted” value into the next round. The graphic above shows an example first-round election, and the following table shows the weight for each prospective council member for the following election two weeks later.
As you can see, council candidate C won in round 1 and was removed from the candidates list. In round 2, DOT holders who did not get their council candidate voted in now carry some of their vote-weights over to the next vote. (In the table they carry all of their weights over, but in Polkadot at launch, they’ll likely carry over only a portion.)
DOTs used to vote for council members are not locked in any way, and can be revoked or changed at any time during the election by DOT holders. Votes that are carrying more from previously “lost” elections, however, do get reset once a voter changes their position.
Referenda in Polkadot Governance
Every change to Polkadot takes the form of a referendum. Referenda contain a crucial function in the code to go alongside it, set_code, which has the ability to change any aspect of the system. The set_code function is the most powerful function found in Polkadot, as it changes any feature, including the governance system itself.
Who can propose a referendum?
Referenda can be proposed in three ways, each with different paths to enactment:
- Unanimous Council
- Majority Council
- Public referenda
Proposals that do not pass a majority within the council do not make it to a public referendum. In situations where the council is in unanimous agreement, proposals benefit from a less-than-majority threshold in a public vote for approval, as described in the following section on “Adaptive Quorum Biasing”. When only a majority of council members vote aye on a given proposal, the public must approve of the motion with a simple majority.
Public referenda can be proposed by any DOT holder and seconded by supporting DOT holders. As we expect many proposals from the public, we mitigate the problem of proposal spam by prioritizing the proposals with the greatest stake weight behind it. This ensures that the most desired proposals get voted on first.
Adaptive Quorum Biasing
To mitigate the reality that turnout is never likely to be at 100%, Polkadot introduces Adaptive Quorum Biasing. Quorum has traditionally been defined as a minimum number of participants present for a vote to be considered valid, but issues have arisen over the last few centuries. Quorum-busting has been used by minorities to delay or prevent a vote from occurring, and some historical figures have gone as far as to jump out of windows to prevent a quorum from being reached. Studies have also shown that strict quorums decrease voter participation. Another issue is how to determine the minimum number of votes required for a quorum to be reached, a decision itself that can be contentious, and how to reach a decision without a defined quorum?
Voting systems without quorums have explored ways of incentivizing participation by means of rewarding voters, or inversely, punishing citizens who do not vote. Research has shown that such mechanisms may lead to much higher voter turnout, but a disproportionate effect on increasing voter knowledge.
Polkadot’s Adaptive Quorum Biasing changes the supermajority required for a referendum to pass based on the percentage of voter turnout.
- A positive turnout bias requires a heavy supermajority of aye votes to carry at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as above. We call this a “positive” turnout bias because the required margin of ayes increases as turnout increases.
- A negative turnout bias requires a heavy supermajority of nay votes to reject at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as above. We call this a “negative” turnout bias because the required margin of nays increases as turnout increases.
When a proposal is unanimously voted in favor by the council, it benefits from using the negative bias. We assume that if the council proposes a referendum, then low turnout is less troublesome. Public referenda, however, must be agreed upon using the positive curve. This is done to mitigate attacks by malicious or ill-conceived proposals.
When a proposal is unanimously voted in favor by the council, it benefits from using the inverted bias. Public referenda, however, must be agreed upon using the standard curve. This is done to mitigate attacks by malicious or ill-conceived proposals.
An important feature in Polkadot governance is delayed enactment. Every approved referendum goes through a certain amount of time before it becomes enacted on-chain. This allows participants who disagree with any referenda to leave the network, while the DOT holders that voted in support of this referenda have their DOTs locked until the upgrade is enacted.
Voters should carefully choose what proposals they vote for, and keep in mind what the impact referenda will have on the health of the entire Polkadot network.
Lock-vote multiplying / Time-lock voting
Polkadot introduces the aspect of time-lock voting, a novel approach that allows DOT holders to increase their vote’s weight on a particular motion.
All voters are weighted based on two criteria:
- DOTs: The amount of tokens under ownership by the voter;
- Time: The amount of time those tokens will remain locked after the referendum has ended. Five periods are allowed: 4 weeks, 8 weeks, 16 weeks, 32 weeks and 64 weeks. Each doubling of the period results in the voter getting an additional “vote”.
In order to vote, a voter must lock their DOTs up for at least 4 weeks, the enactment delay period beyond the end of the referendum. This is in order to ensure that some minimal economic buy-in to the result is needed and to mitigate vote trading.
With this mechanism, a voter with five tokens willing to lock them up only for the minimum allowed duration would have the same number of votes as a voter with only one token happy to have it locked for the maximum amount of time.
In addition to the above, a voter may choose not to lock up tokens at all for a heavy discount (90%) on their voting weight. In the same scenario as above, a third voter would need to own 50 tokens to have the same voting power if they did not wish to lock them at all.
More to come
In the following months, the developers and researchers will fine-tune the details of what has been described here. Different time-spans will likely be used once Polkadot launches, and perhaps the weights of time-lock voting will be adjusted once more research and testing has been completed.
An upcoming feature being worked on right now is delegated voting, also known as “liquid democracy.” For participants who do not wish to participate in every vote, but know an individual or group they trust to align with their own beliefs will be able to delegate their votes.
Want to participate?
Has this Polkadot walkthrough tempted you to participate? Feel free to use the Alexander testnet, Polkadot’s living testnet, already in its fourth Proof-of-Concept, having been upgraded using some of the mechanisms described above. Many of the features described so far, including Adaptive Quorum Biasing, public referenda, democracy and council modules are live.
As we continue to work on the governance interfaces for a future release, the easiest way to start is to head to https://poc-3.polkadot.io, create an account, get some testnet DOTs from the faucet and start playing with transfers, staking, nominating, and if you’re up for it, proposing new referenda.
From the blog
Elevating Polkadot's Performance and Scale with Asynchronous Backing
Asynchronous backing is the latest step in the roadmap towards natively scaling Polkadot’s performance and flexibility for Web3 use cases across every industry.
Polkadot Consensus Part 1: Enhanced Economic Security via NPoS
The first installment in the NPoS series describes how Polkadot maintains a more secure, open and more decentralized network due to its novel consensus system, NPoS.
Polkadot Blockchain Academy: Forging Web3’s Future Innovators
Polkadot Blockchain Academy, designed to shape promising developers into tomorrow's leading blockchain engineers, just wrapped up its 3rd wave in Berkeley, California.