Revamping Polkadot Governance with Polkadot OpenGov

The current Polkadot governance model was designed with the ultimate goal of ensuring consensus and automatic enactment of any changes based on community decision. Composed of three collectives that have ensured that necessary legislation is initiated (Council), discussed and enacted successfully or rejected (Democracy module), and executed in a speedy way if urgent (Technical Committee), Polkadot stakeholders have worked in coordination for more than two years discussing and stewarding the network’s direction.

Since the very first governance proposals were put up for discussion, the community already began thinking about alternatives and possible new designs to counteract some identified weaknesses in the model. Many community members have already identified the lack of participation as its weakest point. Others felt that the Council was the weakest aspect, arguing that, even if Council were to grow in number, this form of representation had no place in a decentralized on-chain governance system. Many community members, despite being able to delegate voting power and use conviction voting, also noticed a low representation of smaller token holders.

Following the recent launch of parachains and the completion of Polkadot’s multistage launch process, in the coming weeks, the community will have the opportunity to vote on a proposal for the first major changes to Polkadot’s governance design, proposed first for deployment on Kusama to ensure the successful functioning of the code.

Governance 1.0: What We Have Right Now

Polkadot and its parachains need to change over time to stay relevant, and the network was designed from the beginning to have a transparent and sophisticated process to not only approve or reject changes but enact them automatically. Polkadot governance is designed around three collectives: the Council, the Technical Committee, and the general DOT holder community. By meeting certain criteria, the first two collectives can call privileged functions which affect how a proposed change goes to a referendum to be voted by the community.

Polkadot expresses privilege using origins. An origin is defined as the initiator of an extrinsic. A simple origin would be the account that is sending a token to another account. The governance design today also supports more complex origin types, such as the root origin, from which privileged functions can be called. If the origin of the call does not match the predetermined requirement in the code, the call fails to enact. 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.

• 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.
  
• The Technical Committee serves as Polkadot’s last line of defense against software errors. Members are 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.
  
• The Democracy module, composed of all DOT token holders, is based on the idea that a majority of stake, defined as the total number of tokens in issuance, can always command the network. 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. This collective ensures a successful enactment of all proposals, including those that are initiated via Council.

The Democracy module became a primary focus in recent discussions of the new governance design, as it allows all token holders to be able to propose, participate, and be held accountable for the proposals they submit. 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 lowers. Since making a protocol change comes with risk, this system was designed to favor the status quo. Positive biasing ensured that with lower turnout, only uncontroversial proposals can pass.

This design has preserved the core tenet that a majority stake can always command the network and has ensured that the teams working on the core development of Polkadot could deliver the promises of the Polkadot paper↗ in a gradual manner.

For a deeper analysis of the current model, please read this article.

What Is Coming: A More Agile, Inclusive, Secure, and Decentralized Governance Design

Recent events around the world have shown that centralized institutions are trying to retain control over technological innovation, diversity, and participation in all spheres of human society by any means they can. Efforts at regulating the space often do not take into account new forms of community participation that push networks toward decentralized governance.

The new Polkadot governance design answers two questions that have arisen in the community:

1. How do we ensure wide participation among big and small token holders while complying with regulatory concerns?
2. How do we avoid censorship while also ensuring the correct functioning and progress of the network?

An update on any governance processes on Polkadot needs to aim for a more censorship-resilient type of design in which community members can participate in a secure and decentralized manner. The purpose of this section is only to highlight the three pillars of the new governance in an introductory manner. Subsequent articles will go into more detail about their technical design. Other interesting efforts on the technical side to deepen Polkadot's decentralized character can be found here↗: providing a way to interact with Substrate-based blockchains in-browser without using an RPC server’s services.

The way the new governance model reflects its decentralized character is by 1. migrating all responsibilities of the Council to token holders via democracy votes, 2. dissolving the current Council collective, and 3. allowing users to delegate voting power in more ways to community members.

The Council And Technical Committee Are Dissolved And The Fellowship Is Born

The Council has fulfilled its role as representative of passive token holders, guardian of the treasury, and initiator of legislation: but the time has come to return these responsibilities to the community. The migration will be immediate: referenda and conviction voting pallets↗ will be added to the Polkadot business logic and work in parallel with a functioning Council for a release cycle. Afterward, most of the council's functions will be transferred immediately with a runtime upgrade that will dissolve the Council, causing it to cease existing on-chain.

The Community Holds the Ultimate Decision

The various Council responsibilities will be migrated to the community. Clearly, this can only work if there is sufficient information and tooling available to DOT holders to make and submit informed decisions.

In the current design, 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 proposals: ensuring they have an equal chance of reaching the referenda queue. At the end of the voting period, Polkadot tallies the votes and calculates the result. If the proposal passes, then the network logic automatically schedules it for enactment.

The new design will build on top of these assumptions and take community participation further: each call aimed to be enacted by a proposal will be submitted by any token holder and will have different origins defined (as opposed to the current model) depending on the seriousness of the call.

The new model will define different origins for different calls: each of them will include different thresholds and turnouts needed for a proposal to pass. For example, a runtime upgrade (set_code call) does not have the same implications for the ecosystem as the approval of a treasury tip (reportAwesome call), and therefore different origins are needed in which different turnouts, approvals, deposits, and minimum enactment periods will be predetermined on the pallet. For the first example, set_code, for instance, we expect the threshold for approval in combination with turnouts to be higher in order for the proposal to pass.

The creation of new origins will allow the community to treat proposals differently, assess their approval requirements and take these into account when campaigning for a vote. The new model also defines different referendum tracks defined by their origins and these are wholly independent of each other.

The design this particular process follows can be read below:

