BEP-297: BSC Native Governance Module

[SolidityGo]

  BEP: 297
  Title: BSC Native Governance Module
  Status: Draft
  Type: Standards
  Created: 2023-10-16

BEP-297: BSC Native Governance Module

• BEP-297: BSC Native Governance Module
• 1. Summary
• 2. Abstract
• 3. Status
• 4. Motivation
• 5. Specification
• 6. License

1. Summary

Native Governance is incorporating governance logic into the BNB Smart Chain instead of delegating this responsibility to the BNB Beacon Chain. BSC Native Governance is a primary goal for the BNB Chain Fusion. The proposal allows community members to submit proposals directly on the BSC network. Any staking credit holders are allowed to vote on these proposals, and the passed proposals will be executed automatically on the chain or manually off-chain.

2. Abstract

Native Governance has several significant differences and improvements compared to current implementations:

• Any staking credit holders are allowed to propose and vote.
• Voters can continue to earn staking rewards during the voting period.
• Users have the option to delegate someone else to participate in governance on their behalf.
• The proposer can cancel the proposal at any time.
• A time lock period is introduced before the proposal is executed.
• If the proposal is not approved, the proposer won't suffer any financial losses anymore.

The overall governance framework is derived from OpenZeppelin Governor.

3. Status

Draft.

4. Motivation

In the framework of the dual-chain structure, the Governance module from Cosmos-SDK is currently being utilized to manage proposals, votes for the BSC network. Subsequently, the tally results are transmitted to the BSC network through a cross-chain protocol, triggering automatic execution, like changing the parameter of system contract, adding whitelist relayers.

With the progress of BNB Chain Fusion, BNB Beacon Chain no longer exists, thus the governance functionality will be migrated from Beacon Chain to Smart Chain. In addition to addressing migration requirements, this proposal also aims to enhance the existing governance mechanism and encourage more community participation.

5. Specification

5.1 Definitions

• BSCGovernor Contract: A new system smart contract to manage the lifecycle of proposals and votes.
• GovToken Contract: A new system contract to manage the user's voting power, the token is not transferable.
• Staking Credit: Staking Credit is a cryptocurrency token that aims to represent a BNB that is "staked" to a specific validator on BSC. Different validators on the BSC issue distinct staking credit tokens.

5.2 Proposal Type

5.2.1 Text Proposal

Text proposals are used to make an on-chain record of support or agreement on a certain topic or ideas. Text proposals do not contain any code. That is, they do not directly cause any direct changes to the BSC once passed. Technically, nothing happens on-chain, but we all get information from it having been considered:

• The community engaged in a comprehensive and insightful discussion on a topic that would have otherwise been overlooked.
• A development team interested in a feature may have a clearer understanding of how the community will receive their work.
• The community can have a sense of assurance that we share a common understanding or social standard.

5.2.2 Executable Proposal

An executable proposal is used to make substantial modifications to on-chain protocols in BSC. The Executable proposal consists of a list of triplets in the form of (string key, bytes value, address target).
Target is the desired target contract. The key and value represent the parameters for invoking the target contract. The target contract must implement the interface: function govCall(string key, bytes value).

We use executable proposals in the following scenarios:

• Change the parameter of the system contract.
• Enable or disable some functionality of the system contract.
• Adding EOAs to play some key role in the system.

5.3 Governance Token

The lifecycle of staking credit and gov token are identical.

• When users stake, they mint both the staking credit and the governance token.
• Similarly, When users undelegate, both the staking credit and governance token are burned.

Due to the non-transferability of governance tokens and staking credits, these two scenarios can cover all possible situations.

In an ideal scenario, the balance of a user's gov token should be equal to the total BNB value of all staking credits held by the user. This condition does not hold true in the following situations:

1. The validator receives block rewards.
2. User stakes to the validator.
3. User unstakes from the validator.
4. The validator is slashed.

