Governance Overview

This is just my current intepretation of the Polkadot governance system. The document will most likely change as my understanding evolves. I have drawn from the following resources:

Video Resources

1. Governance on Polkadot by Bill Laboon
2. Governance with FRAME
3. Polkadot Decoded 2020: The Power of Polkadot’s On-Chain Governance & Treasury
4. Gavin Wood - A Walkthrough of Polkadot's Governance

Blog Resources

1. Polkadot Governance
2. Kusama Governance

Wiki Resources

1. Learn Governance
2. Participate In Governance

Code

1. Substrate Node Runtime
2. Polkadot + Kusama Runtime

The high-level idea

The system wants to be governed by the majority of the stake in it. This is not a democractic 1 person 1 vote system. We have the concept of proposals that can be turned into a referenda and voted on in a stake weighted manner. After these referenda are passed by a majority of the stake, they will be enacted autonomously with a delay period. So we can see three distinct periods here:

1. Launch Period - when a proposal is proposed and turned into a referendum.
2. Voting Period - the actual voting on the referendum by all the token holders.
3. Enactment Period - the period between the end of the voting and the actual exection. Necessary so stake holders can either prepare for the change or leave the system if they are not happy with it.

Now that we are familiar with the different periods let's go through the lifetime of a proposal.

Launch Period

We mentioned this is the period where a proposal gets turned into a referendum. First we need to establish there are 3 ways to generate proposals:

1. Public Token Holders using the democracy pallet
2. Council using a pallet_collective instance.
3. Technical Committee using a secondary palllet_collective instance

Let's walk through each of them separately:

1. Any public token holder can create a proposal. This proposal can then be seconded (with more stake) by other users during the launch period. There can be multiple proposals but ultimately only one, with the most backing, will be pushed to referendum at the end of the period.
2. Council can create their own proposals, and their mechanism is different than the public token holder proposals. They each have 1 vote and majority wins.

It's important to pause and mention that even though we have described two independent mechanisms to create proposals only 1 at a time will be pushed to be voted on as a referendum. The reason for having 1 referendum at a time is to avoid situations where we vote for 2 completely opposite actions and both passing. In order for things to be fair, the public token holders and council will rotate who gets to make the proposal each launch period.

3. A special case is the technical committee, which can create their own proposals with drastically reduced voting and enactment periods, in order to push stuff like bug fixes much quicker. A technical committee referendum is allowed to run alongside other referendums, which is an exception to the rule we established earlier. Even though these referendums are fast tracked, they still have to be voted on by the public.

It is possible to have instant or fast-tracked launch periods. In our runtime instant launch periods can happen when the technical committee unanimous. It can be fast-tracked with two-thirds of the technical committee agree.

Similarly proposals can also be canceled before they become referendums.

Voting Period

At this point things converge and the process is the same no matter how the referendum was created. The majority of the stake needs to make a decision. No matter what, if 51% of the total stake votes on something it will be passed. But in the case of low voting turnouts there's a mechanism called Adaptive Quorum Biasing, which will change the pass thresholds depending on vote participation. Most of the time with a bias towards not passing.

Here's where technical committee and council have slightly more power. For example unanimous proposals will have lower thresholds to pass during the voting period.

Moreover referendums can also be canceled, i.e. if a bug is found late in the process. However referendums can only be cancelled once, and then can then be resubmitted.

Enactment Period

At this point the system has autonomy and simply executes the passed referendum using pallet_scheduler. As we mentioned before the reason for the delay is for stake holders to either prepare for the change or leave the system if they are not ok with it.

This period can be drastically reduced for referendums that are created by the Technical Committee.