Substrate Governance 2.0 (OpenGov)

Welcome to ChaosDAO’s first published article. Today we’ll be talking about governance on Polkadot and Kusama. The current governance system isn’t perfect, and Dr. Gavin Wood has been in the kitchen with the big brains at Parity for months working on a complete overhaul, detailed below.

This post features a short summary of Governance 1.0, the current system, as well as a short summary of Governance 2.0 (A.K.A. OpenGov), the upcoming overhaul. If you want to know all of the details, you can find those in the second half of the post. Enjoy!

Governance 1.0

The current governance systems of Polkadot and Kusama, henceforth Governance 1.0, are made up of three parts: the technical committee, the council, and token holder generated public referenda.

The technical committee exists to fast-track necessary technical upgrades or fixes, for example, if a critical bug is discovered. It is comprised of 3 members elected by the council.

The council is a group of 13 members elected by token holders to perform executive actions for the chain, such as voting on treasury proposals and electing the technical committee.

Token holders can create proposals to do things such as transfer tokens, upgrade the chain’s runtime, and request funding from the on-chain treasuries. These proposals can then become referenda to be voted upon.

However, due to the nature of Governance 1.0, only one referendum may be voted upon at a time (the single exception is when the technical committee fast-tracks a referendum alongside an existing referendum). Especially in Polkadot’s case, with a 28 day voting period, this can make things prohibitively slow.

Referenda are based on proposals, which can be thought of as on-chain operations, such as making a transfer. Proposals aren’t that important by themselves, but the Origin with which they are executed are.

Origins act as the permission level of a proposal. The lowest Origin just allows one account to perform actions on behalf of itself. This is what we, as users, use in our everyday lives. The most powerful Origin is Root, which is basically on-chain God. The Root Origin can make any change to the chain it wants, from mixing everyone’s tokens together to slashing every validator to halting the chain or upgrading the runtime. In Governance 1, every referenda is executed using the Root Origin. Due to the immense power of this Origin, every proposal needs to be carefully analyzed — this makes the governance system slow.

Governance 2.0

Governance 2.0 aims to turn a slow single lane road into a series of parallel roads of differing sizes and speeds. Some roads, such as those for small treasury tips, can move at lightning speed, while the large roads suited for upgrading the chain’s runtime may still move at a turtle’s pace. Let’s get into the details.

Governance 2.0 gets rid of the council and technical committee, but includes many different Origins in the governance process, including Origins for tips, various sizes of treasury proposals, and creating parachains.

This system allows for a streamlining of the governance process from a technical level. A proposal for a 10 DOT tip to someone does not need to use the Root Origin, and therefore does not need as much scrutiny as a proposal to upgrade the runtime of the blockchain.

Each Origin is associated with a specific type of referendum, and this is called a Track. Following the earlier analogy, a Track can be thought of as a road. Based on the associated Origin, the size and speed limit of the road can be set accordingly based on the impact that refenda from that track can have. Different Tracks can have different voting periods, approval thresholds, and timelines.

In short, Governance 2.0 provides for much greater specificity when participating in governance. Everyday users interested in governance don’t need to spend time looking at tech upgrades they can’t understand, and those that understand tech upgrades don’t need to look at article funding requests. It also enables a much higher throughput of governance decisions on the network.

That was the short summary, and you can stop reading there, but if you want to know all of the details, read on.

The Specifics

If you really want the full details from Gavin himself, you can read his super long article. We’ll be covering the details in the simplest way possible that still enables full understanding.

This is where it starts to get complicated. In Governance 2.0, referenda have multiple phases.

When a referendum is first created, it is considered Undecided. Token holders can begin voting to approve this referendum immediately. Next is the Deciding phase, where the referendum will be passed or rejected. There are three requirements for a referendum to enter the Deciding phase.

First, each Track will have a specific lead-in period, which is the amount of time that has to pass between a referendum being created and the Deciding phase starting. For example, if the lead-in period is 5 days, a referendum must spend at least 5 days in the Undecided phase.