• All referenda have a desired origin from which the proposal is dispatched if approved.
• There is a track ID for the proposal which is determined by the origin.
• Any token holder may introduce a referendum at any time for any reason.
• Referenda may be voted on at any point prior to completion or cancellation.
• When ready, referenda will enter a deciding period during which they may become approved (following a confirmation period of continuous approval).
• Once the deciding period expires without approval, the referendum is rejected.
• Tracks have their own attributes and limits, including defining how many referenda can be decided simultaneously and the criteria for approval (more on this in a subsequent article).
• Any delegation is done per track and accounts choose to select different delegates (or no delegation) for each track (we will discuss this further down).

All submitted referenda will have a minimum viable on-chain deposit for storage and will be immediately votable (they can also be canceled at any time through a cancel_vote or kill_vote call via governance). These proposals will move to the closing period when 1. The deposit is paid 2. The proposal has reached its required approval threshold.

If multiple proposals become eligible for moving to the Closing Period at the same time in one track, then the one with the greatest number of approvals is scheduled first. When a vote ends, the proposal is queued for enactment. The longest time a proposal can be voted for is 30 days: but bringing forward the ending time of a vote is possible and relates to the turnout and threshold of approval.

What this means, in simple terms, is that different proposals submitted by the community will enjoy different approval thresholds, depending on the call up for vote. But there is one extra component available to bring forward the ending time of a vote: a new collective called "The Substrate Fellowship". As we will explain below, the fellowship can also speed up the voting of a proposal, making it easier to pass if the proposal hash is whitelisted.

The Substrate Fellowship

During the first phase of deployment, the Technical Committee (in charge of emergency bug fixes or rapid implementation of new but battle-tested features into the runtime) will continue to work in parallel with the new pallets. However, the goal is to dissolve this collective (although later than the Council) via a runtime upgrade. The Technical Committee will be replaced with a collective of Substrate developers, although different in nature and composition, who will ensure the quality of any code being deployed.

The Substrate Fellowship is a membership-oriented governance body inspired by expertise-based structures. It requires its own pallet, which enforces the rules of ranking and membership. Composed of at least 100 developers voted in by democracy and voted out in the same way or by its members, the collective aims to answer the following questions when looking at a piece of code before deployment:

• Correctness: Does the code actually do what it is meant to do?
• Quantity: How much relevant functionality is delivered in the code?
• Quality: Is the code minimal, elegant, and comprehensible?
• Modularity: Is the code only relevant for the immediate features, or was it architected and implemented modularly, generally, and with sufficient functional-independence to allow for reuse, maintenance, and eventual externalization?
• Timeliness: Was the functionality delivered at the optimum time for maximum value to be extracted through its existence?

The main fellowship calls include whitelisting code hashes for a relay chain upgrade, parachain upgrades, root calls, or XCM dispatch from the relay chain. It is essential to note that the collective holds no power over these calls' approval but token holders do: the collective aims only to whitelist a proposal for a faster enactment, answering Aye/Nay to the questions above.

An easy path for the enactment of a runtime upgrade proposal could look like the following: a token holder proposes a runtime upgrade to the network, the Fellowship approaches the code hash by answering Aye to the questions above in an on-chain manner. This results in a vote on this upgrade executed with a non-root origin (essentially making the proposal easier to pass by the community), and the non-root call schedules an upgrade with a code hash pre-approved by the collective.

A second article will dive more deeply into the specific role of the Fellowship, along with membership requirements, the application process, expertise, voting process, and rank voting. Stay tuned.

What About Delegation?

In Substrate, delegation is defined as the act of granting your voting power to the decisions of another account for up to a certain conviction. In the current governance design, if you are too busy to keep up with and vote on upcoming referenda there is an option to delegate your vote to another account whose opinion you trust. When you delegate your vote to another, that account gets the added voting power of your tokens along with the conviction that you set. The conviction for delegation works just like the conviction for regular voting: the account that is being delegated to does not make any special action once the delegation is in place, they can continue to vote on referenda how they see fit.

The issue with the current delegation design lies in the lack of flexibility the Democracy pallet allows when thinking about different types of proposals with different origins and therefore implications for the network. Token holders need a way to delegate their votes (and conviction) depending on the calls up for vote by the community: the new delegation design helps with this.

With the current design, it is essential to encourage people to delegate their democracy votes to ecosystem members as much as possible if they are too busy to participate: they can delegate with 0.1x conviction if they need liquidity (they can be undelegated instantly) or 1x if they are staked (in which case they can be undelegated in approximately the same period as unbonding). With the new governance model, the user delegating is able to decide for which set of calls (treasury proposals, runtime upgrades, staking parameter calls) they are delegating their voting power, with what conviction, and how much of their tokens will be dedicated to this task.

Occasional delegation and undelegation calls are fee-free: incentivizing token holders to use this feature and ensuring that wallets can do it “by default” without any cost to end-users. It is worth noting that a user delegating their voting power does not imply that the delegate will have control over the funds of the delegating account: they can vote with a user's voting power: but they won't be able to transfer your balance, nominate a different set of validators or execute any call other than voting on the defined call/s by the user.

With the new delegation features, the goal is to ensure the required turnouts for proposals to be enacted are reached while maintaining the anonymity of voters and keeping the overall design censorship-free.

When To Expect The First Changes?

As stated before, if the community approves the runtime upgrade proposals that include these changes, we will see the first contributions towards OpenGov on Kusama in the next few weeks. After auditing to ensure successful functioning, these will be also submitted as a runtime upgrade proposal to Polkadot.

Stay tuned for the next article of the series to understand more about referenda, origins and conviction voting pallets, the Substrate Fellowship collective and more details on this amazing journey in the quest of a more fluid, decentralised and censorship-resistant network.