In the previous article, we discussed how OpenGov 2.0 removes the Council and Technical Committee present in OpenGov 1.0, making referenda the sole decision-making authority.

All referendum proposals are categorized into Tracks, each with different parameters to handle proposals of varying “risk levels.” Additionally, the referendum proposal process in OpenGov 2.0 is more refined, consisting of four stages: preparation, decision, confirmation, and execution.

In addition to the improvements mentioned above, OpenGov 2.0 introduces innovative interventions for risky proposals, a more flexible delegation mechanism, and the concept of Fellowship.

Intervention for Risky Proposals

OpenGov 2.0 has established an intervention process for risky proposals in addition to the preparation period to ensure safe governance and prevent malicious proposals from being passed.

Within the Polkadot governance tracks, there are two unique tracks, the Referendum Canceller and the Referendum Killer. These tracks require a substantial DOT stake and have almost unlimited capacity. They are used to cancel other proposals, but the Referendum Canceller only cancels the proposal, while the Referendum Killer also forfeits the proposer’s deposit. The Referendum Killer is an effective deterrent for malicious proposers.

Once a proposal enters the Referendum Canceller or Referendum Killer process, its progress will be immediately suspended regardless of its current stage (even during execution).

Delegations by Tracks

OpenGov 2.0 inherits the conviction voting mechanism from OpenGov 1.0. Under this mechanism, the voting capacity/weight is determined by the number of governance tokens used for voting and how long a voter is willing to lock their tokens into the system.

The longer the staking duration, the stronger the “belief” represented, resulting in a higher voting utility bonus.

In governance practice, many token holders often lack the time and expertise to participate in decision-making. Therefore, a delegation mechanism is necessary. OpenGov 1.0 allowed users to delegate their governance powers to others to exercise on their behalf.

Users can withdraw or change their delegation at any time. OpenGov 2.0 further refines this rule by allowing users to delegate the same voting power to different people for different tracks.

The benefit of doing this is that it allows experts in different issues to utilize their expertise fully. For example, I can delegate the voting power for treasury decisions to an operations expert and delegate the voting power for technical decisions to another technical expert.

Fellowship

The Fellowship is an autonomous group of experts understood as a more decentralized technical committee. While the initial members of the Fellowship will come from the committee, it differs from the committee in that it aims to encompass broader members. Polkadot will incentivize them through specific mechanisms to contribute to developing and optimizing the Polkadot ecosystem continuously. Furthermore, the Fellowship is not strictly a governing entity and does not possess any direct privileges in terms of governance power.

Only one specific track, the Whitelist Caller, will be associated with the Fellowship. The Whitelist Caller is similar to the Fast Track in OpenGov 1.0 and executes urgent bug fixes. The preparation and enactment periods for this track are relatively short, and the two threshold values for passing votes decay quickly with a steep curve. However, for proposals in this track that are approved and enter the execution phase, they require a secondary confirmation vote from the Fellowship before being formally executed.

The Fellowship’s governance interface governs matters such as recruitment, removal, and rank changes of Fellowship members. Adding new members requires recommendations from existing members and is confirmed through internal voting. Fellowship members have their ranks determined by their contributions to the Polkadot ecosystem, and these ranks will determine the weight of their votes in internal voting.

For more details, please refer to the official document released at: https://github.com/polkadot-fellows/manifesto/blob/5e01eef15eded63f1db9be808b0f7c11bb9f4a12/manifesto.pdf.

The Fellowship admin track in referendums can also manage Fellowship affairs with higher authority than the internal autonomous decision-making of the Fellowship.

Conclusion

The transition from OpenGov 1.0 to OpenGov 2.0 has improved the governance process of Polkadot by enhancing governance efficiency and flexibility while ensuring security, all while achieving a high level of decentralization. Overall:

• Power distribution: In OpenGov 2.0, governance token holders have a complete control over governance without the need for other governing entities.
• Decision-making efficiency: OpenGov 2.0 introduces multiple tracks to accommodate proposals with different processes and capacities. These tracks can operate simultaneously, significantly improving decision-making efficiency.
• Governance security: OpenGov 1.0 relied more on the council as the sole firewall, while OpenGov 2.0 relies on cleverly designed mechanisms.

As a member of the Polkadot ecosystem, Bifrost will adopt a governance mechanism congruent with Polkadot. Currently, Bifrost is utilizing Gov 1.0 and will transition to OpenGov 2.0 in the near future.