Bera Governance Token

General Introduction

Berachain’s reward layer is facilitated through the BGT token, which operates as a means to acquire dApp fees, protocol incentives, and governance functions. This section delves into the technical implementation of the value-capturing mechanisms (VCMs) of the Berachain Governance Token (BGT). BGT employs three distinct VCMs: the YBSTwB , Generalized Governance, and Representation. The YBSTwB VCM enables BGT holders to delegate their tokens to validators through a "boosting" process, which channels protocol incentives and core dApp fees to participants. The Generalized Governance VCM allows BGT holders to engage in governance by creating proposals, casting votes, and whitelisting Reward Vaults to receive BGT emissions. Lastly, the Representation VCM provides a mechanism for BGT holders to redeem their tokens for BERA at a 1:1 ratio, exiting the BGT system. These VCMs are implemented through a series of smart contracts: the YBSTwB VCM involves contracts such as BGTStaker, FeeCollector, BGTIncentiveDistributor, RewardVault, and BeraChef to manage delegation and reward distribution; the Generalized Governance VCM relies on the Governance contract to handle voting and proposal execution; and the Representation VCM is executed via the BGT token contract for redemption into BERA. The detailed workflows for each VCM’s implementation will be explored in their respective subsections below.

1. The YBSTwB Implementation

The YBSTwB VCM is implemented through a network of contracts: BGTStaker, FeeCollector, BGTIncentiveDistributor, RewardVault, and BeraChef. Together, these contracts enable BGT holders to delegate tokens and earn incentives. BGT holders initiate delegation by queuing or activating boosts via the BGT contract, which then internally calls the (permissioned) stake method of the BGTStaker contract to stake their BGT; this allows the holders to earn proportional shares of the dApp fees in WBERA.

These fees are collected by the FeeCollector contract, which auctions fee tokens for WBERA and transfers the payoutAmount to BGTStaker. Holders claim these fees using the getReward method of BGTStaker.

BGT holders are also allowed to boost validators through the BGT contract (even when they do not do so, they merely boost themselves); this begets emissions allowing the boosted validators to participate in the incentive marketplace. The validator operators may queue their commission rates on incentive tokens using the queueValCommission method of the BeraChef contract. These rates are activated via activateQueuedValCommission after a delay, determining the validators’ direct share of incentives (aside from any self-boosts). The protocols deposit incentives into whitelisted RewardVaults using addIncentive, a process initiated when BGT holders cast votes through the Governance contract to whitelist vaults via BeraChef. Incentives are distributed via _processIncentives through the RewardVault contract: a (commission) portion goes to validators, while the remainder is sent to the BGTIncentiveDistributor contract via receiveIncentive, and the boosters may thereafter claim their share using claim.

A summary of the mechanisms whereby the Incentive Marketplace operates:

1. The validator is allotted additional emissions in addition to his regular reimbursement. The value is given by the formula

$additional\_emission = \max \left( m,\ (1 + a)R \left(1 - \frac{1}{1 + ax^b} \right) \right)$

• x – boost, or the fraction of BGT delegated to the validator in question
• R – base BGT reward rate
• a – boost impact coefficient
• b – boost impact curve shape parameter
• m – floor for reward vault emissions (i.e., additional emissions)

2. These emissions are directed towards a Reward Vault the validator chooses (he may choose a number thereof; the explanation considers one Vault only, as the mechanism remains the same).
3. If $\text{nTokens}$ have been directed towards the Vault, and it has an Incentive Rate of $y$ $\frac{\text{Incentive Tokens}}{BGT}$, then, provided it has sufficient reserves of the Incentive Token, $y\cdot \text{nTokens}$ Incentive Tokens will be released.
4. Of these, the validator takes the preset commission. The rest is distributed proportionally to all boosters of the validator in question.

In other words, the proportional allocation due to a single boost unit comes up to (for one Incentive Token in one Reward Vault and sufficient Incentive Token reserves):

$incentive\_per\_boost = (1 - commission) \cdot \frac{additional\_emission \cdot y}{x}$

• x — boost, or the fraction of BGT delegated to the validator in question
• additional_emission — see above
• y — incentive rate
• commission — portion of the incentives the validator retains

The commission level of a validator is set in advance and can only be changed with 16 382 blocks' advance warning.

Key Contracts:

• BGTStaker: Core logic for staking.
• FeeCollector: Core logic for dapp fee collection.
• Berachef: Core logic for incentive weights.
• BGTIncentiveDistributor: Core logic for staking.
• RewardVault: Core logic for reward vaults.

2. The Generalized Governance Implementation

The Generalized Governance VCM is implemented primarily through the Governance contract, which leverages OpenZeppelin’s governance framework to enable BGT holders to participate in Berachain’s decision-making processes. This contract facilitates key governance functions, allowing holders to propose, vote on, and execute changes such as whitelisting Reward Vaults for BGT emissions or adjusting dApp parameters. BGT holders initiate governance by calling the propose function, requiring a minimum of 10,000 BGT to create a proposal with details like target contracts and actions. A 1-hour pending state follows before the 5-day voting period begins, during which holders use castVote to vote, with voting power derived from their BGT holdings. A 51% approval threshold is ensured via _voteSucceeded, and a quorum of 20% of the total BGT supply must be met. Once a proposal passes, _queueOperations schedules the execution with a 2-day timelock delay via a separate ancillary contract, and _executeOperations finalizes the action, updating the ecosystem accordingly.

Key Contracts:

• Governance: Core logic for governance.

3. The Representation Implementation

The Representation VCM is implemented through the BGT token contract, enabling BGT holders to redeem their tokens for BERA at a 1:1 ratio. This mechanism allows holders to exit the non-transferable BGT system by converting their tokens into BERA. The core functionality is handled by the redeem function, which burns the specified amount of BGT from the caller’s balance and transfers an equivalent amount of BERA to a designated receiver. Before execution, the contract ensures the caller has sufficient unboosted BGT (not delegated or queued for boosting) via checkUnboostedBalance. The _burn function reduces the BGT total supply, while SafeTransferLib.safeTransferETH sends BERA to the receiver. Additionally, the burnExceedingReserves function allows excess BERA reserves to be burned, ensuring the contract’s balance aligns with the total BGT supply and potential mintable tokens.

Key Contracts:

• BGT: Core logic for BGT-BERA swap.