Polkadot uses a fairly complex system to govern the protocol when compared to other L1 chains. Three fundamental features of the governance design make the model unique:

• An on-chain Council, where members are associated with an account, and the account gets added to the council to introduce proposals and govern the treasury.
• Submitted referenda, where proposals include code changes that the protocol will automatically implement after the proposal passes, avoiding a hard fork. Polkadot uses WebAssembly to accomplish this.
• Finally, the proposal uses conviction voting, a system that uses native tokens, while bypassing many drawbacks associated with token-based voting.

Ethereum, on the other hand, has a robust off-chain governance structure based on Python’s model for governance. Vitalik Buterin, one of Ethereum’s cofounders, is a strong proponent of off-chain governance and voting that is not tied to the native token of the protocol. (You can read more about Ethereum’s governance structure here.)

Gavin Wood, the founder of Polkadot, was also a cofounder of Ethereum. He stands on the opposite side of Vitalik Buterin regarding governance. Polkadot has a complex system of on-chain governance that includes an on-chain council that can evolve based on the demands of stakeholders.

A few pivotal characteristics of Polkadot’s governance are drastically different from the familiar governance of, for example, the Cosmos Hub and other Cosmos SDK-based chains. Polkadot is one of the two protocols for which we provide staking support that uses a conviction voting model; instead of one token equaling one vote, people lock up their tokens for at least four weeks.

These are relatively novel systems. Although there are identifiable connections between Polkadot and other governance systems that Figment encounters, few other protocols have technical governance mechanisms such as these.

‍

Council-Based Governance

Polkadot has an on-chain council, where an on-chain account represents each member. Currently, the council consists of 13 members, and this number can be set by governance. More members can be added as the use of Polkadot grows. There are 17 people who are runners-up.

The implication of a council in this way is to address issues of low voter turnout. Council members’ votes have more weight than regular votes to ensure proposals are passed or rejected within a reasonable time.

The council has four responsibilities:

• Control the treasury
• Propose sensible referenda
• Cancel uncontroversially dangerous or malicious referenda
• Elect the technical committee.

Other networks have committees and councils (Secret and Celo, among others), but Polkadot is currently the only network with an on-chain Council that oversees these roles.

This is not the only protocol developing this method. Cosmos SDK-based chains have fairly robust forms of community governance, where committees apply for on-chain funding and are independent of the foundation. Secret Network and Osmosis have independent committees. Gravity Bridge introduced an organizational structure that mirrors worker-owned cooperatives, called a federated DAO. The teams building the Cosmos SDK are developing a group module, a structure that chains will launch with that will give groups of accounts the ability to control a treasury and allow them to vote on proposals and policies for group voting. The module will allow these committees to have more flexibility and on-chain tools to govern themselves.

The Phragmén election algorithm selects councilors based on how token holders have signaled their desires. Polkadot does not use a “first-past-the-post” model to ensure that the majority overtakes the governance agenda.

The length of terms depends on the size of the council. A term length of an individual member lasts two weeks multiplied by the number of council members. With 13 members on the council, a term is currently 26 weeks.

‍

Referenda

In Polkadot, anyone can submit a new proposal by starting a Referendum. Each referendum has a specific proposal that can change an entire piece of code. This allows the referendum to accomplish what otherwise would have to be a hard fork in the code, and node operators upgrade their nodes in sync. This method avoids complications and, theoretically, reduces errors within restarting the chain. To accomplish this goal, Polkadot uses WebAssembly (WASM), a technology stack that can implement changes to code. Cosmos is currently developing CosmWasm, a version of this packet for Cosmos chains, for a future upgrade.

Once proposals are submitted on-chain, they need to be seconded by others. Once seconded, proposals enter the queue to be voted on by the majority. The more support the proposal garners, the more places it will jump in the queue. Every 28 days, a referendum will come up for a vote, assuming at least one proposal is in the queue for public referenda and council voting referenda.

There are four ways that a referendum can get started:

• Publicly submitted proposals;

• Anyone can submit a proposal with the minimum deposit amount (similar to Cosmos SDK-based networks).

• Proposals submitted by the council;

• Councils can submit proposals when there is either a unanimous or majority vote.
• When a proposal has a unanimous vote, the fewer amount of stake voting, the less stake is needed to get the vote to pass.
• When a majority council proposal goes to the referendum stage, the proposal requires a 51% majority to pass.

• Proposals submitted as a part of the enactment of a prior referendum;
• Emergency proposals submitted by the technical committee and approved by the council.

