RFRV Yeet BGT Auction

Reward Vaults
1

1. Proposer Details

  • Email: pemby@yeetit.xyz
  • Proposer’s project name: Yeet
  • Proposer’s X account (you will be required to make a post from the X account provided for verification purposes): https://x.com/eatsleepyeet
  • Best Telegram Handle for questions/fixes: @lps0x

The proposer should be affiliated with the protocol or at least one of the tokens in the contract.

For example if the contract is a $EXAMPLE / $BERA pool on XYZ DEX, the proposer should be affiliated with the protocol (XYZ DEX) or one of the tokens in the pool (in this case, $EXAMPLE).

  • Affiliation (protocol / one of the tokens in the contract): Yeet core team

2. Protocol Details

3. Contract/Pool Details

  • Contract Name: Yeet BGT Auction
  • Contract Address: 0xD7CFdd9514b6Ef10e9cF271CF62955530adbC4eC
  • Contract Type / Configuration: Custom contract
  • Describe how the contract works:
    • Description of game mechanics:
      • A dutch auction determines who secures a guaranteed timeslots of uninterrupted BGT flow
      • The proceeds of this auction are split amongst bribes, a prize pool, and a treasury fee
      • The ongoing bribes guarantee ongoing BGT flow
      • If a player is the most recent Yeeter for several consecutive slots, then they also win the prize pool
    • How the BGT is awarded to players
      • The contract dynamically mints and burns an ERC-20 and uses delegateStake to stake the tokens in the reward vault
      • The beneficial owners of these tokens are players in the Yeet v2 game
      • The current most recent Yeeter earns all the BGT flow from this RV in real time, with a minimum guaranteed timeslot
      • When the most recent Yeeter is updated, tokens are burned and new ones minted and delegateStake is called to make the new recent Yeeter the beneficiary of the BGT accrued by staking those tokens
      • The contract is also built such that multiple recent Yeeters can be beneficial owners of tokens in this RV
  • Contract Fees: None
  • Existing Liquidity / TVL: current liquidity and volume stats (if applicable): NA
  • Identify any address(es) controlling more than 10% of the contract shares: The contract shares technically be 100% owned by the contract itself, however the beneficial owners will be
  • Is the contract upgradable? Yes
  • Contract Control: Multisig
  • Additional details on Contract Control: Yeet core multisig
  • Is the contract verified? Yes.
  • Can the contract be paused? No
  • Does the contract rely on oracles? No.

4. Token Details

Provide the following details for each token in the contract (up to 5):

For Non-Major Tokens:

Token 1:

  • Name: Yeet
  • Symbol: YEET
  • Contract Addresses (on Berachain and bridging addresses if cross-chain): 0x08A38Caa631DE329FF2DAD1656CE789F31AF3142
  • Tokenomics, Distribution, and Vesting: Yeetonomics | Yeet Documentation
  • Identify any address(es) controlling more than 10%: Protocol treasury: 0x019D3FdD8E0D4C9ac229a298c6a1a6634A35F894
  • Does the project issuing the token have any relationship with current Berachain validators? Yes
  • If yes, which one? THJ, Kodiak, Smilee
  • Total Supply Cap (if any): 1B
  • Circulating Supply: 610m
  • Token Type: Utility
  • Provide extra details: Can be staked for revenue
  • Are token contracts upgradable? No
  • Token Control: Multisig
  • Additional details on Token Control: Yeet core team multisig, but no major controls in the token contract
  • Is the token contract verified? Yes
  • Is the token a standard ERC20 or any functions have been customized? (e.g. transfer, balance, mint, burn…): Standard
  • Can the token be paused? No

Token 2:

  • Name: Wrapped BERA
  • Symbol: wBERA

5. Token / Project Background / Incentive Token Whitelist

Indicate which tokens will be used and provide all relevant information below.

Required Data for Incentive Tokens:

  • Name: Wrapped BERA
  • Symbol: wBERA
  • Name YEET
  • Symbol: YEET

Additional Requirements:

  • Specify how many tokens you plan to allocate for incentives and over what period of time: 80% of Yeeting volume will be used as bribes
  • Outline how decisions about token incentives are made (DAO, multi-sig, etc.). Multi-sig
  • Incentive Manager address for YEET: 0xd1d6f74cd41b5a823d7d67526a3849b1936c2f76
  • Incentive manager address for wBERA: 0xd1d6f74cd41b5a823d7d67526a3849b1936c2f76

6. Growth, Community & Ecosystem Impact

Why This Contract Matters:

  • How will this contract benefit Berachain?
    • It enables a unique use case and novel protocol
    • It allows users to access BGT via a unique mechanism
    • It can bring new users to the chain, and will be accompanied by a social campaign run by Yeet to further incentivize usage of the protocol
  • Will it deepen liquidity for a major ecosystem token (e.g., BERA, core stable asset)?
    • NA
  • Does it enable important trading pairs that drive adoption or integrate with other Berachain projects?
    • No

Potential Volume / TVL:

  • Provide metrics or estimates on liquidity you expect to attract.
    • NA
  • Highlight any known liquidity commitments. (If you or partners plan to seed the contract, provide proof of funds or a statement of intent.)
    • NA

Synergies with Other Protocols:

  • Will this contract feed into any yield aggregators, lending markets, or liquid staking derivatives on Berachain?
    • It will enable Yeet v2 users to earn BGT, which they can claim as any LST they desire. This has clear synergy with LST protocols.

Marketing / Promotion:

  • Are there plans to co-market with another project to bootstrap liquidity?
    • Yeet will bootstrap this new product with bribes

Long-Term Vision:

  • How could this reward vault evolve over time? (E.g., eventually becoming a core liquidity pair or a major stable pool for the chain.)
    • This can become a core product in the ecosystem and a vehicle in which BGT flow can be auctioned. This vault enables all of it, by enabling the rewarding of the appropriate addresses with BGT following the dynamic minting and burning of beneficiary tokens

7. Verification

Please post the following text with the provided X account:

“Submitted Reward Vault Request for [Contract Name] on protocol [Protocol Name] with incentive tokens [incentive token 1], [incentive token 2]”

Insert post link: https://x.com/eatsleepyeet/status/1939675765181743426

2

Hi team, at the time of submission, the following concern was identified:

  • The incentive amount for this proposal is not defined with a clear base figure. It is currently described only as “80%,” but it is unclear what this percentage references. According to the guidelines, each vault must target incentives of at least $10,000 per month. The team should provide a monthly estimate of the expected volume to ensure the proposal meets this requirement.

Please note that the following feedback doesn’t represent the opinions of the BGT Foundation. It is contextual feedback from the Bera ecosystem team with respect to publicly stated guidelines.

With the following changes implemented, this application should be a better candidate for a Reward Vault.

3

Hello team, thanks for the feedback. Here is some further information:

  • This vault’s bribe volume will be 80% of gross Yeeting volume, and we are confident this figure will exceed 10k per month
  • to kickstart this flywheel, we commit to using RFA funds for the initial bribes to create BGT flow and guarantee more yeeting volume, and thus more bribe volume. We plan to use 5-10k for this first bribe alone.
  • If the bribing volume for this RV falls below 10k per month in any of the first 6 months after its launch, we commit to using treasury funds to supplement bribe amounts to meet this minimum requirement