Polkadot Governance
Parity Technologies and the Web3 Foundation Team stopped over in Tokyo and gave a series of highly educational presentations at the Polkadot Meetup, with Gavin Wood in particular focusing on governance. In addition, Ryan Zurrer provided a comprehensive assessment of the state of Web3, and Robert Habermeier explained Substrate.
Polkadot proposes various ways in which motions can be proposed. A key element of the governance structure is the council, for which 12 or 24 representatives will be elected on a rotating basis so that the term for the council members ends up to be a full year. Gavin also highlighted that the votes for runner-ups will be carried forward, so that it is much more of continuous election, whereby votes can be accumulated over time, and the highest ranking candidate will get her turn during the next cycle.
The council may cancel a motion by unanimous vote, e.g. in cases where it is obvious to all that the technical implementation of a proposal is impossible or detrimental to the overall system. Individual council member may also veto a motion, but only once, which would lead to a 2 or 4 week cooling-off period during which further debate is possible. This feature is intended to be used if one council member feels strongly against a motion, and the rest of the council might be lukewarm for it, so it provides for a little more time to convince the majority.
The power of votes in the Polkadot governance system is determined by the willingness of voters to lock up their tokens for specific periods of time. The longer the lockup, the more the vote counts. In the example on the top of the above picture, Alice has one vote, but is willing to lock up her token for four periods (8 weeks), so her vote counts four. Bob has three tokens, which he is willing to lock up for three periods (6 weeks), so his vote counts nine. Charlie has four tokens that he only locks up for the standard period. With a weighted vote of nine for (Bob) and eight (Alice & Charlie) against, the motion is accepted and will be implemented after a cooling off period of two weeks. That two-week delay allows those that have lost the vote to exit the system (sell their tokens) if they desire to do so. Also, only the winners’ tokens are locked up, not the tokens committed to the losing vote. The example at the bottom of the picture shows a corresponding win of the vote against.
Lastly, Polkadot implements adaptive quorum biasing. What sounds terribly complicated, is simply taking the voter participation in consideration when determining the majority needed to win (positive turnout bias) or reject (negative turnout bias) a motion. The lower the voter participation is, the higher a majority of the participating vote is required to win the motion. Naturally, with 100% participation, a simple majority suffices. Once participation drops to 50%, 59% of the turnout, equalling to 29% of the total population, is required. The curves for positive and negative turnout bias are simply mirror images of each other.
This article was intended to highlight just a few aspects of Polkadot governance that have been discussed at the Polkadot meetup. For a more comprehensive coverage, you may want to refer to the following two sources:
Why on-chain governance? by Phil Lucsok
For additional reading on Polkadot & Substrate, please also refer to our article “Implications of Interoperability”, covering Robert Habermeier’s talk at the Web3 Summit in Berlin.
If you found value in this article, please “clap” (up to 50 times).
This article is part of our Tokyo FinTech Publication, please follow us to read more from our writers, like hundreds of readers do every day. Should you live in Tokyo, or just pass through, please also join our Tokyo FinTech Meetup.
