OpenGov 1.0 is Polkadot’s first-generation open governance model, which we previously introduced in the article “Bifrost Governance on Subsquare I: General Introduction.”

The core feature of OpenGov 1.0 is the adoption of a tricameral structure.

• The Council is responsible for approving financial proposals and holds the privilege to initiate external proposals.
• The Technical Committee can fast-track external proposals, reducing their voting period. This mechanism primarily applies to handling technical issues and fixing critical vulnerabilities.
• Referenda are conducted for public proposals suitable for most non-urgent matters. Any governance token holder can initiate a public proposal. Governance token holders vote on public proposals through a conviction voting mechanism. Only one public proposal can be in the voting phase at a time.

During the early stages of project development, the tricameral structure effectively coordinates governance power between the team and the community. Moreover, it ensures the security and flexibility of governance decisions to the fullest extent. However, as the project matures, the community inevitably demands a more decentralized approach to project governance. OpenGov 2.0 is the result of Polkadot responding to this demand.

Compared to OpenGov 1.0, the most notable change brought by OpenGov 2.0 is eliminating the Council and the Technical Committee. All decisions are now exclusively handled through referenda. At the same time, additional governance tracks have been introduced, enhancing the governance process and delegation mechanism. Furthermore, a fellowship of experts has been established.

This article aims to provide a comprehensive overview of the framework and structure of OpenGov 2.0.

Governance Process

In OpenGov 2.0, the proposal process is divided into the following steps:

Preparation Period

After a proposal is initiated, it enters the preparation period. During this stage, the proposer is required to deposit a stake. If the stake is not deposited by the preparation period’s end, the proposal becomes invalid. After the stage starts, users can immediately start participating in the voting during this stage. However, regardless of the voting threshold reached, the proposal will not be concluded during this period. (This prevents whale holders from quickly passing proposals without others having time to notice.)

Decision Period

During this stage, users can always participate in voting. Once the voting threshold is reached, the proposal enters the confirmation period. There are two voting thresholds: the relative majority threshold and the absolute majority threshold. In other words, a proposal must satisfy the relative majority and absolute majority thresholds to enter the confirmation period. It is important to note that these thresholds are dynamic and represented by two curves. As the decision period approaches its end, the thresholds tend to decrease. However, the relative majority threshold will never be lower than 50%.

A proposal must meet the threshold requirements at the end of the decision period to be considered accepted.

Confirmation Period

Proposals that meet the threshold requirements during the decision period enter the confirmation period. Even during the confirmation period, users can continue to vote. Throughout the confirmation period, the proposal must consistently meet the threshold requirements. Once the confirmation period ends, the proposal is officially approved and enters the execution period. If, during the confirmation period, users continue to vote in a way that no longer meets the threshold requirements, the proposal will be returned to the decision period. In such cases, when the proposal re-enters the confirmation period, its confirmation period timer will reset.

Enact Period

Once a proposal is approved, it enters the execution phase, and upon completion of the execution phase, the proposal officially takes effect on the blockchain. The proposer can customize the duration of the execution phase, but it must not be shorter than the minimum execution period set by the track in which the proposal is located.

Governance Track

In OpenGov 2.0, the referendum is the sole governing body. Multiple tracks are available to handle proposals, each with its own set of parameters to enhance the efficiency of referendum decision-making.

Taking Polkadot as an example, Polkadot has established 26 different tracks.

The track capacity refers to the maximum number of proposals that can be processed simultaneously in a given proposal track. The deposit refers to the amount of funds a proposer is required to stake, and its existence prevents the submission of spam proposals. The preparation period, decision period, confirmation period, and minimum execution period are the deadlines for each proposal stage in the track. In addition, each track has two different threshold curves.

These different proposal tracks have varying degrees of authority, with some having greater authority than others. The level of risk associated with the proposals also varies, with more risky proposals having a greater impact on the system or involving larger amounts of treasury spending. We have observed that tracks with greater authority have smaller capacity, longer preparation periods, confirmation periods, and minimum execution periods, and require larger deposits.

The tracks Small Tipper, Big Tipper, Small Spender, Medium Spender, Big Spender, and Treasure can all be used to request funding from the treasury. However, they have different maximum payment limits and corresponding parameters. For instance, with the lowest authority, the Small Tipper track allows a maximum one-time payment of 250 DOT from the treasury. Its preparation period, confirmation period, and minimum execution period are only 1 minute, 10 minutes, and 1 minute, respectively. The proposal deposit for this track is merely 1 DOT.

On the other hand, the Treasure track, with the highest authority, permits a maximum one-time payment of 10,000,000 DOT from the treasury. Its preparation period, confirmation period, and minimum execution period are as long as 2 hours, 3 hours, and 1 day, respectively. The proposal deposit for this track amounts to 1000 DOT. Furthermore, there is a significant difference in track capacity between the two. The Small Tipper track has a capacity of 200 proposals, while the Treasure track can only accommodate 10 proposals.

The same applies to non-treasury proposals. With the highest authority, the root track supports proposals for arbitrary modifications to the on-chain code, which significantly impact the system. Therefore, the track capacity is limited to 1, with a deposit requirement of only 100K DOT. The preparation period, confirmation period, and minimum execution period for this track are all relatively long. Other tracks, which only manage specific domains with a smaller impact on the system, have more relaxed parameters.

Through this design, OpenGov2.0 can handle non-risky proposals swiftly while exercising caution with risky proposals.

We have also discovered that some tracks can handle specific types of proposals. For example, the Referendum Canceller and Referendum Killer can cancel spam or malicious proposals. The Whitelist Caller can handle emergency proposals, while the Fellowship admin track can manage Fellowship-related affairs. We will delve into these topics further in the next part.