Like the early development of most Web3 projects, Bifrost, which launched in 2019, initially adopted a Sudo (super administrator) mechanism controlled entirely by the project team. This mechanism allowed the team to execute a series of critical on-chain operations related to the product’s underlying logic, ensuring a smooth launch and stable operations.

In September 2021, Bifrost officially rolled out its democracy governance module, removing the Sudo (super administrator) privileges and transitioning to a decentralized governance model, Gov 1.0, aligned with Polkadot’s structure. This governance framework is based on a tripartite system consisting of the Council, Technical Committee, and public referenda, embodying a separation of powers.

As the protocol matured, and with the release of Polkadot’s Gov2.0, also known as OpenGov, Bifrost quickly followed suit by introducing its own OpenGov governance system, placing community referenda at the heart of the decision-making process.

What is OpenGov?

Let’s first delve into the basic structure of OpenGov.

Polkadot's OpenGov replaces the tripartite structure of Gov1.0, shifting to a system where all governance proposals are decided through referenda. The former Council and Technical Committee have evolved into the Fellowship, which influences decisions more through reputation and influence rather than direct voting power. The Fellowship's only governance privilege is providing a secondary approval for emergency proposals (those under the WhitelistCaller track).

The Fellowship has its own internal voting and decision-making mechanism, where higher-ranked members possess greater voting weight. However, referenda can still hold authority over the Fellowship, as their governance power supersedes the internal voting outcomes of the Fellowship.

To improve the efficiency of referenda execution, OpenGov categorizes governance proposals into different tracks. At any given time, only one proposal can be active per track, though multiple tracks can progress proposals simultaneously. Each track is tailored with specific parameters based on the "risk level" of proposals—lower-risk proposals have reduced deposit requirements, lower approval thresholds, and shorter decision-making periods, whereas higher-risk proposals have more stringent requirements.

OpenGov also offers a delegation option for those lacking the time or expertise to participate directly in governance. Users can delegate their votes to others, enabling proxy voting. Moreover, users can delegate their votes to different representatives for each track, ensuring that experts can make decisions in their respective domains.

A proposal progresses through four stages from initiation to execution:

Preparation Period: After submission, the proposal enters the preparation period, where the initiator must place a deposit.

Decision Period: During this period, users can vote on the proposal. If the proposal meets the threshold conditions, it moves to the confirmation period. There are two threshold conditions: Support and Approval. Support is solely based on the number of votes, while Approval takes into account both the vote count and the duration of stake, with longer staking periods yielding higher Approval.

It’s important to note that these thresholds are dynamic and vary throughout the decision period, generally decreasing as the decision period progresses.

Confirmation Period: Users can continue voting during this phase, and the proposal must maintain its threshold conditions throughout. The confirmation period helps prevent manipulation by large holders, who might otherwise sway the outcome by casting votes at the last second during the decision period.

Execution Period: Once a proposal passes the confirmation period, it moves into execution, becoming effective on-chain after this stage.

Through OpenGov, Polkadot has achieved a fully community-driven governance model, positioning itself as a leader in governance innovation within the blockchain space. For a more detailed analysis of Polkadot OpenGov, please refer to our research report: Bifrost Governance on Subsquare I: General Introduction and Bifrost Governance on Subsquare II: Democracy & Treasury

Bifrost OpenGov

Bifrost has established eight tracks, each closely related to its operations:

1. Root: This track holds Sudo-level privileges, allowing the invocation of any method and making arbitrary system changes. It is primarily used for runtime and system fixes, as well as underlying adjustments.

2. WhitelistCaller: This track is used to initiate fast-track proposals, which have a shorter decision period and lower approval thresholds to address urgent matters. However, such proposals require secondary approval from the Fellowship after being passed.

3. Liquid Staking: This track merges the previous VET (Validator Election Track) and SystemStaking tracks. It has three main functions:

   • Approving various vToken Validator White Lists (VWL) and Validator Boost Lists (VBL). VWL and VBL represent validator nodes eligible to receive staking delegations from the Bifrost protocol, although the application processes for joining these lists differ. For more details, refer to the article "VET - Multi-Chain Validator Election Mechanism of Bifrost Based on Polkadot Governance 2.0."
   • Managing parameters related to System Staking, such as staking ratios and adjustment methods. System Staking is a unique feature of the Bifrost protocol, where a portion of the assets locked in the Bridge is used for staking to generate additional revenue, which is added to the earnings of vToken holders to enhance the overall yield.
   • Adjusting the vToken Reward Fee (protocol fee), in addition to managing various Liquid Staking parameters.

4. SALP Admin: Manages operations related to SALP (Slot Auction Liquidity Protocol). SALP is a service Bifrost provides for slot auctions, allowing the liquidity of DOT/KSM locked in crowdloans to be released. However, with slot auctions gradually losing prominence within the Polkadot ecosystem, the SALP service will also be phased out.
5. FellowshipAdmin: Handles the management of Fellowship members, including adding or removing members and upgrading or downgrading their status. As previously mentioned, the decisions made through this track hold higher authority than the Fellowship's internal management decisions.
6. ReferendumCanceller: Used to cancel an ongoing proposal.
7. ReferendumKiller: Used to cancel an ongoing proposal and slash its deposit, typically used to address malicious or high-risk proposals.
8. Treasury Spend: Approves financial expenditures.

Each of these eight tracks has distinct parameters. For example, the high-risk Root track requires a stake of 50,000 BNC to enter the voting period, whereas the lower-risk SALP Admin track only requires a stake of 2,500 BNC. Detailed parameters for all eight tracks can be found in the Bifrost Docs.