When the above situation occurs, the protocol will call the sync interface of the GovToken, either mint or burn gov token to ensure the equation holds true. Scenario #1 is an exception where the sync function is not automatically invoked. Users can either manually invoke the sync interface or wait for the next stake or unstake operation to occur.

Token balance does not contribute to voting power directly. Voting power can be increased by directly invoking the delegate function or by providing a signature to be used with delegateBySig. The contract allows querying the voting power of any account at any height without requiring an archive node. It achieves this by keeping checkpoints of each account's voting power. These features are implemented through inheritance of ERC20Votes.

5.4 Governance Workflow

5.4.1 Community Discussion

BSC governance is driven by the BNB Chain community. Governance discussions occur in various community-moderated platforms such as GitHub, forums, Discord, Twitter, and other channels where the BNB Chain community gathers. Once a proposal is on-chain, it cannot be modified to include feedback. Hence, it is essential to give the proposal enough time off-chain for gathering feedback, input, and edits before advancing it on-chain for voting. While this guide may not cover all possible engagement methods, it offers several suggestions:

• Post your idea to the Forum.
• Create a BEP for your idea.
• Create an issue on the BSC repo directly.

5.4.2 Create Proposals

BSC proposals can be managed on UIs integrated with the onchain smart contracts, such as Tally. Tally is a comprehensive application designed for users to engage in on-chain governance. It offers a user-friendly voting dashboard, intuitive proposal creation wizards, real-time research and analysis tools. With Tally, users can actively participate in the decision-making process and contribute to the growth of BSC.

To submit an on-chain proposal, a user must have enough voting power to meet the Proposal Threshold, such as 100 BNB. Proposers should draft a Title and Description for the proposal, explain its intent, and include any relevant context for the voters.

To create an executable proposal, we need to add actions. The call data of the action contains three parts:

• Target. The target contract to call.
• Key. Key meanings vary across different target contracts, typically indicating the intended purpose.
• Value. The meaning of the Value parameter varies among different target contracts. Typically, it signifies a modified value.

To create a text proposal, simply create a proposal without any actions.

The proposal is delayed to become active after creation. For example, allocate a 3-day timeframe for the community to participate in detailed discussions and establish voting preferences.

5.4.3 Vote on Proposal

Once a proposal is active, delegates can vote as only delegates have voting power. Staking credit holders who want to participate in governance voting must either select a trusted representative as their delegate or become a delegate themselves by self-delegating their voting power. When governance participants cast their votes, they get three options:

1. For generally means that voter want the proposal to be enacted.
2. Against signals that voters do not want the proposal to be enacted.
3. Abstain. The voter wishes to contribute to the quorum without voting “for” or “against” a proposal.

GovernorPreventLateQuorum extension will be enabled to prevent a single voter from swaying the vote and triggering quorum at the last minute. It ensures that there is sufficient time for the community to react.

5.4.4 Tally

Following requirements need to be met for a proposal to be accepted by the end of voting period:

• Quorum: A minimal of 10% of total voting power votes For.
• Threshold: The voting power of For is larger than Against.

5.4.5 Timelock and Execution

Once a proposal passes, it can be queued and executed. The first step to execution is queueing, this will cause the Governor Contract to interact with the timelock contract and queue the actions for execution. After the required delay, anyone is allowed to trigger the execution.

The community has time to take action on proposals that have been manipulated due to vulnerabilities, fall under spam or violate rules of engagement. However, these actions are often beyond the scope of on-chain protocols, such as validators reaching a consensus to veto a passed proposal through a hard fork. Such a situation should be avoided at all costs.

5.5 Proposal Status

• Publish. The proposal is created but not active for vote yet.
• Active. The proposal is active for vote.
• Defeated. The proposal is rejected.
• Canceled. The proposal is canceled.
• Accepted. The proposal is passed but not queued yet.
• Queued. The proposal is queued in the TimeLock contract but not ready for execution.
• AwaitingExecution. The proposal is ready for execution after queued.
• Executed. The proposal is executed.

6. License

The content is licensed under CC0.