-
Notifications
You must be signed in to change notification settings - Fork 537
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
feat: add BEP-295 BSC Native Governance Module
- Loading branch information
1 parent
bfe4fdb
commit f7ece0a
Showing
1 changed file
with
157 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,157 @@ | ||
| <pre> | ||
| BEP: 297 | ||
| Title: BSC Native Governance Module | ||
| Status: Draft | ||
| Type: Standards | ||
| Created: 2023-10-16 | ||
| </pre> | ||
|
|
||
| # BEP-297: BSC Native Governance Module | ||
| - [BEP-297: BSC Native Governance Module](#bep-297-bsc-native-governance-module) | ||
| - [1. Summary](#1-summary) | ||
| - [2. Abstract](#2-abstract) | ||
| - [3. Status](#3-status) | ||
| - [4. Motivation](#4-motivation) | ||
| - [5. Specification](#5-specification) | ||
| - [6. License](#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 significant achievement 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](https://docs.openzeppelin.com/contracts/4.x/governance). | ||
|
|
||
| # 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 Governance Token | ||
|
|
||
| The lifecycle of staking credit and gov token are identical. | ||
|
|
||
| - When users stake, they simultaneously mint both the staking credit and the governance token. | ||
| - Similarly, when users unstake, both the staking credit and governance token are burned simultaneously. | ||
|
|
||
| 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 governance 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. | ||
|
|
||
| By default, token balance does not account for voting power. Vote power can be delegated either by calling the **delegate** function directly, or by providing a signature to be used with **delegateBySig**. This contract keeps a history (checkpoints) of each account’s vote power. Voting power can be queried through the public accessors **getVotes** and **getPastVotes**. | ||
|
|
||
| ## 5.3 Governance Workflow | ||
| ### 5.3.1 Community Discussion | ||
|
|
||
| BSC governance is driven by the BNB Chain community. Governance discussions happen in many places moderated by diverse community members, including github, forum, discord, twitter and anywhere else the BNB Chain community stays. Once a proposal is on-chain, it cannot be modified to incorporate feedback. Therefore, it is crucial to allow the proposal sufficient time off-chain to gather feedback, input, and edits before proceeding on-chain and requesting votes. This guide may not encompass every possible approach to engagement, but it provides several suggestions: | ||
|
|
||
| - Post your idea to the Forum. | ||
| - Create a BEP for your idea. | ||
| - Create an issue on the BSC repo directly. | ||
|
|
||
| ### 5.3.2 Create Proposal | ||
| A proposal is a sequence of actions that the Governor contract will perform if it passes. Each action consists of a target address, **calldata** encoding a function call, and an amount of ETH to include. Additionally, a proposal includes a human-readable description. | ||
|
|
||
| BSC manages proposals on [Tally](https://www.tally.xyz/), **Tally** is a full-fledged application for user owned on-chain governance. It comprises a voting dashboard, proposal creation wizard, real time research and analysis, and educational content. | ||
|
|
||
| To submit an onchain proposal, a user must have sufficient voting power to meet the DAO's Proposal threshold. Proposer need to write Title and Description for the proposal, explain the intent behind the proposal and include any helpful 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 what kind of intention. | ||
| - **Value**. The **value** parameter in different target contracts has different meanings. It usually represents a modified value. | ||
|
|
||
| For text proposals, just create a proposal with no actions, a transfer of 0 BNB to the proposer will be added, as Governor requires one executable action for the proposal to be submitted onchain. | ||
|
|
||
| The proposal is delayed to become active after creation. | ||
|
|
||
| ### 5.3.4 Vote on Proposal | ||
| Once a proposal is active, delegates can cast their vote. Note that it is delegates who carry voting power: if a token holder wants to participate, they can set a trusted representative as their delegate, or they can become a delegate themselves by self-delegating their voting power. When governance participants go to place their vote, they are given three options: | ||
|
|
||
| 1. **For** generally means that voter want the contents of the proposal to be enacted and. | ||
| 2. **Against** signalling that voters do not. | ||
| 3. **Abstain**. The voter wishes to contribute to quorum without voting for or against a proposal. | ||
|
|
||
| If the power of a vote is larger than **GovernorPreventLateQuorum** * **TotalVotingPower**, the proposal’s voting period may be extended so that it does not end before at least a specified time has passed. This prevents a large voter from swaying a vote and triggering quorum at the last minute. | ||
|
|
||
| ### 5.3.5 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** and **Abstain**. | ||
| - Threshold: The voting power of **For** is larger than **Against**. | ||
|
|
||
| ### 5.3.6 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** to interact with the timelock contract and queue the actions for execution after the required delay. Both the queue and execute functions require passing in the entire proposal parameters, as opposed to just the proposal id. This is necessary because this data is not stored on chain, as a measure to save gas. | ||
|
|
||
| For proposals that have been manipulated by vulnerabilities, that belong to (1) spam, (2) infringement on minority interests, and (3) violation of rules of engagement, the community still gets time to take action. | ||
|
|
||
| ## 5.4 Proposal Type | ||
|
|
||
| ### 5.4.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.4.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 EOA to play some key role in the system. | ||
|
|
||
| 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](https://creativecommons.org/publicdomain/zero/1.0/). |