If either the public or the council submits a referendum, there is a voting time of 28 days. If proposals were submitted to enact a prior referendum, the proposal can determine the length of the voting period. The Technical Committee can submit emergency proposals, which are then approved by the Council to be fast-tracked through the voting period.

‍

Voting 

Polkadot uses various mechanisms to address voter apathy, governance attacks, and the trappings of token-based voting. Conviction voting and adaptive quorum biasing stray significantly from other models of governance that chains are implementing.

‍

Conviction Voting

To vote, people must lock up their votes until the proposal is implemented. Polkadot does this to ensure that there are minimal opportunities for position bribery to take place. This model is called conviction voting.

Conviction voting is a method that uses token-based voting while avoiding the pitfalls that networks with one token = one voting-based governance models face. This way, the network has a native token with a use case, alongside staking and paying for fees on the network. At the same time, it allows people with varying amounts of tokens to participate and have a say in how decisions are made on the network.

Where one token = one vote models give large token holders, whales, the ability to have more say in decision-making on the process than smaller token holders. The goal of conviction voting is to balance the token’s utility while allowing small token holders more weight in governance decisions than other models. Conviction voting provides a more equal playing field, so retail delegators can have as much voting power as institutional stakers.

Put simply, conviction voting works like this: the longer someone locks up their tokens, the more votes they have.

Specifically, on Polkadot, the number of votes is calculated by the conviction multiplier. This variable increases the vote multiplier by one every time the number of lock periods doubles. One lock period is 28 days long. Polkadot has a maximum number of doublings of the lock period.

votes = tokens * conviction_multiplier

Peter: Votes No with 10 DOT for a 128 week lock period => 10 x 6 = 60 Votes

Logan: Votes Yes with 20 DOT for a 4 week lock period => 20 x 1 = 20 Votes

Kevin: Votes Yes with 15 DOT for a 8 week lock period => 15 x 2 = 30 Votes

‍

Tokens still locked can be used for voting and staking but cannot be transferred to another account. Delegators need to bond their tokens to the network to stake and participate in governance.

‍

Adaptive Quorum Biasing

Polkadot recognizes that voter turnout is likely to be less than 100%. A quorum is the minimum number of participants who can vote on a proposal. But minorities in the past have taken advantage of this to prevent votes from happening by refusing to be present for a vote.

Polkadot has a method called adaptive quorum biasing, which “changes the supermajority required for a referendum to pass based on the percentage of voter turnout.” This allows governance to adapt to different levels of voter turnout. Hence, it is not reliant on an opposing minority or apathetic voters.

If the majority of participants vote yes, as turnout increases, the protocol will require more yes votes for the vote to pass. The more people vote on the proposal, the more support it will need to represent community desires.

If the majority of participants are voting no, and there is a low turnout, the protocol will require more no votes for the vote to be rejected. As more people vote no, and if there is a low turnout, more support is needed to ensure that rejecting this proposal is what the community has decided is best, rather than just what the people who voted think is best.

This model contradicts Cosmos-SDK’s governance mechanisms. Cosmos SDK-based chains have a quorum, and chains can change this number based on turnout numbers through governance. But certain proposals may struggle with the ability to reach quorum without large token holders voting. The adaptive quorum method ensures that quorum is always met and that the proposal outcome is within the community’s best interest.

‍

Novel Models of Governance

Polkadot’s governance model is optimized to avoid a few fundamental drawbacks within other governance systems present in the space. Mainly, the designers aim to prevent a majority or a minority from controlling all the decision-making on the protocol.

Implementing an adaptive quorum system and conviction voting can successfully avoid the trappings that Cosmos SDK chains often face. These drawbacks include quorum not being met if not enough large token holders pay attention to governance and if the largest token holders have the largest say on the outcomes of governance proposals.

However, this system does have its flaws. The current UX that Polkadot uses for governance is the same that is available for other Substrate chains. In its current state, the UX is challenging to navigate, making participating in proposal discussions and voting a high barrier to entry for individuals who want to get involved.

‍

Voting Proxies:

Polkadot does provide a voting proxy mechanism; our clients can authorize an account controlled by a member of Figment’s governance team to vote on their behalf! We’re happy to work with our institutional stakers by informing them of new governance proposals, working through the potential outcomes together, and then voting on the proposal. Figment’s clients can also authorize us to vote with their best interests and the best interests of the protocol in mind, and we’ll report back with an explanation of how and why we voted in a particular way.

In the future, we can expect innovative and thoughtful approaches to governance, and Polkadot has supported a host of mechanisms that may prove successful across ecosystems.