Skip to main content
Reward Vaults drive meaningful economic activity on Berachain. To qualify for BGT emissions, your vault must show that it supports ecosystem goals and creates real user value. This guide captures all essential requirements. For submission forms and the request process, see Reward Vault Governance.

​
Ecosystem value requirements

​
Adds ecosystem utility

  • The vault must boost use or value of BERA or other major assets.
    • For example: enhancing yield across “Major” assets (as defined below) to encourage looping activity, or utilization of yield-bearing collateral across more exotic trading pairs, or other revenue-generating use cases.
  • This can happen through:
    • Liquidity pools (e.g., paired with BERA or majors)
    • Vault structures that carry out more complex multi-step operations
  • Proposals should clearly explain how the Reward Vault will help scale your existing product. How does this vault become more than a simple farm?
  • The best barometer for ecosystem utility is often correlation to some tangible, empirical metric of interest. PoL does not work if it solely subsidizes idle capital. PoL works when it encourages economic activity, which often shows up as application revenue, volume, fee generation, or user growth.
  • The above guidelines require some nuance. There is value in experiments, whether in memecoins, token launchers, RWAs, consumer applications, and more. For established DeFi applications or adjacent vault products, there should be a path toward sustainable economic activity and growth.

​
Reasonable emission fees

  • Fees taken on yield must not be excessive and must not be used mainly to recycle incentives.

​
Yield stacking restrictions

  • If a vault (e.g., ERC-4626) generates yield from BGT farming, the majority of that yield must be passed through to stakers, not recycled.
  • Yield from non-BGT sources can be recycled into incentives.
  • This prevents double-dipping BGT rewards without adding utility.

​
Technical requirements

All Reward Vaults must meet these expectations:

​
Open access

  • The staking token must be accessible to everyone, with no special permissions or barriers.
  • Special exceptions may apply for certain real-world asset (RWA) protocols that require permissioned or compliance-specific applications.

​
Standard ERC20 token

  • The staking token must be a standard ERC20 token.

​
Rebasing tokens

  • Rebasing staking tokens must use a wrapper.
  • This does not apply if the rebasing rate is 0% (e.g., OHM).

​
Verified contract

  • The token’s smart contract must be verified on-chain and publicly viewable on tools such as Berascan.

​
Audits

  • The protocol must have at least one audit and no recent exploits.
  • If an exploit occurred, the proposer must provide clear evidence that the issue has been resolved.

​
Staking and incentive token liquidity requirements

The tokens must have sufficient liquidity to support sustainable participation:
  • The token should have at least $100,000 in Total Value Locked (TVL).
  • If the token represents a decentralized exchange (DEX) liquidity pool, it must meet the following criteria:
    • At least $50,000 in TVL paired with a “Major” asset, defined as:
      • BERA, HONEY, BYUSD, USDC, wETH, wBTC, stablecoins
      • Or other widely recognized, large-cap tokens (e.g., SOL, or comparable assets reasonably within the top 10 by market capitalization; only established tokens are eligible—purely speculative or memecoin assets do not qualify)
      • An asset that is a wrapper of a major asset listed above
      • An asset that is minted using a major asset as collateral
  • The token must be deployed and verified on-chain.
Why focus on majors?
  • Boosts fee generation: major-token pairs attract higher trading volumes, increasing fees for liquidity providers and making Berachain a home for desirable assets.
  • Reduces volatility risk: major tokens are more stable, lowering impermanent loss for liquidity providers.
  • Democratized access: requiring a major token in every liquidity pair lowers barriers to entry so new users can participate without acquiring obscure or illiquid tokens.
Why enforce a minimum TVL requirement?
  • Serves as a filter for teams that might look to extract from the system, and demonstrates some degree of capital at risk and ideally multiple participants from the community, indicating broader interest and trading potential for the pair.

​
Contracts must be live

  • All contracts being incentivized must be already deployed and fully live on-chain.
  • No rewards for theoretical, unlaunched, or coming-soon contracts.

​
Protocol must be live

  • The protocol itself must be live on-chain and actively operating before applying for a Reward Vault.

​
Gas efficiency

  • Transfers must not exceed 500,000 gas units per transaction to keep fees reasonable.

​
Minimum program viability

​
Sufficient duration

  • Incentives must run at least 2 months to sustain engagement.

​
Sustainable incentives

  • Must target $10,000+ per month in incentives.
  • Incentive levels must be reasonably priced relative to market conditions. Resources such as Furthermore are recommended for understanding current market incentive rates.

​
Governance and compliance

​
Proposal requirements

​
Three-week maximum rollover policy

  • All unapproved applications will automatically roll over and remain in the review pipeline for up to three weeks.
  • After the three-week period, your team must comment under your forum post or submit a new application if you want the proposal reactivated and put up for consideration again.

​
BGT use clarity

  • When applying, be specific about exactly what BGT will be used for.

​
Deployment

  • Reward Vaults must be deployed at time of submission.
  • Any changes require a new proposal and vote.
To protect the system from value-extractive incentives, systemic risk, and abuse, the following measures may be exercised at any time:

​
Time-limited whitelisting

  • All whitelisted vaults are subject to periodic reevaluation and must continue to meet eligibility criteria to maintain active status.

​
Emergency veto

  • In the event of security vulnerabilities, critical protocol risks, or evidence of abuse, an emergency veto may be activated to suspend or revoke emissions immediately.

​
Post-approval disqualification

  • Any vault that no longer meets the required standards may be disqualified or have emissions removed, even after prior approval.
Teams at risk of being delisted will be directly contacted.

​
Submission deadlines

Proposals for each new batch must be submitted by Wednesday 11:59 PM EST every week. Proposals received after this deadline will be reviewed in the next batch.

​
References