Second, there must be space for the referendum. Each Track has a set capacity for how many referenda can be in the Deciding phase at a time. For example, the Root Origin will only have space for one referendum at a time. This means that if there is a referendum in that Track’s Deciding phase, there is no space left, and an undecided referendum must remain Undecided until the Deciding referendum is passed or rejected. If, for example, there is a Deciding referendum in the Root Track and two Undecided referenda waiting for space, the one with more approval votes will take priority in entering the Deciding phase.

The third and last requirement for a referendum to enter the Deciding stage is for the Decision Deposit to be paid. If the referendum is ultimately rejected, this deposit can be refunded.

Once these three requirements have been met, the referendum enters the Deciding phase, where it is eligible to be approved. This eligibility window lasts for 7 days on Kusama, and 28 days on Polkadot. If a referendum is not approved, it is automatically rejected.

For a referendum to be approved, it must pass two criteria for the duration of the Confirmation Period, which will differ by Track. The two criteria are Approval and Support.

Approval is simply what percentage of votes are in favor of approving the referendum. For example, if the referendum has received 100 votes, with 69 of those votes being approvals, then the approval rating is 69%. Approval takes voter conviction into account.

Support is essentially voter turnout. If the referendum has 100 votes, but 1000 votes could be made, then it only has 10% support. Support does not consider voter conviction.

Each Track can have different requirements for Approval and Support thresholds in order for a referendum to be considered approved. However, what is interesting is that the required Approval and Support levels can be set to decrease over time. In effect, this may mean that referenda in Track X with very high Approval and Support levels will be approved quickly, while referenda in Track X with moderate Approval and Support levels will take longer to be approved, as they need to wait for the Approval and Support requirements to lower. Higher impact Tracks, such as the Track involving the Root Origin, will have higher initial Approval and Support thresholds.

If a referendum maintains suitable Approval and Support levels for the duration of that Track’s Confirmation Period, it is approved, and will be enacted after the Enactment Period. The Enactment Period is specified when a referendum is created, and has no maximum length (in theory, a referendum could be passed that would be scheduled to execute in the year 2100), though each Track will have a minimum Enactment Period.

Cancellations

There are two types of cancellation proposals. One simply cancels an existing referendum, while the second cancels the referendum and slashes the original proposer’s deposit. Cancellations have their own Origin and Track, with short time tables to allow for canceling a runtime upgrade that contains a bug, for example.

Delegation

Like Governance 1.0, Governance 2.0 features the ability to delegate your voting power to another entity, for whatever reason. These tokens stay in your control, but increase the voting power of the entity you delegate to.

Governance 2.0 improves upon this by allowing you to delegate to different entities by Track. For example, you might delegate 10 DOT to Alice for matters involving Track X, but delegate that exact same 10 DOT to Bob for matters involving Track Y.

The Fellowship Of The Ring

The Polkadot Fellowship is the spiritual successor to the technical committee from Governance 1.0. It’s main use case is in those very rare “oh shit” moments involving the Root Origin Track, for example, if a runtime upgrade containing a bug is about to be approved. The only power the Fellowship has over the network is reducing the timeline of a referendum. The Fellowship’s goal is to decide if an action is both safe and time-sensitive.

Whereas the technical committee was made of three members, the Polkadot Fellowship can function with thousands of members, and becoming a candidate is as simple as placing a deposit. Members have ranks that represent their level of technical knowledge about the system, and the Fellowship attempts to minimize the downsides of a ranking system by decreasing the difference in voting weight between high and low ranks. The Fellowship has a constitution that governs its operations and the system for promotions and demotions.

The Whitelist

As part of the Fellowship, a Track exists for a new origin named Whitelisted-Root. This essentially allows the Fellowship to make proposals with the Root Origin without going through the normal Root Origin. The advantage of this is that the Root Origin Track can have its parameters set for standard operations, and if a situation arises that warrants action from the Fellowship, they can use their special Track with much shorter timeframes, without altering the Root Origin Track.

If you made it this far, you can consider yourself an expert on the new governance system.

Cheers,

Yung Beef, ChaosDAO