# Overview
## What is Beefy?
Beefy is a Decentralized, Multichain Yield Optimizer that allows its users to earn compound interest on their crypto holdings. Beefy earns you the highest APYs with safety and efficiency in mind.
Through a set of investment strategies secured and enforced by smart contracts, Beefy automatically maximizes the user rewards from various liquidity pools (LPs), automated market making (AMM) projects, and other yield farming opportunities in the DeFi ecosystem.
The main product offered by Beefy are our [Vaults](/beefy-products/vaults). The investment [Strategies](/beefy-products/strategies) tied to the Vaults will automatically increase your deposited token by compounding arbitrary farm reward tokens from decentralized exchanges back into your initially deposited asset. Despite the inference of the name Vault, your funds are never locked in any contract on Beefy: you can always withdraw at any moment in time.
DeFi applications are unique in the sense that they are permissionless and trustless, meaning that anyone with a supported wallet can interact with them without the need for a trusted middleman. While you have funds staked in a vault, you remain 100% in control of your crypto.
## What is $BIFI?
The [$BIFI Token](/ecosystem/bifi-token) is the governance token of the [Beefy DAO](/dao/team-and-goals). It is the central asset which connects all stakeholders across the Beefy project, to perpetuate the virtuous cycle of value creation which Beefy was invented around.\
\
The token's utility is two-fold: first tokenholders are entitled to vote in important [Governance](/dao/governance) decisions for the DAO; and second a part of all revenue generated by vaults within the [Beefy Protocol](/ecosystem/protocol) are directed towards our tokenholder [Incentive Programmes](/ecosystem/protocol/incentive-programmes). Incentives are regularly paid out through the protocol's BIFI Pool and BIFI Vault, which require tokenholders to deposit their $BIFI tokens to participate.
The supply of $BIFI is limited to 80,000 tokens, with no capacity for mint or burn functions. As such, the Beefy DAO does not issue or trade in $BIFI tokens, and $BIFI may only be acquired through third-party exchanges, including Binance, Crypto.com and Uniswap.
# Get Started
How-To series to get started with DeFi and Beefy
Here we will aggregate a lot of information to help you get started with DeFi and Beefy. You will find links to various sources on how to set up a wallet, how to fund it, and how to connect your wallet to Beefy.
{% content-ref url="/pages/32W9qBezYxMCsYSuCKLe" %}
[How to set up a wallet](/get-started/how-to-set-up-a-wallet)
{% endcontent-ref %}
{% content-ref url="/pages/J1luloKHCkTEb97D9bFP" %}
[Funding your wallet](/get-started/funding-your-wallet)
{% endcontent-ref %}
{% content-ref url="/pages/N8aTR1Iit6A41ngxKBLL" %}
[Connecting your wallet to Beefy](/get-started/connecting-your-wallet-to-beefy)
{% endcontent-ref %}
Once you are ready to go, have a look at our other How-To Guides:
{% content-ref url="/pages/-MYopsjwDMFeyltPtPli" %}
[How-To Guides](/faq/how-to-guides)
{% endcontent-ref %}
# How to set up a wallet
In DeFi (Decentralized Finance), you are the true owner of your crypto. Your funds sit in a wallet that is controlled and managed by you. Before doing anything, it is important that you always follow these safety practices:
{% hint style="success" %}
* Never share your recovery phrases with anyone, under any circumstances.
* Never input your recovery phrase to a website or app, other than your wallet app when you are importing your wallet on a new device.
* Be wary of fake websites, giveaways, or other malicious acts.
* Download and install only the latest wallet version from official sources.
* Follow the setup guides of your wallet of preference carefully.
* Safely back up your recovery phrases, preferably somewhere offline.
{% endhint %}
## MetaMask
MetaMask is a very popular browser-based wallet plugin. It supports Ethereum by default, and every other Ethereum compatible blockchain, such as BNB Chain, Avalanche, and Polygon, can be added manually. MetaMask is also compatible with hardware wallets like Ledger and Trezor.
* [Download MetaMask](https://metamask.io/download.html)
* [MetaMask Frequently Asked Questions](https://metamask.io/faqs/)
* [MetaMask Setup Guide by Binance](https://academy.binance.com/en/articles/connecting-metamask-to-binance-smart-chain)
* [Step-by-step guide by Creatorbread](https://www.creatorbread.com/blog/how-to-set-up-a-metamask-wallet-step-by-step-guide)
## Trust Wallet
Trust Wallet is a popular mobile wallet. It is user-friendly as many blockchain networks are preconfigured and it has a build in DApp Browser. It is however not as configurable as MetaMask.
* [Download Trust Wallet](https://trustwallet.com/download)
* [Trust Wallet Community Setup Guide](https://community.trustwallet.com/t/how-to-create-a-multi-coin-wallet/41)
* [Trust Wallet Setup Guide by Binance](https://www.binance.com/en/blog/ecosystem/how-to-set-up-and-use-trust-wallet-for-bnb-smart-chain-421499824684901157)
## Rabby Wallet
Rabby is an open-source, non-custodial crypto wallet that supports multiple EVM & non-EVM chains. It is designed to be user-friendly and secure, and it offers a number of features, including a simplified UX and seamless multi-chain support making it a good choice for both beginners and experienced crypto users. It is generally supported where Metamask is used.
* [Download Rabby](https://rabby.io/)
* [A Brief Introduction To Rabby by Rugdoc](https://wiki.rugdoc.io/docs/introduction-to-rabby/)
* [Rabby Setup Guide](https://medium.com/@rabby_io/rabby-wallet-easy-onboarding-for-new-users-6fb1ab26ef40)
# Funding your wallet
Now you have created your wallet, it's time to fund it with crypto tokens. To make any transaction on a blockchain, such as a trade on a decentralized exchange or a deposit in Beefy's vaults, you need the native gas token to pay for it. For Ethereum, it's ETH, for BNB Chain, it's BNB, etc.
## Fiat On-Ramp
There are several providers that let you buy crypto directly to your wallet by using a bank transfer or credit card. On Beefy, various services allow you to do just that, bundled in one module for an easy overview that lets you pick the best option. You just need to click on the Buy Crypto button on the top of the page to start the Fiat On-Ramp process.
## Centralized Exchange method
Funding your wallet is relatively easy if you already have an account on a centralized exchange, such as Binance or Coinbase. In short, it comes down to withdrawing your crypto from the exchange to your wallet address. In the process, you choose the coin to withdraw and the blockchain network on which you wish to receive the crypto asset.
* [Binance Deposit and Withdrawing guide](https://www.binance.com/en/support/faq/85a1c394ac1d489fb0bfac0ef2fceafd)
* [Coinbase Send and Receive guide](https://help.coinbase.com/en/coinbase/trading-and-funding/cryptocurrency-trading-pairs/how-to-send-and-receive-cryptocurrency)
# Connecting your wallet to Beefy
Now that you have created a wallet and funded it with crypto, it’s time to connect your wallet to Beefy!
### 1. Click on the "Connect Wallet" buttton
The button can be found at the top of the page:
### 2. Select your wallet from the options
### 3. Approve the connection
All done! :cow: You are now ready to explore Beefy's vaults and other earnings opportunities.
{% content-ref url="/pages/-MKPlFREnjJBFAYJEzz4" %}
[How to deposit in a Vault](/faq/how-to-guides/how-to-deposit-in-a-vault)
{% endcontent-ref %}
# Introduction to Beefy
Last Update: August 2023
## What is Beefy?
Beefy is a Decentralized Finance (**DeFi**) Yield Optimizer project, that helps users to earn more of the cryptoassets that they love through the magic of autocompounding.
Open-source DeFi applications aim to be permissionless and trustless, meaning that anyone can interact directly without the need for a trusted middlemen. By keeping all code public and verifiable on the blockchain, anyone is able to verify how DeFi works and bypass the need to trust that a service is safe. Beefy leverages these characteristics to deliver hundreds of yield opportunities from across the ecosystem to users in a safe and decentralized manner, through one simple-yet-beautiful interface.
Through its battle-tested [vault](/beefy-products/vaults) and [strategy](/beefy-products/strategies) contracts, the Beefy Protocol maximizes the rewards available to users from liquidity pools (**LPs**), automated market makers (**AMMs**), and other yield farming opportunities. It does this by automatically claiming, swapping and redepositing rewards, unlocking exponential returns through **autocompounding**. By automating the process, Beefy saves time, increases efficiency and circumvents the user risks in manual yield farming, to offer a substantially better experience. In sharing gas fees and aggregating volume, Beefy's contracts are able to compound (or **harvest**) rewards far more frequently than users can, meaning much beefier yields. Overall, Beefy offers a huge advantage to users when compared with farming manually yourself. It's a simple win-win formula.
The Beefy Protocol is governed by its decentralized autonomous organisation (the **Beefy DAO**). The DAO is constituted by hundreds of community members from all across the world, who have a shared appreciation for the magic of autocompounding and a passion for the Beefy project. The DAO is operated using our [$BIFI governance token,](/ecosystem/bifi-token) which is used for voting on governance proposals.
## Beefy's History
Beefy was born in September 2020, when a team of 4 founders came together to bring the power of autocompounding technology from DeFi projects on Ethereum over to lower costs chains. The first set of vaults went live on 8 October 2020 on BNB Chain, making Beefy the first yield optimizer on the chain.
In less than a year, Beefy was managing over $800 million of total value locked, and had reached a $100 million market capitalisation. Many new contributors and community members arrived, and gradually the founding team stepped back as a new generation of core contributors took over the reigns. By the end of 2022, Beefy was live on 10 different blockchains. A year later, it was 18.
By 2023, Beefy is widely known as one of the OG cross-chain DeFi protocols, with a reputation for indiscriminately building on top of hundreds of protocols. Beefy's contributor team are professionals at scoping out new opportunities, carrying out proper due diligence, and safely and quickly deploying onto the newest and hottest chains and protocols.
## What Makes Beefy Unique?
Beefy differs from other DeFi yield optimizers and aggregators in a few key ways:
1. Beefy's vaults are primarily "single strategy", meaning optimizing just one yield farming opportunity, rather than diluting yield across multiple opportunities;
2. Safety is Beefy's number one priority. All of our products are run through rigorous safety standards through our [SAFU Standards](/safety/beefy-safu-practices);
3. Beefy prides itself on indiscriminately, quickly and flexibly deploying on top of an enormous range of protocols and blockchains;
4. The Beefy Protocol directly distributes platform revenue back to users who stake $BIFI in our governance pools;
5. Beefy offers unique strategies that can't be found elsewhere, and is often the first to market with new and exciting yield farming opportunities; and
6. Beefy maintains an enormous network of recognized partners, and has a stellar reputation in the community for its safety and professionalism.
## Autocompounding On Other Chains
Beefy was created with the aim of disseminating the potential of automated yield farming to different blockchains, in order to take advantage of higher transaction speeds and lower gas costs than can be found on Ethereum.
Autocompounding on alternative chains presents a different set of opportunities and challenges: where on Ethereum the timing of events is vital to ensuring profitability, other chains the frequency of low-cost compounding has an enormous impact on the yield. Likewise, low-cost chains encourage farmers to move between different opportunities to maintain high average APY across their portfolio, where moves on chains like Ethereum are expensive and must be carefully considered. This opens the door to more sophisticated and complex strategies on other chains.
Because Beefy's vault offer a fully decentralized and automated solution, they allow users to all sizes and persuasions to access the benefits of DeFi with minimal effort.. We see this as a vital step in levelling the financial playing field, allowing small users to have access to the same opportunities that only the wealthy, professionals and businesses could access elsewhere.
Beefy's goal is to help projects in DeFi grow together, and to spread the potential of decentralized financial technologies across the world. By pursuing this with a complete open-source mentality, a firm commitment to decentralization, and by placing governance openly in the hands of tokenholders, we hope to deliver an unbeatable experience for accessing yield in DeFi.
# Beefy Protocol
Last Update: November 2023
Beefy is first and foremost an autonomous, decentralized yield optimization protocol. Though the wider project and DAO which surround the protocol are central to Beefy's operations and identity, in fact the protocol functions entirely independently of any such individuals, and will continue to do so on blockchain in perpetuity, even after all other stakeholders are left (even if very, very broken at that stage).
This page provides a short summary of the protocol, designed to onboard novice users as to how the protocol will put their inputs to use. The detail on this page is simplified, and is generally non-technical in nature.
## What do we mean by the "protocol"?
As described above, the core of Beefy's protocol is its collection of live [Vaults](/beefy-products/vaults) and associated smart contracts on the blockchain. Beefy's contracts accept user deposits, put funds to work in automated yield farming processes, and then pay out fees to the various on-chain stakeholders in the process. As the smart contracts exist independently of the rest of the project, the protocol operates autonomously, even if all of the supporting stakeholders stopped maintaining them.
A simplified map of the contextual layers of the Beefy protocol.
However, in order for the smart contracts at the heart of the protocol to be maintained and remain accessible to ordinary users, additional services are required. These services typically require ongoing human intervention to deliver and maintain them, and so are typically performed by Beefy's contributor team. These include:
* maintenance of existing smart contracts, such as pausing vulnerable or malfunctioning contracts, or performing live changes or upgrades to facilitate to improve performance;
* development and deployment of new contracts, both to replace and supplement the existing protocol;
* provision of a functional web application or user interface, which assists users in accessing the smart contracts and seeing live information about their functioning (e.g. rates of return);
* maintenance of live servers and databases to store and distribute necessary and relevant data about all other aspects of the protocol, including services like application programming interfaces (**APIs**); and
* operation of automated contract interactions, such as bots to watch for and trigger profitable compounding events in Beefy's vaults.
Though the protocol may continue to operate without any one of the above services for a certain period of time, all of these services are required to keep the smart contracts of the Beefy protocol safe, operational, accessible and comprehensible.
Beyond these internal services, external services often build on top of Beefy's protocol to deliver access to its products to users elsewhere. This can include other smart contracts (which deposit funds or act as on-chain stakeholders in the protocol), other web applications (which may point users direcly to Beefy's smart contracts) and other information services (e.g. user dashboards, or comparison sites like DefiLlama). By virtuing of being external to Beefy, all of these services are not considered to be a part of Beefy's protocol.
## How does the protocol work?
The overarching process and flow of the Beefy protocol is as follows:
A simplified flowchart mapping out the Beefy protocol.
The protocol involves the transmission of funds through various wallets and smart contracts to deliver on its two core functions:
1. To perform automated yield farming, and to optimize the yield received by users from that process, such that they earn more with Beefy than they would elsewhere or doing the same process themselves (left side); and
2. To reward and incentivize the on-chain stakeholders in the protocol for supporting and facilitating its ongoing operations (right side).
Each of these are described below in [#how-does-the-yield-farming-function-work](#how-does-the-yield-farming-function-work "mention") and [#how-does-the-stakeholder-incentives-function-work](#how-does-the-stakeholder-incentives-function-work "mention").
As described in [#what-is-included-in-the-protocol](#what-is-included-in-the-protocol "mention"), the protocol can be thought of simply as just the smart contracts which exist on the blockchain to perform yield optimization. These are reflected in the middle row of the above flowchart, and incorporate our Beefy Vault products (comprised of [Vaults](/beefy-products/vaults) and [Strategies](/beefy-products/strategies)), the [Revenue Bridge](/ecosystem/protocol/revenue-bridge) contracts, the [Fee Batch](/ecosystem/protocol/fee-batch) contract, and ultimately our [Incentive Programmes](/ecosystem/protocol/incentive-programmes) and [Treasury](/dao/treasury).
However, in order for each of these contracts to function, the protocol is built on top of other external contracts which facilitate the farming process. These contracts are reflected in the bottom row of the above flowchart. If all of the underlying liquidity pools and farms which Beefy is built on were withdrawn and not replaced, Beefy's contracts would still exist, but no real yield or fees would be being generated.
## How does the yield farming function work?
A summary of the core yield farming process in provided in the [Strategies](/beefy-products/strategies) page (see [Strategies](/beefy-products/strategies#how-do-liquidity-pool-strategies-work)), so is not repeated here.
The yield farming process is shown in the left side of the flowchart above. It revolves around the user's deposit, and the generation of on-chain yield through farming with that deposit and swapping farm rewards back to the principal asset.
Each time the yield farming process compounds the rewards, a small fee is charged on the rewards earned, as detailed in [Beefy Fees Breakdown](/ecosystem/beefy-bulletins/beefy-finance-fees-breakdown). The strategy pays out that fee in the chain's native token directly to the harvest caller (i.e. the wallet which calls the [Strategy Contract](/developer-documentation/strategy-contract#harvest) function), the strategist (i.e. the user who deployed the Beefy Vault), and the [Revenue Bridge](/ecosystem/protocol/revenue-bridge) contracts to facilitate the distribution of stakeholder incentives.
## How does the stakeholder incentives function work?
The stakeholder incentives function aims to facilitate and incentivize the development and maintenance of the protocol and wider project, including both technical and non-technical contributions.
As mentioned above, the [Strategies](/beefy-products/strategies) themselves distribute incentives to strategists and harvest callers, which sit outside of the remit of the DAO. Otherwise, once fees are received by the [Revenue Bridge](/ecosystem/protocol/revenue-bridge) on each chain, the protocol then works to bridge those fees back to the Ethereum [Fee Batch](/ecosystem/protocol/fee-batch), and distribute them to the DAO both by way of the [Incentive Programmes](/ecosystem/protocol/incentive-programmes) and the [Treasury](/dao/treasury).
Once the Revenue Bridge holds a viable amount of tokens, it performs a few functions to allocate and prepare them for bridging. The bridge itself contains multiple different bridging services, and will use the preferred method which has been specified to the contract. The bridge can either bridge directly to Ethereum, or back via any number of intermediate chains.
On Ethereum, the fees arrive to the Fee Batch, which aggregates all of the protocol's fees. Once a sufficient amount of tokens are batched token, the Fee Batch distributes them both to Treasury and - after swapping back to native $ETH - to the Governance Pools.
The governance pools holds $BIFI deposits on behalf of tokenholders, and pays out protocol fees as incentives to the tokenholder for participating in Beefy's [Governance](/dao/governance), in proportion with their $BIFI holding. The default position is that incentives are paid out in $ETH, though the BIFI Maxi Vault was designed and implemented to automatically swap those funds into more $BIFI tokens, in order to facilitate an autocompounding effect for the user.
## Who are the stakeholders in the protocol?
The protocol identifies and engages with the following selection of stakeholders, whose interests and needs must be continually balanced:
* **Users** - users are the primary beneficiaries of the protocol, because they enjoy and benefit from its services. The protocol primarily aims to cater to users by building and maintaining products that they like, though can also incentivize them through fee adjustments and peripheral incentives, such as [Boost](/beefy-products/boost) programmes;
* **Tokenholders** - tokenholders are the secondary beneficiaries of the protocol, who control the Beefy DAO and its assets and operations, and therefore have rights over the fees generated by the protocol. The protocol primarily rewards tokenholders through incentives in the [Incentive Programmes](/ecosystem/protocol/incentive-programmes), though they may also benefit from specific uses of the [Treasury](/dao/treasury);
* **Contributors** - contributors are the final core group of beneficiaries of the protocol, who enjoy the benefit of interesting and profitable work. Contributors primarily benefit through experience and remuneration, and are generally subject to the whims of the DAO and the resources of the Treasury.
From experience, these different categories of stakeholders frequently crossover, as regular users become token holders or contributors, and vice versa. Altogether, the different groups of stakeholders reflect the Beefy community at large.
It is also worth considering that there are many external parties that assume some form of stake in the Beefy project, though with less of a direct connection. For instance, the exchanges which Beefy builds on top of frequently receive increased liquidity from Beefy's user base, meaning the exchange's relationships with users and Beefy become intertwined. Similarly, many of the chains Beefy launches on come to rely on and appreciate Beefy as a core player in their ecosystem. Finally, many of our commercial partners for things like infrastructure see Beefy as a key demonstration of their own products' virtues, and are therefore interested in ensuring it suceeds.
## What is the distinction with Beefy DAO?
Beefy DAO is the organisational form of Beefy, which encompasses our contributors, members and (to a lesser degree) community. Much as the protocol would survive without the DAO, the DAO exists independently of the protocol, and has its own shared cultures, practices, assets and activities.
Though the DAO has primary responsibility for maintaining the protocol, users should be careful to delineate between what's in the control of the DAO and what's purely the domain of the protocol. For instance, where users choose to interact with immutable and independent smart contracts in the Beefy protocol, and incidentally send funds to that contract which are then lost, it is often the case that the DAO has no power or right to recover those funds. As such, caution is advised when dealing with the protocol, and all users are generally advised to use [the Beefy frontend web application](https://app.beefy.com/) to manage such interactions.
# Revenue Bridge
Last Update: November 2023
The Beefy Revenue Bridge is one of a few core components in the wider [Beefy Protocol](/ecosystem/protocol) which help to distribute vault fees from each of our deployed chains back to our Ethereum [Incentive Programmes](/ecosystem/protocol/incentive-programmes) and [Treasury](/dao/treasury). In doing so, the Revenue Bridge acts in one direction, to move earnings away from deployed chains and back to Beefy's native Ethereum. Its core purpose is to facilitate the transfer of assets across blockchains.
## What does the Revenue Bridge do?
As described above, the Revenue Bridge's main purpose is to facilitate the transfer of assets between blockchains in a profitable manner. Within this, it has five key functions:
* **Fee Batch** - the Revenue Bridge receives all of the fees from each strategy on the relevant chain, and gathers them together into batches to share the handling costs throughout the distribution process;
* **Wrap Native** - the Revenue Bridge wraps any native chain tokens it receives to ensure they are ERC-20 compliant, allowing them to be manipulated more easily by protocol contracts;
* **Top Up Cowllector** - the Revenue Bridge also now assumes the roles of keeping the Beefy Cowllector fed with gas. Before any fees are bridged, the Revenue Bridge first tops up the Cowllector's balance to the configured minimum level;
* **Swap to Specified Token** - the Revenue Bridge also contains functionality to specify a preferred token for bridging - typically a common stablecoin like USDC or USDT. The bridge swaps the native token received as fees into this token ready for bridging; and
* **Bridge Fees** - the Revenue Bridge finally transfers the accumulated fees in the required token to its preferred bridging or messaging solution, to bridge those funds to the specified chain. The bridge contract includes several hardcoded bridging and messaging solutions.
## How does the Revenue Bridge work?
The *BeefyRevenueBridge.sol* smart contract handles each of the functions described above. The core workflow of the Revenue Bridge is its *harvest()* function, which first wraps any native tokens held by the contract, then checks whether it can top up the Cowllector, before finally bridging the tokens.
The Revenue Bridge also contains permissioned functions that allow Beefy's Core team to configure workflow, including changing the preferred bridging or messaging solution for the transfer, changing the stablecoin used for bridging, changing the swap pool and changing the destination chain and address.
Though the Revenue Bridge has a number of different bridging solutions hardcoded at launch, the world of cross-chain bridging and messaging is still an experimental one, where critical changes can be needed on short notice. As such, the Revenue Bridge is deployed as a proxy contract, allowing critical upgrades to be implemented by Beefy's Development Council (through it's multi-signature wallet), should the need arise.
The Revenue Bridges are also designed to incorporate the permit pattern established by [EIP-2612](https://eips.ethereum.org/EIPS/eip-2612), which allows for gasless permit approvals by way of signatures. This means that users can approve transactions with the bridge without paying gas. More specifically, the contracts inherit this functionality by way of OpenZeppelin's [ERC20Permit.sol](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/extensions/ERC20Permit.sol) abstract contract.
## What bridging method(s) does the Revenue Bridge use?
The Revenue Bridge is designed to serve as flexible and resilient on-chain infrastructure, which can adapt to use different services in response to current market conditions over time. On launch, the Revenue Bridge supports the following bridging and messaging services:
* LayerZero's [omnichain interopability protocol](https://layerzero.gitbook.io/docs/) (message passing);
* Axelar's [cross-chain gateway protocol](https://docs.axelar.dev/) (message passing);
* Circle's [cross-chain transfer protocol](https://developers.circle.com/stablecoin/docs/cctp-getting-started) (message passing);
* Interopability's [Synapse bridge](https://docs.synapseprotocol.com/protocol/synapse-bridge) (message passing);
* Polygon's [zkEVM bridge](https://wiki.polygon.technology/docs/category/zkevm-bridge/) (canonical bridge); and
* Matter Lab's [zkSync Era bridge](https://era.zksync.io/docs/reference/concepts/bridging-asset.html) (canonical bridge).
## What happens on the source chains?
As detailed in [#what-does-the-revenue-bridge-do](#what-does-the-revenue-bridge-do "mention"), the Revenue Bridge has several core functions, which it applies to fees transferred by strategies on each chain.
Flowchart showing the movement of fees through a typical Revenue Bridge, and one of numerous bridging/messaging solutions.
As detailed in the flowchart above, once fees are received they are first used to top up the Beefy Cowllector, to support harvesting operations on the chain. Afterwards, they are swapped to the relevant stablecoin to prepare for bridging.
At the point of bridging, the Revenue Bridge sends to just the one live bridging solution assigned in the contract. The other bridging functionality remains hardcoded, and Beefy's Development Council have the power to switch the assigned solution at any time. Depending on the chain and the asset, the bridge takes one of a number of possible routes back to Ethereum.
## What happens between chains?
As revenue flows back to Ethereum, the protocol distinguishes between three tiers of chain:
* **Home Chain** - Ethereum is the ultimate destination for all vault fees earned by the protocol;
* **Hub Chains** - chains which send fees directly to Ethereum, and aggregate fees from other chains; and
* **Spoke Chains** - which do not receive fees from other chains, and typically send all fees on to hub chains.
Flowchart showing the movement of fees from spoke chains to hub chains and onward to Ethereum for distribution
Through its use of hub chains, the Revenue Bridge can aggregate larger volumes of fees from several chains, and minimize the number of costly bridge transactions into Ethereum. Arbitrum is the current default hub chain for efficient batching of fees and bridging to Ethereum.
At the time of writing, there are two exceptions to using Arbitrum as a hub: both Polygon zkEVM and zkSync have canonical bridges which immediately and securely settle to Etherum, meaning this is the most secure method of bridging fees from these chains. Others may follow this model in the future, though the default position remains that batching on the core hub chain is the most efficient means of bridging fees to Ethereum.
In some cases, the token being received in the hub may not be the optimal token to return to Ethereum. For example, with fees denominated in $USDCe (i.e. non-native $USDC on Arbitrum), the protocol will tend to deliver these fees to a swapper contract to first swap back to native $USDC before delivering the fees to the bridge contract. Likewise, Axelar-bridged tokens (e.g. $axlUSDC) are sent to Polygon PoS for transfer to their native form, before being transferred on to Arbitrum.
## What happens on Ethereum?
Once the fees from the hub chains reach Ethereum, they are sent directly to Ethereum's [Fee Batch](/ecosystem/protocol/fee-batch) contract for onward distribution to the [Incentive Programmes](/ecosystem/protocol/incentive-programmes) and the [Treasury](/dao/treasury).
# Fee Batch
Last Update: November 2023
The Beefy Fee Batch is another core component of the [Beefy Protocol](/ecosystem/protocol) which distributes vault fees to our Ethereum [Incentive Programmes](/ecosystem/protocol/incentive-programmes) and [Treasury](/dao/treasury). As with the [Revenue Bridge](/ecosystem/protocol/revenue-bridge) which delivers fees to the Fee Batch, the Fee Batch acts in one direct only, helping to move earnings from vaults to the Beefy DAO and its tokenholders.
## What does the Fee Batch do?
Beefy's Fee Batch contracts were designed and implemented to improve gas efficiency across the protocol in its management of vault fees. Forwarding fees immediately in small values may increase the speed of Beefy's cashflow, but in practice also depletes that cashflow with a corresponding increase in gas costs.
When preparing to send out fees, the Fee Batch's outflow transaction is a multicall, which sends $WETH to the [Incentive Programmes](/ecosystem/protocol/incentive-programmes) and to a router liquidity pool, to swap for a stablecoin (e.g. $USDC), which is sent onwards to the [Treasury](/dao/treasury). The breakdown of fees into these categories reflects the [Beefy Fees Breakdown](/ecosystem/beefy-bulletins/beefy-finance-fees-breakdown).
Following the migration of the [$BIFI Token](/ecosystem/bifi-token) to Ethereum in 2023, the protocol relied on Fee Batch contracts on each chain to aggregate fees from that chain's strategies, before transferring into the treasury and governance pools on that chain. See [here](https://optimistic.etherscan.io/address/0x2bbf9cfbda4293fa446e915aa12adc52ea8d5d53#code) for an example Fee Batch contract on Optimism, which often handled around 500 inflows and 2 outflows of $WETH per day, and [here](https://optimistic.etherscan.io/tx/0x8c8a31d0ff4e66fe55d5e55e2670ccf8015614cdd5bc78bd51ced42845bb6587) for an example outflow transaction.
Post-migration, most chains now use their [Revenue Bridge](/ecosystem/protocol/revenue-bridge) contracts to batch fees before bridging, as explained in [Revenue Bridge](/ecosystem/protocol/revenue-bridge#what-does-the-revenue-bridge-do). The obvious exception to this is Ethereum.
## Ethereum Fee Batch
Post-migration, the Ethereum Fee Batch contract has taken on the role of batching **all** revenue from the protocol's vaults after the [Revenue Bridge](/ecosystem/protocol/revenue-bridge) has returned the funds to Ethereum. This covers inflows from all of the hub chains across different bridges and assets.
Once received by the fee batch, and a sufficient amount has accumulated, the fees are split as previously between the [Incentive Programmes](/ecosystem/protocol/incentive-programmes) and the [Treasury](/dao/treasury), in accordance with the allocation detailed in the [Beefy Fees Breakdown](/ecosystem/beefy-bulletins/beefy-finance-fees-breakdown). Unlike under the previous fee batch, as the fees are received in stablecoins, the Treasury inflows do not need to be swapped, but incentives for the Governance Pools must first be swapped back to $WETH.
# Incentive Programmes
Last Update: November 2023
The final core component of the [Beefy Protocol](/ecosystem/protocol) which is needed to distribute vault fees from our various chains is our incentive programmes, which are used to reward and incentivize [$BIFI Token](/ecosystem/bifi-token) holders for their participation in the Beefy project.
## What are incentive programmes?
Beefy's incentive programmes are the smart contracts which facilitate the protocol's distribution of governance incentives. Where we refer to "incentive programmes", we mean collectively:
* **The BIFI Pool** - which pays out governance incentives to tokenholders in the form of $WETH; and
* **The BIFI Vault** - which autocompounds the governance incentives for tokenholders into more $BIFI tokens.
Each are contracts which exist solely for the purpose of safely holding the [$BIFI Token](/ecosystem/bifi-token) on behalf of tokenholders and gradually distributing the value accruing from vault fees using the preferred method of the holder (either native rewards or autocompounding $BIFI).
## Why pay out incentives?
Since Beefy's inception, the [Beefy Protocol](/ecosystem/protocol) has always envisaged incentivising community members to take an interest in the project and act as a stakeholder in its operations. Though a standard governance token model permits tokenholders to interact with the project through the governance process, in practice this rarely aligns the incentives of each side, leading to conflicts and ineffective decisions.
Likewise, leaving control of a project's governance to wholly distributed tokens that are out there in the ether can lead to disruptive behaviours and negative externalities. For instance, where users seek to borrow using their governance tokens as collateral, their debt's health (or lack of) can have significant impacts on the governance of the project, as cascading liquidations damage pricing and cause panic. In the reverse, freely available tokens present an opportunity for a parasitic takeover of the project, such as how Convex was able to gain control over Curve.
Beefy's solution is to incentivize tokenholders to deposit their tokens with Beefy itself, leaving them with no functional uses beyond participation in governance. By having protocol smart contracts custody the tokens, and tokenholders receive regular and tangible reward, Beefy mitigates the desire to look elsewhere, and maximizes concentration on the project and protocol. Similarly, by tying the amount of rewards payable to the amount of revenue earned (which is itself a function of the project's efficacy in deploying vaults, managing harvests and locking value), the system achieves a close align of incentives across all of the project's core stakeholders.
## How do incentives programmes work?
As described in previous [Beefy Protocol](/ecosystem/protocol) pages, fees generated by our [Vaults](/beefy-products/vaults) flow from the [Strategies](/beefy-products/strategies), through each chain's [Revenue Bridge](/ecosystem/protocol/revenue-bridge), back to the [Fee Batch](/ecosystem/protocol/fee-batch) before reaching the incentive programmes and [Treasury](/dao/treasury). This is shown in the below diagram:
A simplified flowchart mapping out the Beefy protocol.
Prior to the $BIFI token migration in 2023, fees flowed into the Fee Batch contract as native tokens, which were deposited directly into the Reward Pool. Now, fees flow into the Fee Batch as stables, meaning they must be swapped for native before reaching the Reward Pool. Once the native tokens arrive in the BIFI Pool, they vest as incentives and become claimable for tokenholders in a linear fashion. Tokenholder claims must pay the gas required to transfer the incentives to them.
The BIFI Vault sits on top of the BIFI Pool, actually depositing all of the $BIFI tokens into the BIFI Pool. Beyond that, the vault regularly and automatically claims the native incentives from the BIFI Pool, routes them through a liquidity pool to swap for $BIFI, and then redeposits the $BIFI in the BIFI Pool, to unlock the autocompounding effect.
# $BIFI Token
Last Update: November 2023
The $BIFI token is the governance token of the Beefy project. It unites the [Beefy Protocol](/ecosystem/protocol) - which pays out to tokenholders through [Incentive Programmes](/ecosystem/protocol/incentive-programmes) - with the Beefy DAO - which conducts the [Governance](/dao/governance) of the project.
## **What is $BIFI?**
The Beefy token (symbol: BIFI) is an ERC-20 smart contract which records the holdings of $BIFI tokens among our community of tokenholders. The purpose of $BIFI itself revolves are two core use cases:
* **Project Governance** - holders of $BIFI can vote in the [Beefy Snapshot Space](https://vote.beefy.finance/#/) on all of our governance matters, at a rate of 1 vote per token (including fractional amounts); and
* **Stakeholder Incentivization** - through holding the $BIFI token, the project can incentivize the participation by stakeholders in the project and protocol with governance incentives paid through our [Incentive Programmes](/ecosystem/protocol/incentive-programmes).
Other external use cases for Beefy have emerged over time, including offering liquidity for trading in $BIFI and using $BIFI as collateral for loans. However, within the Beefy project, the token is purely intended to facilitate and encourage governance of the project.
## How does $BIFI work?
The ERC-20 smart contract for the $BIFI token itself is extremely short and simple:
{% code overflow="wrap" %}
```solidity
// SPDX-License-Identifier: MIT
pragma solidity 0.8.19;
import {ERC20PermitUpgradeable} from "@openzeppelin/contracts-upgradeable/token/ERC20/extensions/ERC20PermitUpgradeable.sol";
import {ERC20Upgradeable} from "@openzeppelin/contracts-upgradeable/token/ERC20/ERC20Upgradeable.sol";
contract BIFI is ERC20Upgradeable, ERC20PermitUpgradeable {
function initialize(address _treasury) external initializer {
__ERC20_init("Beefy", "BIFI");
__ERC20Permit_init("Beefy");
_mint(_treasury, 80_000 ether);
}
}
```
{% endcode %}
The new $BIFI token - launched after the migration in 2023 - builds upon the [original $BIFI token](https://bscscan.com/token/0xCa3F508B8e4Dd382eE878A314789373D80A5190A#code) in a few core ways:
* It removes any minting functionality or permissions, and mints all the token supply there will ever be immediately on initialization;
* It moves to an upgradeable standard, which means you deal with a contract instance but not the underlying logic of the contract; and
* It adopts the permit pattern established by [EIP-2612](https://eips.ethereum.org/EIPS/eip-2612), which allows for gasless permit approvals by way of signatures. This means that users can approve transactions with the bridge without paying gas.
The initial 80,000 $BIFI supply is all minted to the Beefy treasury, for distribution to existing holders as part of the migration.
## How do I verify that $BIFI is safe?
As a [verified open-source contract](https://etherscan.io/address/0xb1f1ee126e9c96231cc3d3fad7c08b4cf873b1f1) on the Ethereum blockchain, anyone can review the code of the new $BIFI smart contract and its operations through the block explorer.
With that said, we are conscious that not all users will feel comfortable verifying the safety of contracts themselves. As such, we've had the token contract audited, and you can view the full audit report [here](https://github.com/beefyfinance/beefy-audits/blob/master/2023-08-30-Beefy-Zellic-BIFI-Token-Audit.pdf).
## What are the tokenomics of $BIFI?
Beefy prides itself on having some of the simplest tokenomics in all of Web 3.0:
* There are 80,000 $BIFI tokens, as determined on deployment of the token contract;
* The contract provides no further ability to mint and no officially burn functionality;
* All tokens were fully distributed as of July 2022, though the Beefy [Treasury](/dao/treasury) does hold $BIFI for various purposes (e.g. protocol-owned liquidity, redemptions of $BIFI which could not be migrated, etc); and
* There are no plans or obvious means to change the token's functionality or add additional tokens to our governance system.
No frills. No gimmicks. What you see is what you get.
## What is the history of the $BIFI token?
The $BIFI token was launched together with the project and the [Beefy Protocol](/ecosystem/protocol) back in September 2020. After an initial distribution period of around two months back in Q4 2020, 72,000 tokens were supplied to the community with 8,000 being locked for the founding team. All 80,000 BIFI were officially in circulation as of July 2022. The distribution via the "governance pools" and detailed info about the timelocks are found [here](https://github.com/beefyfinance/beefy-gov).
The $BIFI token migration was approved
In July 2023, issues with the Multichain project - Beefy's bridging provider who had issued the $BIFI token on all non-native chains - caused critical failures with the Multichain bridge. Shortly after this, the decision was taken to seek to migrate the $BIFI token away from Multichain, to protect user funds. A more detailed account of the events leading up to the Migration is provided [here](https://beefy.com/articles/bifi-migration/).
Through \[BIP:71] - the $BIFI Migration Plan - Beefy's core team sought approval for a comprehensive plan involving moving the token's base to Ethereum, restructure the [Incentive Programmes](/ecosystem/protocol/incentive-programmes) and building a new [Revenue Bridge](/ecosystem/protocol/revenue-bridge) and [Token Bridge](/ecosystem/bifi-token/token-bridge). After several months of work to prepare for the change over, the migration was implemented in September 2023.
### What is $mooBIFI
$mooBIFI is the name of the vault token for the [BIFI Vault](https://app.beefy.com/vault/bifi-vault). The BIFI Vault is the output contract of our incentives programmes which gives out incentives to tokenholders in the form of $BIFI tokens. Revenue from all vaults on every chain flow to Ethereum and into the BIFI Vault for distribution as incentives. Incentives are autocompounded linearly based on the quantity of $BIFI tokens deposited into the pool. All incentives are automatically swapped into $BIFI and redeposited, resulting in a higher APY of incentives when compared to the BIFI Pool. The amount of $mooBIFI tokens issued on deposit reflects the user's share of the $BIFI in the vault, so 1 $mooBIFI token will equate to more than 1 $BIFI token.
### What is $rBIFI
$rBIFI is the name of the vault token for the [BIFI Pool](https://app.beefy.com/vault/bifi-pool). The BIFI Pool is the output contract of our incentives programmes which gives out incentives to tokenholders in the form of $ETH tokens. Revenue from all vaults on every chain flow to Ethereum and into the BIFI Pool for distribution as incentives. Incentives are paid out linearly based on the quantity of $BIFI tokens deposited into the pool. Users must manually claim their $ETH incentives to use them. The amount of $rBIFI issued on deposit reflects the amount of $BIFI tokens deposited.
### Where can I find the details of the $BIFI token?
The new $BIFI token, and its derivatives staked in Beefy's incentives programme, can be found on the relevant block explorers at the following links:
* [$BIFI on Ethereum](https://etherscan.io/address/0xB1F1ee126e9c96231Cc3d3fAD7C08b4cf873b1f1);
* [$rBIFI on Ethereum](https://etherscan.io/address/0xb1F131437e314614313aAb3a3016FA05c1b0e087);
* [$mooBIFI on Ethereum](https://etherscan.io/address/0xBEEF8e0982874e0292E6C5751C5A4092b3e1BEEF); and
* [$mooBIFI on Optimism](https://optimistic.etherscan.io/address/0xc55E93C62874D8100dBd2DfE307EDc1036ad5434).
The contract addresses on the relevant chains are as follows:
* $BIFI on Ethereum: 0xB1F1ee126e9c96231Cc3d3fAD7C08b4cf873b1f1;
* $rBIFI on Ethereum: 0xb1F131437e314614313aAb3a3016FA05c1b0e087;
* $mooBIFI on Ethereum: 0xBEEF8e0982874e0292E6C5751C5A4092b3e1BEEF; and
* $mooBIFI on Optimism: 0xc55E93C62874D8100dBd2DfE307EDc1036ad5434.
# Token Bridge
Last Update: November 2023
The Beefy Token Bridge refers to the bridge built by Beefy to handle our $BIFI token's implementation across various different chains. To ensure that the Beefy DAO retains foremost control over how the $BIFI token dispersed, the Token Bridge and all of its contracts have been built by Beefy and remain within its control, relying on bridging and messaging services only handle the exchange across chains.
## What can I bridge with the Token Bridge?
On launch, the Token Bridge serves only to bridge the staked $mooBIFI token.
The Token Bridge is designed to enable holders on different blockchains to gain exposure to $BIFI on their preferred chain, without the need to handle the token itself on Ethereum - which is an expensive exercise due to the high gas fees.
The previous bridge (prior to the $BIFI token migration in 2023) enabled copies of $BIFI on every chain that the project launched on, enabling users to select which chain's [Incentive Programmes](/ecosystem/protocol/incentive-programmes) they wanted to stake their $BIFI on, to take advantage of the fees on that chain and the consequential level of governance incentives.
However, after the migration, the reorganisation of Governance Pools to live only on Ethereum means there is no need to have $BIFI on every chain. It also unlocks the possibility of bridging the staked version of $BIFI - $mooBIFI - to allow bridged copies of the $BIFI token to still benefit from the governance incentives being paid out on Ethereum.
Though it is also possible to facilitate bridging of naked $BIFI, it was felt bridging naked $BIFI with no option to stake for governance incentives on the bridged chain would make this a second-class form of $BIFI. As a yield-bearing asset, $mooBIFI was felt to be a more attractive choice, which can level the playing field with users for whom Ethereum is simply too expensive to operate on.
## How does the Token Bridge work?
The process of on-chain bridging is set out in the flowchart below. This shows how native $mooBIFI on Ethereum is originally bridged out to other chains, using Optimism as an example.
A simplified flowchart mapping out the process of bridging through the Token Bridge.
The user interacts with the Token Bridge through the Beefy Web Application to transfer their ERC-20 $mooBIFI tokens to their preferred Token Bridge contract. Each of the contracts then itself transfers the ERC-20 to a single separate "lockbox" contract, to demonstrate that the underlying asset is being safely held on the base chain. Once locked, a message is sent back to the xERC-20 contact for the bridge, which mints an ERC-20 duplicate of the locked token, called an "xERC-20 token".
With the xERC-20 $mooBIFI copy in place on the base chain, the Token Bridge can then engage with the external bridging/messaging provider to initiate the bridging process, and burn the xERC-20 to validate the request. The provider then facilitates the bridging or messaging needed to reach the target chain's Token Bridge contract. On receipt of the valid request, the Token Bridge then mints an xERC-20 $mooBIFI to the user on the source chain.
For bridging back to Ethereum, the process is reversed. On the source chain, the xERC-20 copy is burned to validate the Token Bridge's bridge transaction with the external provider. On receipt of that message, the xERC-20 contract mints an equivalent copy, which is used to demonstrate the transaction to the lockbox. The xERC-20 is then burned to release the underlying ERC-20, which is transferred back to the user on Ethereum.
Between bridged chains, the process is simply that the xERC-20 on the source chain must be burned to trigger the bridging service through the Token Bridge. Once the service delivers to the target chain's Token Bridge contract, a new xERC-20 token is minted and transferred to the user.
## What is xERC20?
xERC-20 is [Connext](https://www.connext.network/)'s implementation of cross-chain ERC-20 tokens. The design is based on [EIP-7281 (sovereign bridged tokens)](https://ethereum-magicians.org/t/erc-7281-sovereign-bridged-tokens/14979), which was pioneered by some of Connext's founders. Though the proposed standard is still gaining adoption and awaiting formalisation, Beefy's contributor team recognise that the standard provides two core benefits which merited adoption in our case:
* All the contracts for xERC-20 are (or can be) deployed by the project, meaning it retains total control over the implementation of the underlying ERC-20, the xERC-20, the lockbox and the bridge mechanism; and
* The xERC-20 tokens can be used with any number of different bridging solutions at the same time, as the storage, minting and burning of the underlying and bridged tokens is all managed by the protocol.
## Is bridged $mooBIFI different to native $mooBIFI?
Yes - bridged $mooBIFI is entirely different in terms of the underlying code when compared with the native. The native $mooBIFI ERC-20 is issued by the [Incentive Programmes](/ecosystem/protocol/incentive-programmes) (the BIFI Vault), and thus reflects an actual deposit of $BIFI in the vault, being put to use by its strategy.
By contrast, bridged $mooBIFI is an xERC-20 token with no technical connection to the BIFI Vault or any of the functionality therein. On a smart contract-level, bridged $mooBIFI is very simple, and exists purely with the understanding that it represents a claim over the underlying $BIFI held in the lockbox contract on Ethereum.
In light of the inconvenience of needing to bridge back to Ethereum, and possible any perception of risk around bridged copies, it may be possible that the bridged $mooBIFI is also priced differently to the native $mooBIFI and underlying $BIFI tokens by the free market. This is a natural phenomenon and to be expected.
## Which bridging provider does the Token Bridge use?
As explained in [#what-is-xerc20](#what-is-xerc20 "mention") above, the Token Bridge's use of the xERC-20 implementation means that it does not rely on any one particular bridging provider, and can in fact use multiple providers at once. This was extremely attractive to the Beefy contributor team, as the migration itself had been necessitated by our dependence on a fallen bridging provider.
A flowchart showing the 4 bridge contract pairs on Ethereum and Optimism on launch.
Instead, the new Beefy Token Bridge is launching with 4 different providers:
* [**The Optimism bridge**](https://app.optimism.io/bridge/) - the core bridge between Optimism and Ethereum which ensures that all tokens received on Optimism through the bridge are canonical with the underlying assets held on Ethereum. **Please note that the Optimism bridge is currently only enabled for one deposits from Ethereum to Optimism, in light of the constraints with transaction finality when going the reverse direction** ;
* [**LayerZero's omnichain interoperability protocol**](https://layerzero.gitbook.io/docs/) - LayerZero's cross-chain messaging service which is used for lightning-fast exchanges between a huge range of chains;
* [**Axelar's cross-chain gateway protocol** ](https://docs.axelar.dev/)- Axelar's cross-chain messaging services which ensures decentralized execution of messages across its range of validators; and
* [**Chainlink's cross-chain interoperability protocol**](https://chain.link/cross-chain) - Chainlink's cross-chain messaging service which takes advantage of the existing Chainlink decentralized oracle network.
Across the 4 solutions provided at launch, users have the choice to optimize for the benefits of certainty, speed, decentralization and infrastructure. But with the xERC-20 architecture, there is no limit on the number of providers that can be incorporated into the system. That way, the distribution of our $mooBIFI token to other chains can remain firmly decentralized and not reliant on any one provider, allowing Beefy to future proof the cross-chain design of our $BIFI token.
# Beefy Bulletins
Not everyone recognizes the "perfect" trade when they see it...
So it's time for the world to get Beefy.
{% content-ref url="/pages/-McuWJJW9J8uitkX1Dqj" %}
[What is Beefy?](/ecosystem/beefy-bulletins/what-is-beefy-finance)
{% endcontent-ref %}
{% content-ref url="/pages/-McuWJJX\_hzN3s1XUacZ" %}
[The Big Beefy Opportunity](/ecosystem/beefy-bulletins/the-big-beefy-opportunity)
{% endcontent-ref %}
{% content-ref url="/pages/-McuWJJYWLBsCt6OpiNb" %}
[What Makes Beefy Different?](/ecosystem/beefy-bulletins/what-makes-beefy-different)
{% endcontent-ref %}
{% content-ref url="/pages/-McuWJJZYozXUUtwIyzF" %}
[How Does Beefy Work?](/ecosystem/beefy-bulletins/how-does-beefy-finance-work)
{% endcontent-ref %}
{% content-ref url="/pages/-McuWJJ\_bMSfJDNHLLm0" %}
[Beefy Fees Breakdown](/ecosystem/beefy-bulletins/beefy-finance-fees-breakdown)
{% endcontent-ref %}
{% content-ref url="/pages/-McuWJJaQYTcMrU7oIZf" %}
[Why Beefy Beats Your Bank](/ecosystem/beefy-bulletins/why-beefy-beats-your-bank)
{% endcontent-ref %}
{% content-ref url="/pages/-McuWJJbkQSDzVo2\_j8r" %}
[Introducing Beefy's Unique Revenue Share Model](/ecosystem/beefy-bulletins/introducing-beefys-unique-revenue-share-model)
{% endcontent-ref %}
{% content-ref url="/pages/-Mdr1SzVBtbVc41MSoQQ" %}
[Beefy's Coveted Advantages Revealed](/ecosystem/beefy-bulletins/beefys-coveted-advantages-revealed)
{% endcontent-ref %}
# What is Beefy?
Beefy has been called many things…
* "The compound interest opportunity of a lifetime"
* "The safest and best way to get started in DeFi"
* "Passive income on steroids"
* "Just a really good, super decentralized investment"
***But in practical terms, Beefy is a yield farming optimizer that removes the daily actions and regular fees associated with manual optimization.***
What you're left with is very safe funds and a *very* good return of investment (ROI).
For those new to decentralized finance (DeFi), yield farming is simply a way to make some interest — as opposed to just "gains" — with your crypto holdings.
Money is one thing, but time is the most important asset of all.
***Beefy makes it simple to benefit from the upside of complex farming strategies.***
There are lots of farms to choose from, so Beefy automates and optimizes different investment strategies in the background while you get on with your day.
The project consists of an anonymous team constantly exploring new methods of optimizing automation to secure the largest yields possible.
As a decentralized project with a crypto-mindset, there is a robust governance system in place to put the decision-making power in the hands of those invested in the project.
**This takes place through governance mechanisms related to Beefy's own fixed-supply, revenue earning token, $BIFI.**
# The Big Beefy Opportunity
There are two types of people in this world: those who have a vague desire to achieve their financial goals, without ever taking any specific and deliberate action to make it happen, and those who "run the numbers" and are ready to seize the opportunity when they see it.
This might sound like a cringe 80's television commercial, but the truth is the strength of Beefy comes from what we BUILD, not what we say.
*So, what have we built?*
Like any other DeFi Yield Farm, Beefy has created an opportunity for its users to both automate AND maximize the ROI of their holdings.
But what is unique to Beefy is a decentralized working hub for people with a vision to come together and build the future of global finance.
Smart contract devs, UI, UX, strategists, statisticians, designers, and artists — anyone can join and contribute (no matter your nationality, sex, or views).
*By investing in Beefy, you are investing in the idea that a group of highly technical individuals can safely, securely and creatively leapfrog the dinosaurs of traditional finance.*
The two main variables in wealth generation are:
Time (how long) and yield (how much).
We'll take care of the yield.
**All you have to do is decide how soon you would like to get started.**
# What Makes Beefy Different?
Investor and crypto evangelist Naval Ravikant was once asked, "What would you be working on if you were 25 again?"
**Naval's reply:**
*"An unstoppable, uncensorable social media platform."*
In other words, he'd be working on a technological platform that puts science and code ahead of cronyism and censorship. This is the foundation of Beefy.
Some other values we align ourselves with:
*Trustless, open-source, decentralized, scalable, transparent, community-driven, cross-chain, autonomous, sustainable, innovation, healthy treasury, contribution rewards, developer bounties, safety.*
In practical terms, our sustainable tokenomics mean the day-to-day is unrelentingly focused on the product. We provide the greatest variety of vaults and the highest number of chains. Users can request vaults directly from our developers on Discord and the time it takes to answer these requests is very low.
At the time of writing, we have more than a dozen smart contract developers (and growing) carefully testing and reviewing the vaults, investment strategies and smart contracts before public release.
**Safety is everything.**
And we offer this while saving you time and energy through automation.
***Be first. Be safe. Be Beefy.***
# How Does Beefy Work?
We know that entering the crypto and DeFi arenas can be confusing and disorientating…
We know that entering the crypto and DeFi arenas can be confusing and disorientating. We know that many have lost money in altcoins and have high levels of scepticism about this new opportunity.
So let's break down what Beefy does in language as close as possible to how the current financial world works.
**1. You know what interest is:**
You have $10,000 in your bank account and you earn a 12.5% annual return on your investment. After 12 months, you receive a deposit of $1,250 as an interest payment. After five years, you have $16,250.
**2. You know what compound interest is:**
It's interest on interest. You get interest on the initial amount you put in, and you get interest on the interest already accumulated from the previous years.
So with compound interest, after 5 years you won’t have $16,250, you'll actually have $18,020.
So far, so good.
***But what if there was a "third way"?***
This is the question we asked ourselves as programmers.
**3. Here's what Beefy interest is:**
When you take your crypto and stake it on Beefy we find ways to add to the compounding of your asset. If one of the platforms we use gives away a promotional coin on top of any interest, then we take that promo coin and sell it for more of what you staked.
***The result is a significantly higher overall annual return.***
When Beefy combines your 12.5% annual compounding interest with the 14.2% interest of another site's promotional coin, you get 28.02% APY on Beefy.
Beefy's BNB Venus vault is doing just that. At the time of writing, you get 28.02% APY for your BNB.
**After five years, you won't have $18,020, you'll have $34,386; all in the asset you actually staked.**
# Beefy Fees Breakdown
Anyone familiar with the fee structures typical of traditional finance will tell you fees matter.
**How much do fees matter?**
The answer can be hard to wrap your head around.
* $1M invested for 30 years at 8% with a 1% management fee yields $7.62 million.
* $1M invested for 30 years at 8% with a 2% management fee yields $5.74 million.
* $1M invested for 30 years at 8% with a 3% management fee yields $4.32 million.
**Now, let's throw out modesty for a minute.**
Unlike some platforms flashing their APYs for your attention, there are no catches on Beefy.Finance. For example, they'll promote an APY, but won't mention there's a penalty fee if you withdraw early.
Or the APY is given as a spectacular headline number, but the small print is that you have to *manually* compound every single day to get that number.
**At Beefy we're proud to be doing things a little more transparently.**
*With our vaults, performance fees are included in the APY.*
**So what you see is exactly what you get.**
Our vaults on Beefy charge a fixed performance fee structure on their harvest rewards. As described in [Vaults](/beefy-products/vaults#what-is-the-vault-fee-structure), these fees are distributed back to $BIFI tokenholders, the Beefy [Treasury](/dao/treasury), our strategists and the user that harvests the vault. They are the main source of revenue for the platform.
**Here's what a typical vault looks like:**
* 3.0% is distributed back to $BIFI tokenholders who participate in the protocol's governance incentives program;
* 0.5% is allocated to the Beefy treasury;
* 0.5% is awarded to the vault strategist; and
* 0.05% is awarded to the one calling the harvest function.
Following the passage of [\[BIP:45\]](https://snapshot.org/#/beefydao.eth/proposal/0xb070348f6c2cc229f2bcdc0c042077ee8eab4307a307b89537f8a78089b0c2eb), Beefy has introduced a maximum performance fee structure of up to 9.5%. Where this is applied to new vaults, here's what it typically looks like:
* c. 3.06-3.24% is distributed back to $BIFI tokenholders who participate in the protocol's governance incentives program;
* c. 5.44-5.75% is allocated to the Beefy treasury;
* 0.5% is awarded to the vault strategist; and
* 0.01-0.5% is awarded to the one calling the [Strategy Contract](/developer-documentation/strategy-contract#harvest) function.
For the rare vaults which do not [Harvest on Deposit](https://docs.beefy.finance/ecosystem/products/vaults#what-is-harvesting-on-deposit), we assign a withdrawal fee of up to 0.1% to each vault to protect bad actors from abusing the vaults with too much flipping. We share this amongst all the other users participating in the vault.
Finally, for users of our Beefy ZAP V2 tool, we charge a 0.05% zap fee on your deposited amounts when entering or exiting a vault. These fees are returned to the Beefy treasury by way of a intermediate batching treasury, which allows fees to be aggregated and swapped into stables before being deposited. See [How to use Beefy ZAP](/faq/how-to-guides/how-to-beefy-zap) for more details on the ZAP V2 tool.
Apart from the fees fully listed above, anyone using Beefy should also remember the network transaction fees when adding or removing funds. These small fees go to the operators keeping the blockchain running, not Beefy.
**Bottom line: fees matter.**
When a Beefy vault offers you an investment with 14.46% APY, that's always with fees already factored in...
$1M invested for 30 years at 14.46 % APY yields…
$57,492,639 million
**With Beefy, what you see is what you get.**
# Why Beefy Beats Your Bank
A question the wealthiest people in the world obsess over:
**"What is the biggest opportunity for investors right now?"**
It would be imprudent to mention more than superficial details, but it's common knowledge that there are financial benefits, investment vehicles and tax advantages accessible to high net-worth individuals that are closed to everyone else.
*What we can talk about is how traditional banks work, and demonstrate clearly why Beefy.Finance is a better option.*
When you give money to a bank, it lends that money out to other people at a higher rate than you get for "saving".
**The bank pockets the difference as revenue.**
And that money is used to pay for things like staff, rent, call centers, security guards and a myriad of other operating expenses that may or may not be justified.
**Meanwhile Beefy is a decentralized autonomous organisation, collectively owned and managed by its users.**
Decisions are not a top-down event. So instead of the earnings going to a small clique of champagne-quaffing executives, they can only be redistributed with the approval of the organization. DAOs like Beefy are governed by proposals and voting. Code automates the everyday actions banks pay clerks to execute, while cryptography protects your funds.
**So, there are two things happening here:**
First, a DAO is significantly more efficient than a bank. Second, there is a huge demand for better APY than the 0.1% currently on offer by most institutions, which is significantly less than the current inflation rate of 2%.
When you learn that there is a new and safe way to store your money with an APY that is **at least 70x** as good as your bank...
And you appreciate that this APY is available because DAOs are fundamentally better organized to pass on efficiency savings to their users...
You might reasonably ask how soon you can get started.
And the answer to that is today.
**Because, unlike banks, there's no approval process.**
# Introducing Beefy's Unique Revenue Share Model
By buying $BIFI and staking in BIFI Maxi, you have something unique
**At long last DeFi adopters are beginning to realize that it's ridiculous to believe so strongly in a better financial system, and then spoil the whole moment with degenerate gambling.**
Hence, the growing popularity of decentralized projects with sustainable tokenomics and platform governance.
They're in a class by themselves.
These projects are **more efficient**, have **better stability and security** and are more likely to attract the **attention of the market**.
Owning $BIFI not only allows you to participate in platform governance, but also to start earning daily interest payments by staking your holdings in the right place.
Here's where things get *remarkable* — listen closely.
All the APYs you see on Beefy vaults have the platform fees factored in. These fees are used to buy back more $BIFI from the open market every single day and reward it to those who have their holdings staked in the BIFI Maxi Vault.
So by buying $BIFI and staking in BIFI Maxi, you have something unique:
*Daily revenue from a non-inflationary revenue token where the "company" buys shares off the market every day, and gives you more of them.*
This creates a financial "flywheel" for your money, where a continuously improving set of repeatable, tactical actions scale with decreasing friction to grow your investment.
**In other words, yesterday's gains are tomorrow's capital.**
Beefy is being built by a group of dedicated smart contract codesmen, backed by a community of UI, UX, strategists, statisticians, designers and artists.
That's why the smart money is on [Beefy.Finance](https://www.beefy.finance/).
# Beefy's Coveted Advantages Revealed
How we attract coding and creative talent
*"An organization's ability to learn, and translate that learning into action rapidly, is the ultimate competitive business advantage."*
— Jack Welch, former chairman and CEO, General Electric
**In any activity, there are some advantages that have to do with resources and some that have to do with the absence of them.**
That underdogs often come out on top is because the latter has "unseen advantages" against the former.
At Beefy.Finance, we don't consider ourselves underdogs…
And we generally prefer to let what we build do the talking…
However, a core component of our vision for the future is attracting and incentivizing the best coding and creative talent on the planet to join our community.
Through our unique reward system, our developers receive a percentage of Beefy.Finance's revenue from the vaults they build for Beefy.
Because this exists, we have grown an enormous development team quickly — an army of smart contract developers who are ready to create new vaults almost the same day as we finish our due diligence.
The migration from TradFi to DeFi is a marathon rather than a sprint, but it serves the market to be able to act quickly when we need to.
The marathon means having safety as our number one priority.
The sprint is sustainably spinning up new vaults.
***Code — and the talent that writes it — is the ultimate force multiplier in this arena, and its leverage advantage is compounding at a spectacular rate.***
If you're a smart contract developer who favors future rewards over legacy resources, you know where to find us.
# Vaults
Last Update: April 2024
### What is a Vault?
Vaults are investment instruments that employ a specific set of [strategies](/beefy-products/strategies) for yield farming or [CLM](/beefy-products/clm). They make use of automation to invest and manage deposited funds, which help to achieve high levels of compounding interest. By using a Beefy vault to compound your gains, you save countless small transactions and their associated gas costs, and precious personal time. Instead of manually managing your position our vaults do that all automatically and at a higher frequency.
Vaults are the core of the Beefy ecosystem. In a Beefy vault, you earn more of the asset you stake in it, regardless if this is an liquidity pool (LP) token or a single asset. For example, vaults where one can stake BTC-BNB LP will result in more BTC-BNB LP over time, effectively growing your share in the liquidity pool and thus allowing for more and more fees and rewards over time.
Despite the name 'Vault' suggests, user funds are never locked in any vault on Beefy. One could always withdraw from a vault at any moment in time. Beefy also does not own user funds staked in vaults. However, it is generally best to view vaults as investment tools to store funds for the medium to long term in order to have the effects of compounding really kick in.
When browsing the vaults on the platform, you will see the annual percentage yield (APY), which takes the frequent compounding into consideration compared to annual percentage rate (APR) which does not. You will also see daily interest percentages and the total amount invested in a vault by all users (TVL). Furthermore, one can see what underlying platform the vault is using as a source of revenue.
Each vault can either refer to a pair of tokens invested in liquidity pools, such as CAKE-BNB LP tokens within the Binance Smart Chain ecosystem, or a single token invested in lending platforms or single stake reward pools. After depositing tokens to a vault, the user is supplied with vault specific mooTokens which represent their share in the vault. We will elaborate on mooTokens in the next section.
Anyone in the Cowmoonity can work together to build new strategies and submit them to the Beefy team for review. However, a new vault will not be accepted if the underlying platform does not adhere to the [SAFU Standards](/safety/beefy-safu-practices).
Summarizing, vaults can:
* Efficiently execute yield farming strategies.
* Compound rewards into the initially deposited token amount.
* Use any asset as liquidity.
* Provide one asset as collateral for another.
* Manage collateral at a safe level to mitigate liquidation.
* Put any asset to work to generate a yield.
* Reinvest earned profits.
Users can sit back and relax, and watch their investment grow!
### **What are mooTokens?**
A mooToken is an interest-bearing, tokenized proof of deposit that you will receive at the moment you deposit in a Beefy vault. A mooToken is unique per vault, e.g. you get $mooBIFI tokens when depositing $BIFI into the BIFI Vault. One can view mooTokens as the receipt of your vault deposit.
{% hint style="info" %}
Beefy users should hold on tightly to their mooTokens and not sell or exchange it, since you would lose ownership of your staked vault assets if you did so!
{% endhint %}
### How do mooTokens earn interest?
Beefy's vaults automatically create more of your deposited asset in the form of compound interest. By holding mooTokens in your wallet, they are increasing in value against its corresponding vault asset. The number of mooTokens in your wallet will remain constant, but the quantity of the vault tokens they can be redeemed for increases. This is also the reason why mooTokens do not 1:1 match with the token amount initially deposited.
### How do I redeem mooTokens for the initially deposited tokens?
Whenever you want to withdraw the tokens that are staked for you in Beefy's vault, you simply initiate a withdrawal transaction to exchange them. The mooTokens are then taken from your wallet and burned, and your deposited assets plus yield will be given back to you.
### What are the advantages of the mooToken system?
Beefy's mooToken system has a few major advantages:
1. mooTokens allow any user to withdraw their fair share of deposited funds;
2. the system allows you to deposit the mooToken receipt to a cold or hardware wallet for ultimate safety;
3. your privacy is maintained, as you remain anonymous to Beefy. Your funds in the vault are not tied to the wallet address from which you made the deposit, since the mooTokens are the only evidence of your share in the vault. Therefore, you could withdraw your share of funds from a different address if you moved your mooTokens to it;
4. mooTokens can have tax benefits. Not only do our mooTokens make bookkeeping super simple, but since you're not selling off your rewards or receiving staking rewards direct to your wallet, (in many jurisdictions) you will not be incurring tax liabilities in the same way you would with farming your own yield; and
5. Lastly, mooTokens can be used as interest-bearing collateral.
### **How often do the vaults harvest their profits and reinvest?**
Vaults are normally harvested multiple times daily and profits are automatically reinvested (compounded). You can check the harvesting and compounding rate of a vault using [this how-to guide](/faq/how-to-guides/how-to-check-harvesting-compounding-rate).
### Why can't someone just do this themselves?
They could, but vaults help you save on personal time and transaction fees, maintain healthy collateral to debt ratios, self-optimize for the best possible yields, and automatically reinvest earnings. Attempting to do this manually would result in large inefficiencies. At Beefy we like to say: "Sit back and relax, the vault does all the work for you."
### **What is the vault fee structure?**
Most vaults have a performance fee structure, taking a percentage cut of all harvest rewards. This fee on profits is split up and distributed back to $BIFI tokenholders, allocated to Beefy's treasury, sent to the strategist that developed the vault and sent to the one calling the vault's harvest function. These fees are already built into the APY of each vault and daily rate. You do not need to calculate it yourself. The performance fee and the fee structure breakdown are presented inside the Deposit and Withdraw module in a vault.
The performance fee on additional yield, i.e. vault profits, is in part distributed back to $BIFI tokenholders and is the main source of Beefy's platform revenue. A part of it also funds Beefy's treasury which is used to further fund platform development, security and other initiatives. The performance fee was also implemented to promote community engagement and governance participation. A successful and engaged community is critical for our future growth, which in turn rewards platform users even more.
Furthermore, some vaults have a withdrawal fee. The main purpose of this fee is to prevent possible exploits from bad-faith actors. Without the fee, somebody could deposit just before the harvest() function execution and withdraw straight after that event, taking a % of the gains generated by legitimate stakers. Withdrawal fees stay in the vault and are shared amongst vault funds.
Finally, entering or exiting vaults using our Beefy ZAP V2 tool will incur a 0.05% zap fee on your deposited amounts. These fees are returned to the Beefy treasury by way of a intermediate batching treasury, which allows fees to be aggregated and swapped into stables before being deposited. See [How to use Beefy ZAP](/faq/how-to-guides/how-to-beefy-zap) for more details on the ZAP V2 tool.
### What is harvesting on deposit?
Many of Beefy's vaults "Harvest on Deposit". This means that when you deposit into the vault, you are also calling the harvest function of the vault's strategy. By calling the harvest function, you trigger the collection of pending farm rewards and compounding of those rewards back into the vault tokens for everyone.
Beefy does this so that it is impossible for malicious actors to steal yield, so a withdrawal fee is not required. This greatly benefits long-term investors.
Almost all of the vaults on more inexpensive chains like Fantom and Polygon harvest on deposit. You can tell if a vault harvests on deposit if there is no withdrawal fee.
For depositing, and thus calling the harvest function, you will receive a reward in the form of the native chain token (e.g. WFTM or WMATIC) due to the harvest call fee.
### Harvesting on Ethereum
As transaction fees on Ethereum are expensive, Beefy has introduced a few rules that determine the vault's harvesting frequency.
* Vault TVL is above $100k: vault will be harvested every 3 days.
* Vault TVL is below $100k but above $10k: vault will be harvested every 15 days.
* Vault TVL is below $10k: community harvest.
Community harvest implies that the harvest function on the strategy contract has to be manually called, and the transaction fees for doing so will not be subsidized by Beefy.
Another rule watches the gas prices on Ethereum. If `maxGasPrice` is 20 GWei or more, harvests will not be executed as they will become too expensive. This is regardless of a vault's TVL.
The Gelato Off-Chain Resolver that handles the harvests on Ethereum based on the aforementioned rules can be found following this link: [Gelato Automate](https://beta.app.gelato.network/task/0xa9d7e4ca2aacf1884f45f403b50c941953cf6b80489b5d17ad96a366bcb7b75f?chainId=1). The smart contract and its parameters, as well as past Executions and Task Logs, are also easily accessible there.
### Harvesting on BNB Chain
BNB Chain also has a harvesting constraint in place:
* Vault TVL is below $10k and older than 2 weeks: community harvest.
### **Does the performance fee get taken out when I withdraw my funds?**
No, the performance fees are on profits and are taken every time someone calls the harvest() function.
### Does the vault page show the APY?
Yes. Our displayed APY values reflect the predicted rate earned on a vault in a year. This rate is determined by the underlying platform it uses, the strategy that it is interacting with at the time, the total amount of funds in the vault and also takes into account the effect of compounding. As a unique feature, we have also included all vault fees in the APY calculation. What you see is what you get!
### What risks do the vaults have?
Beefy vaults are audited, but this does not mean that a vault is entirely risk free. As with any smart contract, the ultimate risk is that an investor's funds can end up stolen or unable to be withdrawn. Failing that, there are risks that underlying protocols and tokens may fail and not behave as intended (e.g. failing to deliver rewards).
The team does take steps to quantify the security risks of smart contracts and will only interact with ones that meet a specific set of requirements after excessive testing to make sure the underlying platform does not contain so called 'rug-pull' functions. For a detailed breakdown of the steps Beefy takes before adding new vaults, please consult [SAFU Standards](/safety/beefy-safu-practices). Or for a brief overview of key risk checks performed, review [Risk Checklist](/safety/risk-checklist).
### **Who is in control of the vault?**
Each vault and [strategy](/beefy-products/strategies) is hardcoded, and the code has been built to be immutable, so once they are released, they become unalterable. No one can modify the vaults and strategies.
Modern Beefy vaults do however rely on the standard set out in EIP-1167, known as ["minimal proxy" contracts](https://blog.openzeppelin.com/deep-dive-into-the-minimal-proxy-contract). Minimal proxies reduce deployment costs for repetitive contracts (e.g. vaults) by maintaining the vast majority of core functionality in a single implementation contract. They then configure the individual characteristics of the specific strategy (e.g. the relevant tokens and pools) through the minimal proxy contract - which is a much smaller contract to deploy - which directs instructions through to the implementation contract.
Users should be aware of the distinction between minimal proxy contracts and the proxy pattern used to upgrade contracts. **Beefy's minimal proxy contracts are not upgradeable**, so Beefy cannot take your funds by a sly upgrade. The proxy is only used to reduce deployment costs.
### **What are the different vaults?**
* **Money Market :** Utilizes lending platforms, such as Venus on BNB Chain or Scream on Fantom, to generate the highest possible yield for these coins (e.g. BUSD, BNB, LINK, DOT, DAI, USDT, ETH, or BTCB).
* **Native Token Farming :** Takes advantage of the high yield on popular farms by depositing another asset to earn, sell and compound profits of the native reward token.
### What will I get out when I make a vault withdrawal?
The default is that you withdraw the token type that you deposited, because at Beefy you earn what you stake. You will get the amount you deposited plus the yield generated (minus a potential vault withdrawal fee). For vaults supporting Beefy ZAP, users can withdraw directly into other assets, including any assets forming part of the in the relevant liquidity pool for ZAP V1, and any of the bluechip, native or stable assets supported for ZAP V2.
### **How do LP vaults work?**
Liquidity pool (LP) vaults work by reinvesting the fees awarded to LP participants. In return for providing liquidity to the pool, many platforms reward investors with tokens. Our vaults regularly harvest these rewards, sell it, buy more of the LP’s underlying assets, and then reinvest to complete the cycle.
This compounds the rewards gained from a liquidity pool. Beefy creates strategies that automate this process, saving you time and gas fees in comparison to farming manually. This is all done for a tiny fee that is distributed back to those who deposit $BIFI into the BIFI Pool or BIFI Vault. A small percentage also goes to the Beefy treasury.
### **How often are balances updated in the vaults?**
Pending rewards are not reflected in the balance until they are swapped for the initial deposited token. This can vary depending on the strategy running.
### **How do vaults get added to Beefy?**
New potential vaults can be discussed in our Discord. Our strategists then add the potential investment strategy to our strategy list. A priority is assigned to each new, potential strategy based on its APY, TVL and sustainability. Our developers/strategists then attack the list from top priority to bottom.
Then the platform which the vault is potentially going to deposit into, is thoroughly screened to ensure its contracts and systems are safe and secure. For more information on our security checks, please refer to the [SAFU Standards](/safety/beefy-safu-practices) page.
### **What’s your vault naming process?**
Each vault on the platform is named after the token that users can deposit in it. For example, the CAKE-BNB LP vault uses CAKE-BNB LP tokens for its investment strategy. A BTC vault uses the BTC token, etc.
Underneath the vault name, you can find the platform used for investing the token and farming its yields. For example, Uses: Venus means that that particular vault invests the token in Venus, a DeFi algorithmic money market and synthetic stablecoin protocol.
### **How do lending vaults work?**
*The following applies to: Aave, Banker Joe, Blizz, Geist, Scream, Venus, and similar lending platforms.*
Most Beefy single asset vaults utilize decentralized marketplaces for lenders and borrowers. By depositing your initial asset in the vault, Beefy deposits it into the lending marketplace and borrows against your token at safe levels of collateral.
The borrowed tokens are redeposited into the platform, and once again used as collateral to borrow more tokens. This cycle is repeated multiple times to generate as much interest as possible from the lending interest and the reward token, which is used to buy more of your originally deposited assets. This strategy is also known as a folding strategy. It is noteworthy that this "leveraged" multi lending and multi borrowing is only with the deposited vault token, so there is no liquidation risk due to token price swings.
{% hint style="info" %}
Transaction fees: because of the multi supply and borrow cycle, the transaction fee for a deposit into or withdrawal from these vaults is generally higher as compared to other vaults.
{% endhint %}
{% hint style="warning" %}
Marketability risk: when the underlying token on the lending platform becomes overborrowed, it can prevent the vault's strategy from deleveraging (unfolding) to accommodate a withdrawal. This usually happens when the market is most volatile, or when there is an ongoing event for which people want to borrow funds from the lending platform. The overborrowed condition will naturally resolve once liquidity returns to the lending platform, a process which can take hours or, sometimes, a few days. Meanwhile, funds always remain safe.
{% endhint %}
Due to accruing debt/supply interest, one may notice that the deposited token amount may decline ever so slightly in between harvests. After the harvest event, you will see your deposited token amount increase as the yields are compounded back into it. The change in deposited token amount over time of a typical lending style vault looks as follows:
# Strategies
Last Update: August 2023
### What is a Strategy?
Beefy strategies are modular smart contracts which direct the user funds deposited into [Vaults](/beefy-products/vaults) towards liquidity pools and farms in order to generate the yield which Beefy compounds. Where sufficient rewards have amassed in the strategy contract for Beefy to profitably reinvest them, the strategy executes the compounding workflow (or [Strategy Contract](/developer-documentation/strategy-contract#harvest)), which automatically claims the rewards, swaps them for the principal assets and redeposits them into the liquidity pool and farm.
Strategies are the core product which of Beefy's protocol, as - unlike the vault contract - each strategy is generally unique. Because each strategy involves a different combination of assets, pools, protocols and chains, each requires [individual testing](/safety/beefy-safu-practices#new-vault-testing-procedure) to ensure it is working as intended before it can be pushed into production.
As strategies are the component of a Beefy Vault which interact with external protocols, they are also the component which contains exposure to extrinsic risks beyond Beefy's control (e.g. flaws of the contracts of other protocols). Because of this, strategies contain additional functionality to respond to extrinsic risk, including the ability to [Strategy Contract](/developer-documentation/strategy-contract#panic) the vault - i.e. withdraw all funds from third party contracts to be held safely in the strategy - or [Strategy Contract](/developer-documentation/strategy-contract#pause-unpause) - i.e. halt the operation of all of the contract's functions.
### How do liquidity pool strategies work?
Beefy's most common product is a standard liquidity pool vault, often built on the Uniswap V2 standard (i.e. a 50/50 balance of two assets with uniform concentration across the pool).
Taking this as an example, the workflow of the strategy starts with user deposits, which can be either the LP token, the underlying assets of the vault, or (with [ZAP V2](https://beefy.finance/articles/revolutionizing-beefy-zap-in-partnership-with-1inch/)) any supported bluechip asset or stablecoin. The deposit is secured in the vault to handle the deposit/withdrawal workflows, before being transmitted to the strategy.
The strategy then deposits the assets into the liquidity pool, and in turn the LP tokens into a farm, which begins to accrue both trading fees and farm rewards for the user.
The vault then regularly claims the accrued rewards, routes them to a core liquidity pool for swap them back into the underlying asset, and then redeposits the underlying asset into the Beefy vault and strategy.
### How do lending strategies work?
Standard lending vaults work in a very similar way, taking assets deposited in the vault and deploying them into the lending pool of choice.
Instead of trading fees and farm rewards, lending pools pay out interest on deposits and lending incentives, which need to be redeemed, exchanged and redeposited by the strategy.
### **Who is in control of the strategies?**
Each vault and strategy link is hardcoded, and the code has been built to be immutable, so once they are released, they become unalterable. No one can modify the vaults and strategies.
Modern Beefy strategies do however rely on the standard set out in EIP-1167, known as ["minimal proxy" contracts](https://blog.openzeppelin.com/deep-dive-into-the-minimal-proxy-contract). Minimal proxies reduce deployment costs for repetitive contracts (e.g. strategies) by maintaining the vast majority of core functionality in a single implementation contract. They then configure the individual characteristics of the specific strategy (e.g. the relevant tokens and pools) through the minimal proxy contract - which is a much smaller contract to deploy - which directs instructions through to the implementation contract.
Users should be aware of the distinction between minimal proxy contracts and the proxy pattern used to upgrade contracts. **Beefy's minimal proxy contracts are not upgradeable**, so Beefy cannot take your funds by a sly upgrade. The proxy is only used to reduce deployment costs.
With that said, all vault contracts do contain the functionality to change the strategy where - for example - an underlying DEX replaces its liquidity pool with an upgraded version. Strategy changes allow user funds to be retained in the vault (avoiding imposing migration costs on the user), but allow the strategy to be kept up to date. Strategies are replaced using the [Vault Contract](/developer-documentation/vault-contract#upgradestrat) function, and the [Vault Contract](/developer-documentation/vault-contract#proposestrat) functions of the vault as a precursor, both of which emit trackable events to monitor strategy replacements.
### **How can I make a strategy?**
For users looking to get more involved and become a part of Beefy's team of strategists, you can post and discuss your strategy ideas in Beefy’s Discord in the #🎯-strategy-devs channel. Please make sure to provide detail of what pool and farm you're considering, what type of protocol they're on and what the APY is. There will be a template to help you get started.
### **What is APR and APY?**
APR reflects the simple interest rate over a year’s time, while APY describes the rate with the effect of compounding**.**
### **Is APY/365 the right way to determine daily gains?**
No, the effect of compounded interest is exponential, not linear. A daily compounded interest of 1% would yield 3678.34% a year. The correct formula for daily yield is: *Daily Yield = ((1 + Annual Yield) ^ (1/365.25)) - 1*.
### **How does Beefy optimize APY?**
Beefy automates the entire compounding process, making it close to optimal as possible. The key factor is the frequency of compounding events, which depends on different variables in the system, like current gas prices, rewards accrued and liquidity for swaps. Beefy's sophisticated harvesting automation technology is watching all of the protocol's vaults around the clock, waiting eagerly for the next optimal opportunity to harvest.
# CLM
Last Update: August 2024
### What is CLM?
CLM stands for *"cowcentrated liquidity manager"*, which is Beefy's liquidity management product for concentrated liquidity (***"CL"***) pools. In essence, CLM allows day-to-day users to access the enormous opportunities of CL technology, without the effort and user-error risks that come from managing their own positions. The CLM contract issues depositors with an ERC-20 *"Cow Token",* [*"Reward Cow Token"* ](#how-does-the-clm-reward-pool-work) or [*"Moo Beefy Token"*](#how-does-the-clm-vault-work), reflecting their share of the pooled CLM funds being deposited into the CL position.
As with all other Beefy products, CLM automates complex onchain activities and aggregates scale across users to bring down the average cost for everyone. This means users get higher rates of return with far less effort when compared with handling the process yourself.
*What's in it for Beefy?* A share of all earnings generated are retained as fees for the DAO, the $BIFI tokenholders, the product's creator and the account harvesting the earnings. This means that all of the stakeholders involved in compounding user yields share a small proportion of the total rewards, whilst the user is always earning. It's a win-win-win-win-win.
CLM is a form of *"active"* or *"automated"* liquidity management (**"ALM"**) technology, and stands in contrast to a number of other ALM products currently on the market. CLM brings a unique approach to maximizing utilization, which is aimed squarely at delivering optimal yields for our users.
### What is Concentrated Liquidity?
Concentrated liquidity is a mature form of onchain liquidity that offers higher yields and better availability than traditional liquidity. Instead of having to provide liquidity for swaps at any price range (as with traditional liquidity pools, like [Uniswap V2](https://docs.uniswap.org/contracts/v2/overview)), users can tailor the range at which they are willing to provide their own liquidity. The Trade-off is receiving a greater share of trading fees within the selected range, in exchange for the risk of no fees when their position falls out of range. CL technology was first popularised by Uniswap's v3 protocol, and has since blossomed across many different iterations and protocols. The [UniV3 documentation](https://docs.uniswap.org/concepts/protocol/concentrated-liquidity) is the best place to start learning about the specifics of how concentrated liquidity works.
CL products introduce more features to the onchain liquidity process, but also add more complexity. As prices are constantly moving, managing CL positions requires constant evaluation of the appropriate range to supply liquidity, which was not a concern with earlier generations of liquidity pools (like [Uniswap v2](https://docs.uniswap.org/contracts/v2/overview)). CL positions are also typically represented by non-fungible tokens rather than fungible ERC-20s, meaning they require an entirely different set of functions and interfaces to interact with the smart contract position.
Though Beefy has [found ways](https://beefy.com/articles/beefy-cl/) to autocompound CL positions using other liquidity managers, our traditional yield farming products were not designed to interface directly with CL pools. Beefy's CLM products help to bridge that gap.
### What's the difference between CLM and yield farming strategies?
CLM represents an expansion of Beefy's automation products to a different level of the supply chain. Unlike our yield farming [Strategies](/beefy-products/strategies), CLM directly creates and manages liquidity positions, with no need for intermediate farms or incentives. The below table provides a quick and simple breakdown of the differences between these two core products:
Yield Farming / CLM Vaults
CLMs / CLM Pools
Built on Liquidity Pools
Yes - indirectly through farms
Yes - directly
Requires Farm Rewards
Yes
No
Trading Fees
Compounded in underlying products
Compounded by Beefy
Rewards
Compounded by Beefy
Accrued/Distributed by Beefy
Concentrated Liquidity
Indirect only with CL managers
Directly manages CL positions
Range Management
Depends on provider
Yes
Harvest Process
Claim rewards, swap and redeposit into the principal
Claim fees/rewards and resets position(s)
Token Name
mooTokens or mooBeefy Tokens
cowTokens or rcowTokens
As the two products sit at different levels of the supply chain, Beefy's yield farming strategies can actually be built on top of Beefy's CLM products where there are rewards to compound into the CL position. CLM has been designed from the ground up to offer an optimal approach to automated liquidity management, in a way that unlocks optimal autocompounding of incentives through our ordinary strategies.
### How does CLM work?
Beefy's CLM products are laser focused on ensuring that the maximum amount of user capital in the product is deployed, in range and earning (or *"fully active"*). This includes not only the deposited funds, but also any trading fees accruing on the current investment and all past trading fees which have already been compounded back into the position. Where trading fees are constantly reinvested, we unlock the magic of compounding, leading to significantly increased returns. Where rewards are paid in place of trading fees, the rewards accrue for users to claim on the Beefy app.
The CLM method is extremely simple. Every time a CLM product either receives a user deposit or is *"harvested"*, Beefy automatically: (1) withdraws all deposits and trading fees to reset the position; (2) redeposits all of one token and most of the other into a precise 50/50 position; and (3) redeposits all other tokens into a single-side position (a.k.a. the ***"alt"***). Where the quantity of deposited tokens doesn't match the current ratio of the liquidity pool, the correct ratio of tokens will be deposited and the remainder will be returned to the user.
To ensure the position stays within range, the range is reassessed and reset every 6 hours by way of automated onchain calls of the privileged *moveTicks()* function in the strategy contract. This facilitates smooth, consistent and predictable maintenance of range, without the risk of manipulation by third parties.
In some cases such as Solidly forks, a pool may not pay trading fees but instead provide rewards in other tokens not included in the pool. In those circumstances, Beefy will distribute these to holders in the same manner as other forms of rewards - i.e. as a linearly-accruing claimable reward.
As trading fees or rewards accrue and price changes in the pool impact on the position's range, the position's effectiveness will change over time until the next harvest. However, Beefy routinely harvests all products with any rewards every day (on all chains except Ethereum).
#### Alt Position
The *"alt"* position exists to ensure that the user's entire position remains fully active, and all tokens are deployed in range. The advantage of the alt approach is that there is no need to *"rebalance"* the position (i.e. sell the outperforming token to buy the underperforming). ALM products which regularly rebalance by selling tokens immediately realize impermanent loss, which can significantly dampen profitability in products which rebalance regularly (e.g. narrow-range CL products).
As shown by the dotted line in the graph below, the alt is positioned differently from the main position to take full advantage of the provided liquidity. Instead of using the main position's range, the alt is provided in a smaller range set between (i) the upper or lower boundary of the main position (depending on which token is overweighted); and (ii) the nearest valid *"tick"* (or fixed boundaries between discrete areas in price space) between the adopted boundary and main position's other boundary.
In the example below, the alt position is being set in the range between the dotted line and the bottom blue line, whereas the main position is being set between the two blue lines, which are set equidistant from the current price (i.e. the white line).
The "Alt" position works by counterbalancing the main 50/50 position with a single-side position configured to a smaller range than the main position. Together the two ensure full deployment of assets and maximal earnings without rebalancing.
#### Calmness Check
A wider general issue with many forms of concentrated liquidity products is that prices can be manipulated by attackers, for instance using flash loans. To protect against this, CLM incorporates checks on deposit to ensure that deposits are only made in *"calm"* periods, meaning periods where the relative change of the current price arising from the deposit is not large relative to the time-weighted average price (or **"TWAP"**) of the pool.
The *"calm zone"* is shown in the blue area of the diagram below, and is bound by the pool's TWAP over the last 60 seconds. Where in some cases the current price exits the blue *"calm zone"*, the contract's logic has identified large relative changes and the deposit transaction will be reverted to safeguard against attacks aimed at stealing part of the user's deposit funds.
The "calm zone" ensures deposits are only possible when the current price sits within a reasonable margin of the time-weighted average price. This ensures users won't lose funds through deposits during times of high volatility.
### How does the CLM Pool work?
All CLM products are designed to handle rewards - i.e. additional tokens paid out to liquidity providers beyond trading fees - natively, so that users never need to exit their CLM position to benefit from additional incentives.
Rewards can be distributed by Beefy using our CLM Pool contracts, or through third party services like [Merkl](https://merkl.xyz/) by Angle. The CLM Pool contract accepts the standard CLM *"cowToken"* as a deposit and then issues a corresponding *"rcowToken"* at a 1:1 ratio. Once deposited, the position benefits from a share of any rewards currently being paid out by the CLM Pool, and will automatically participate in any future rewards. Rewards can be claimed on the relevant product page on the Beefy UI, or manually direct from the smart contract.
By default, the Beefy UI (including our ZAP tooling) now automatically deposits user funds into the CLM Pool contract, so no additional work is needed to benefit from rewards. Where for any reason a user continues to hold a standard *"cowToken"*, this can be deposited into the CLM Pool using the UI. Likewise, the withdrawal workflow now automatically bypasses the standard *"cowToken"* working primarily with the CLM Pool version.
### How does the CLM Vault work?
Beefy can also build its classic autocompounding [Vaults](/beefy-products/vaults) on top of CLM products, which automatically claim all incentives being paid out, swap them back into the principle assets and redeposit into the CLM product. As ever, this results in a compounding effect, unlocking the higher exponential rewards that Beefy is known for. This is by far the easiest way to access all the benefits of concentrated liquidity with minimal effort and maximal rewards.
Like our standard vaults, the CLM Vaults are ERC-20 compliant, so issue a *"Moo Beefy"* token (with ticker prefix *"mooBeefy..."*) to users who deposit them. And as with vaults, the amount of underlying *"cowTokens"* or *"rcowTokens"* being handled by the strategy will increase over time, meaning *"mooBeefy"* tokens are not 1:1 with the underlying assets. As many concentrated liquidity designs do not involve issuing an LP token like classic UniV2 liquidity (often using NFTs instead), it is the underlying CLM tokens that increase, rather than an LP token.
In addition to compounding all underlying rewards, Beefy's CLM Vaults also have the ability to host [Boost](/beefy-products/boost) incentives on top. To access, users simply deposit their *"mooBeefy"* tokens into the boost contract to begin accruing rewards in a linear fashion. This is necessary for rewards which Beefy agrees not to sell/compound, such as grant-funded tokens.
### Do CLM products suffer from impermanent loss?
CLM's novel design results in a different approach to impermanent loss (**"IL"**)). However, IL itself remains a feature of generally all forms of DeFi liquidity, and does occur within CLM products (as with all other ALM products). It is important to develop an understanding of how IL operates and the risks it presents before investing in any CL products.
The key difference with Beefy CLM is that, while the the position is in range, IL not realized because assets are promptly returned into range either in the main or alt positions without selling any assets. In other ALM products, the act of rebalancing the position (i.e. selling tokens) within range range causes IL within the position to become realized during its ordinary life, whilst also incurring additional fees in selling the token. Where price oscillates heavily, this can mean IL is repeatedly realized where the range is somewhat too narrow and the position frequently rebalances.
### How does impermanent loss work in concentrated liquidity?
Impermanent loss in concentrated liquidity products can be divided into two types:
1. **Range IL** - where the provided liquidity is in range and being traded, so both the quantity and value of assets attributable to the user's position changes over time when compared with not providing liquidity at all; and
2. **Out-of-range IL** - where the provided liquidity is out of range and not being traded, so the quantity of assets attributable to the user's position remains static, and only the value of assets changes over time when compared with no providing liquidity at all. In these circumstances, the balance is always overweighted in the underperforming asset.
Range IL is natural to all CL positions, and is a necessary consequence of a position being able to earn trading fees or rewards. The core determinant of the size of any Range IL is the size of the range selected for the pool. For example, the IL users experience in ordinary non-concentrated liquidity (e.g. [Uniswap V2](https://docs.uniswap.org/contracts/v2/overview)) is effectively the same as the Range IL from a CL position with a range covering all prices. In all narrower ranges, the amount of Range IL suffered from the same price movement is relatively larger in CL pools than traditional pools. At extremely narrow ranges, a minuscule move in price can significantly imbalance a position, meaning very high levels of Range IL.
We can think of basic CL positions as imposing limits on the possible Range IL of a position. Where a position is left to operate within a single fixed range, the amount of Range IL it can suffer is naturally limited on both sides by the end of its range. However, where the range on the position is later reset by selling tokens, the potential Range IL from the new range will be cumulative (i.e. in addition to) any Range IL that was realized by resetting the original position. This means that there is no limit on the possible aggregate Range IL that users can suffer through actively managing CL positions. Poorly managed positions can easily lose value through Range IL over time.
The other side of this natural limit on Range IL is Out-of-range IL, which kicks in when the position moves our of range and Range IL stops. Out-of-range IL is a generally undesirable phenomenon, because the user is not earning anything by providing liquidity but is bearing increased exposure to the underperforming asset. The benefit of Out-of-range IL is that it limits the amount of IL a position can suffer by fixing the quantity of tokens entirely in the undervalued token. In a situation where two assets are oscillating in price against one another, some temporary exposure to Out-of-range IL may be tolerable where the user expects the position to come back into range in a reasonable period of time. However, where the position is expected to be out of range for some time or even permanently, there is nothing to be gained from the CL position, and so it's often best to just realize the Out-of-range IL and move on.
### How do I evaluate impermanent loss in a concentrated liquidity position?
Though it is necessary to consider both types of IL to evaluate CL positions and realize the benefit of ALM products, in practice the two types interoperate over the life of a position. When a position falls out of range, the current Range IL is translated into Out-of-range IL, so the difference in token quantities is crystalized and only the difference in price continues to cause IL. When that same position comes back into range, the Out-of-range IL is dissolved back into the Range IL, so Out-of-range IL no longer needs to be considered.
However, most CL users will be focused on the net profit of their position, which is the sum of all earned trading fees and all realized and unrealized IL. For in-range positions, net profit offsets trading fee earnings against changes in both price and quantity giving rise to Range IL. For out-of-range positions, net profit only considers price changes for Out-of-range IL, but also factors in the lack of trading fee or reward earnings. And finally, where a positions moves into and out of range over time, a calculation of net profit requires a consideration of the cumulative realized and unrealized Range IL and Out-of-range IL as well as the net earnings arising from the stop-start trading fees/rewards being earned on the product.
The undesirability of out-of-range positions and IL is the core reason for developing and using ALM products, such as Beefy CLM.
### How does impermanent loss work in ALM products and CLM?
All CLM and ALM products will suffer Range IL as prices change. As described above, individual concentrated liquidity positions naturally limit Range IL by imposing a single range for trading. However, when an ALM position (including CLM products) falls out of range and is reset, the IL from the previous setting is then realized within the position, meaning the quantity of the assets held in the position can decrease when compared to what was deposited. ALM products, including CLM, accept the risk of Range IL in the expectation that the trading fees or rewards earned from staying in range should exceed the Range IL in the long term.
Where the range is continually changed over time in an ALM product that rebalances by selling tokens, IL from every reset will be aggregated over time and can easily exceed the IL a user would have suffered by comparison in a normal unmanaged position. By contrast, CLM does not sell tokens, meaning Range IL is not realized until the position is exited or moves out of range, meaning the aggregate IL of CLM products tends to be lower than with other ALM products.
The real value of Beefy's CLM product is how it handles Out-of-range IL. Much like all ALM products, CLM is designed to tackle positions falling out of range and failing to earn trading fees or rewards. However, unlike most other ALM products, CLM achieves this by naturally balancing the user's asset exposure with its *"alt"* position.
By contrast, many other ALM products seek to "rebalance" their position, meaning they will sell the overperforming asset to purchase more of the underperforming asset, and fully reset the position to an equal balance. The impact of this is that all IL affecting the position at the point of rebalancing is fully realized whenever the product is rebalanced, and what's reinvested is the sum of the deposited assets, the trading fee earnings and the cumulative IL to date. All too often, the cumulative IL in traditional ALM products will far exceed earnings, meaning users walk away with less than they deposit.
By effectively avoiding realizing Range IL and handling Out-of-range IL, Beefy's CLM products avoid much of the IL that other ALM products will be unavoidably affected by. This means a CLM position is less likely to suffer a net loss because of IL than other ALM products. In situations where two assets oscillate in price against one another, traditional ALM products may frequently rebalance, thereby realizing and aggregating a far greater amount of IL. Meanwhile, CLM calmly resets the alt balance holding IL at bay until the user chooses to exit.
### In what situations does CLM perform best?
CLM is designed to capture maximal trading fee yield for those who are comfortable earning either of the assets in the underlying liquidity pool. The product aims for that sweet spot between maximal asset utilization without the need to constantly rebalance the position by selling assets. The net impact will often be higher APYs than most other ALM product designs on the exact same pool.
The trade-off for CLM users is that the position does sustain asset imbalances reflective of Range IL. Overtime, the alt can become the larger or even dominant portion of the position, which is not suited to users who are uncomfortable holding an imbalanced proportion of the underperforming asset. The key determinant of the speed and likelihood of the alt dominating the position is the size of the position's range: very narrow ranges can be quickly imbalanced by Range IL, leading to a very large alt position and a significant amount of unrealized IL.
### Are any situations still risky for CLM?
Absolutely. It's a simple fact that all concentrated liquidity products present additional risks of falling out of range, which result in all assets being traded into the undervalued token in the pair. Ordinarily, this risk can be mitigated by widening the range of the position; however, CLMs aim for an effective range setting that will always earn attractive trading fees (e.g. sufficient in-range liquidity for aggregators to route through for large transactions). This means that CLM products will always be vulnerable to the risks of Out-of-range IL where the market corrects sharply and quickly. This is the same for all concentrated liquidity products where the range is narrower than the full range of prices.
For example, let's imagine depositing into a new WETH-USDC CLM product at a precise 50/50 balance. The range of the product is set at c. 20% of the relevant price range, meaning 10% either side of current price. Assume that a correction in the price of $ETH means the pool's price dips 16% within the 6 hours between range resets. This would (i) take the CLM product out of range into 100% $WETH; (ii) thereby realize Out-of-range IL; and (iii) on reset, would create a large $WETH single-side position. Now imagine in the next 6 hours the price recovers by 11% of the original 16% dip, again taking the position out of range, but in the opposite direction. Again, this: (i) takes the CLM product to 100% $USDC; (ii) realizes Out-of-range IL; and (iii) lead to a large $USDC single-side position. The price then gradually recovers to the original prices, and the position naturally returns to a 50/50 balance.
The impact of the above scenario is that Out-of-range IL is being realized on both sides of the pool:
* First, the 50% $USDC has effectively been traded for $WETH in the first 10% range, which is at prices lower than the deposit, meaning more $WETH, no $USDC, and lower USD value. At 100% $WETH, the position then suffers all the loss in the remaining 6% dip in $ETH's price. After being reset after 6 hours, the range of the position will be 10% either side of the lower price (e.g. 10% of 84% (=100%-16%), so 8.4% relative to the original deposit).
* Second, after the price moves in the opposite direction by 8.4%, all of that $WETH will have been traded for $USDC at lower averages prices than the $ETH was obtained for. As $ETH continues to increase in price up to the full 11%, the position won't participate in those increases as the position is 100% stable. This means the 100% $USDC position will have a firmly lower USD value than the initial deposit, and the decrease will be greater than the net change in prices (16% decrease - 11% increase = 5% net change) as it incorporates the realized Out-of-range IL on both sides.
* Finally, as the position promptly returns to the normal price, more deposits and/or trading will naturally return the position to a 50/50 balance at the same price. The 100% $USDC will be used to buy back $ETH at the lower prices, but with less overall assets. Upon returning to the starting prices, the original depositor would notice that they have less of both assets, coming from realized Out-of-range IL losses, despite the assets and prices being returned to the same position as at the start. They may also consider that they would have had zero loss for just [holding](#what-does-the-hold-statistic-show) the assets.
The above risks factor into any ALM product, and involve natural risks to consider in all concentrated liquidity scenarios. No product is able to completely avoid these facets of concentrated liquidity without some kind of trade-off elsewhere. Here, CLM is performing as intended - assets are promptly returned to range and continue earning trading fees throughout these spikes (which are often significant as trading increases with the price volatility). The position is regularly reset to avoid the risk of going out of range early in the scenario and missing all trading fees. And towards the end, the saner market allows the position to recover a natural 50/50 balance and the users to continue earning in a normal fashion quickly and consistently.
With that said, users should be aware that CLM still bears IL risk in these extraordinary scenarios, as do all concentrated liquidity products. The value proposition for long-term users is that extreme scenarios may happen for a day or two each year, but the rest of the time their CLM position is safely generating the consistently higher returns that concentrated liquidity offers at minimal effort.
### How does CLM optimize my yield?
CLM's innovative formula for managing concentrated liquidity positions aim to bring users far superior yield with a number of improvements:
* Earnings are harvested automatically to reduce the time users need to invest in managing their positions;
* Any trading fees are reinvested to establish a compounding effect within the product, i.e. by earning more from previously reinvested earnings;
* Any trading fees are harvested regularly to increase the rate of compounding in the product;
* Deposits are aggregated, meaning a single set of gas fees split across many users rather than each user incurring the same gas fees separately;
* The aggregate volume of deposits means less time is needed to build up to a profitable harvest, which can also increase the rate of compounding in the product;
* The range is reset with each deposit and harvest, minimizing the amount of time spent out of range and not earning trading fees;
* Excess assets arising from the gradual imbalance of the pool are placed in range through a single-side position, meaning they still earn fees;
* No rebalancing takes place, meaning out-or-range IL is not realized in the product; and
* CLM positions are automatically added to the Beefy CLM Pool to benefit from a range of different rewards without any action by the user.
### What is the displayed yield on CLM products?
The displayed yield on Beefy CLM products reflects: (1) the current trading fees being compounded from the CL pool, extrapolated out for the next year; (2) the current simple rate of any rewards being paid out by the CLM Pool; and (3) the current simple rate of any rewards being paid out by Merkl.
All additional rewards accrue in the Beefy app to be claimed by users, and are not automatically reinvested by the CLM product. Only the yield from trading fees reflects compounded *"annual percentage yield"* or APY; all additional rewards are displayed as an *"annual percentage return"* or APR. Where a Beefy yield farming strategy is built on top of a Beefy CLM product, the additional rewards will also be compounded, giving a total APY across the entire position.
Past and current performance is no indication of future yield, so users are advised to review the volatility of yield in any CLM product and the likelihood of future demand for the pool's liquidity before investing.
### What is the percentage displayed in the title of my CLM product?
All CLM products include a percentage figure as part of their CLM labelling, which denotes the pool fee tier for the underlying CL pool. A CLM product with a percentage of *"0.30%"* charges buyers and sellers using the pool a 0.3% fee on their transaction, which is deducted from the balance of tokens they receive from a trade with the pool. A *"0.05%"* pool charges a far lower fee.
In the case of CLM, fee tiers reflect the amount that Beefy depositors will be benefitting from as the pool is traded through by other parties. They are not to be confused with the Beefy fees charged on earnings. For example, a higher fee tier reflects a higher amount of earnings for the same volume. Higher fees are typically charged on more volatile pools and lower liquidity, which typically means lower volume.
### What does the "HOLD" statistic show?
The Position Performance module for CLM Pools shows a *"HOLD"* statistic*,* which expands to show a *"CLM vs Hold"* figure. These figures are intended to give an impression of what impermanent gain or loss exists within the position, relative to if the user had simply held onto the deposit value in 50% allocations to each pool token with no other activity. The base figure next to the *"HOLD"* is what the current value of the user's funds would be for holding both 50% allocations, so reflects the change in market value only. The *"CLM vs Hold"* figure reflects the difference between the current value of the user's position, and the *"HOLD"* figure. A negative value means the user would have retained more USD value by simply holding the tokens. A positive value means the user has gained more in USD value by using the CLM product.
### What fees are charged on CLM?
Beefy's fee structure for CLM products is exactly the same as for our yield farming strategies, as set out in [Beefy Fees Breakdown](/ecosystem/beefy-bulletins/beefy-finance-fees-breakdown). The total fee is capped at a maximum of 9.5% of all trading fees earned in the product. More specifically:
* c. 3.06-3.24% is distributed back to $BIFI tokenholders participating in the protocol's governance incentives program;
* c. 5.44-5.75% is returned to the Beefy treasury to operate the Beefy DAO;
* 0.5% is awarded to the creator of the CLM product; and
* 0.01-0.5% is awarded to the party that calls the [Broken mention](broken://pages/XrLOWHZlKA7r9ykgszmE#harvest) function on the specific CLM product to claim trading fees and reset the position.
For CLM Pools, this fee is charged on all trading fees claimed by the position in the underlying protocol (as opposed to claims made by the user through Beefy). For CLM Vaults, a separate vault fee is also charged on the amount of each harvest - i.e. the rewards/incentives being claimed and reinvested by Beefy on top of the CLM Pool.
In addition, Beefy charges a small swap fee on deposits into an imbalanced CLM product, which is distributed to other users of the same product. This fee exists solely to protect against users taking advantage of the imbalance to swap their single deposit token into a balanced proportion of both tokens, by depositing less than is required to rebalance the pool and then immediately exiting. The fee scales depending on the size of the deposit and the imbalance, but for practical purposes it is capped at no more than 50% of the pool fee level.
As an example of a swap fee, imagine a user depositing into a ETH-USDC CLM product which charges a 0.05% pool fee and is overweighted in $ETH (meaning the user would need to deposit more $USDC). Imagine the imbalance amounts to 1,000 $USDC. A user wanting to deposit $5,000 would first deposit 1,000 $USDC, before depositing a 50/50 balance of $USDC and $ETH from the remaining funds. The swap fee is only charged on the imbalanced deposit, so just on the 1,000 $USDC and not the whole $5,000. As the pool fee is 0.05%, the maximum swap fee is half of that, so 0.025% of 1,000 $USDC, or around $0.25. The fee is immediately distributed among the other user positions in the vault. As others later enter the product, the depositor in this example then also benefits from swap fees arising from the other depositors.
### How do I deposit into CLM?
Underneath the hood, Beefy CLM products accepts deposits that rebalance the existing position, which is effectively the inverse proportion of the current position's balance. This means users seeking to deposit a 50/50 quantity of tokens would use all of their underweighted token, but less than all of the overweighted tokens (e.g. 48/50), with the remaining tokens being retained by the user. This means the product will only accept the underweighted token up to the point of a 50/50 position, at which point it can only add equal values of both tokens.
To improve the user experience, Beefy's popular ZAP tooling has been brought to CLM to allow users to provide a single deposit of any of their favourite tokens, which will then be automatically swapped using DEX aggregators into the necessary proportionate of the relevant deposit tokens. Given that the balance of deposit tokens required to enter a CLM product can change at a moment's notice, a simple ZAP transaction is the optimal way to access the product.
{% hint style="warning" %}
**Single-side Deposits:** Because the CLM deposit tokens you receive on deposit reflect a proportional share of all tokens in the vault that's the same proportion for all users, a user who deposits only one token directly (i.e. not through ZAP) would instantly gain entitlement to a proportionate share of the other token in exchange for part of their deposit. This allows single-side deposits to effectively swap freely into the other asset, taking from the other depositors in the vault who are left with more of the single-side deposit asset. In extreme cases, excessive single-side deposits can deprive ordinary depositors of their alternative asset, leading to excessive and unintended exposure to the single-side asset for everyone.
{% endhint %}
### What happens when I withdraw from CLM?
The CLM withdraw workflow involves the vault contract taking back the deposit tokens that the user received for their deposit (meaning users need to approve access to the token from their wallet). Because of this, it's vital that users do not incidentally move or manipulate their cow or reward cow tokens for the duration of their deposit. Once the tokens are returned, they are immediately burned and exchanged for a proportional share of the tokens held by the CLM product which are sent back to the user.
For example, if a user has 1 cow token, from a total of 10 tokens issued, the user is entitled to 10% (= 1/10) of the tokens in the CLM product. If the product currently has 1 $ETH and 10,000 $USDC, the user will receive roughly 0.1 $ETH and 1,000 $USDC. This can be a totally different quantity to the user's original deposit; for instance, the user could have deposited 0.15 $ETH and 500 $USDC, in which case appreciation in the price of $ETH has significantly impacted the final tokens received.
With ZAP tooling, users can also withdraw into any token of their choice, using DEX aggregators to automatically swap out the different tokens included into the position.
### Who is in control of the CLM products?
As with our yield farming strategies, each CLM product is generally designed to be immutable, meaning they cannot be altered after deployment. However, as with our ordinary strategies, CLM products rely on the standard set out in EIP-1167 known as ["minimal proxy" contracts](https://blog.openzeppelin.com/deep-dive-into-the-minimal-proxy-contract), meaning identical CLM products can be deployed easily with reconfigured settings. The CLM vault contract then has functionality to change the strategy it is using to the reconfigured strategy, meaning Beefy's contributors are able to switch strategies where issues arise. All strategy updates are timelocked and operated by the Beefy Development Council's multi-signature wallet.
For more information, see the equivalent comments for yield farming strategies at [Strategies](/beefy-products/strategies#who-is-in-control-of-the-strategies).
### Has CLM been audited?
Of course! As a brand new product with an innovative new design, Beefy's contributor team have worked closely with a series of leading auditors to tackle all conceivable security and operational risks. You can find copies of their various reports here:
* [Audit 1](https://github.com/beefyfinance/beefy-audits/blob/master/2024-02-28-Beefy-Zellic-CLM-Audit.pdf) by Zellic dated 28 February 2024;
* [Audit 2](https://github.com/beefyfinance/beefy-audits/blob/master/2024-04-06-Beefy-Cyfrin-CLM-Audit.pdf) by Cyfrin dated 6 April 2024;
* [Audit 3](https://github.com/beefyfinance/beefy-audits/blob/master/2024-06-30-Beefy-Certora-CLM-Audit.pdf) by Certora dated 30 June 2024; and
* [Audit 4](https://github.com/beefyfinance/beefy-audits/blob/master/2024-07-02-Beefy-Sherlock-CLM-Audit.pdf) by Sherlock dated 2 July 2024.
# Zap
Last Update: April 2026
Zap tools are a category of smart contract that bundle a variety of different functionality into a single straightforward workflow (or even one atomic transaction). They aim to deliver the smoothest user experience from decision to executed onchain action.
Beefy's array of zap tooling sits at the heart of our mission to make DeFi easy. It's is a key differentiator between Beefy and other DeFi projects. Beefy's goal is to enable users of all skill levels to discover and access yields from across the EVM world. With zap, Beefy complements its thousands of products by making it as easy as possible for users to navigate from one to another.
### Beneath The Hood
Zap tools aggregate an array of different processes, abstracting the various steps from the user. Underneath the hood, Beefy's core zap processes are:
* **Simulating a deposit or withdrawal into the product** to ascertain what balance of assets is expected. Where UniV2-style LPs reliably require 50/50 deposits/withdrawals, more complex products like Beefy CLM typically deal with an unequal and unpredictable balance of assets.
* **Fetching quotes from all available aggregators** for each required swap. This step ensures that Beefy offers users the best price possible from Beefy's active integrations.
* **Calculating the precise swaps** needed to maximise the amount of deposit assets in accordance with the deposit simulation.
* **Relaying messages** to bridge funds between chains where the user is seeking to deposit or withdraw to other chains.
* **Executing the swaps** by submitting orders to each aggregator and paying the relevant fee.
* **Executing the deposit or withdrawal** by executing the relevant functions on the different Beefy smart contracts. In our more complex products like CLM, this can involve multiple interactions with different nested contracts to complete the required action.
* **Charging any fee** that Beefy stipulates for the relevant zap product. Not all zap products incur fees. See [Fees](#fees) below to learn more about those which do.
* **Returning any unused assets** directly to the user wallet. Often the act of swapping or depositing will alter the simulated values, meaning slightly more or less of each is received. Beefy returns all received assets to the user.
Beefy's systems and interfaces receive user specifications for products and assets to zap between and then generate the bespoke payloads required, which are fed to the [BeefyZapRouter contract](/developer-documentation/zap-contracts#beefyzaprouter-contract) on the source chain. This includes a precise combination of the relevant items in the above list, and sometimes covers multiple of the same step (e.g. multiple quotes and swaps).
See [Zap Contracts](/developer-documentation/zap-contracts) for a full breakdown of the underlying Beefy contracts that deliver these various processes as part of zap.
{% hint style="info" %}
For more specific questions and answers relating to crosschain zaps, see the [Crosschain Zaps FAQ](/faq/crosschain-zaps) page.
{% endhint %}
### Versions
Over time, the functionality and complexity of Beefy's zap infrastructure has evolved to make use of new technologies to improve user experience. This is reflected in the different versions of zap.
Though the codebase of Beefy's zap tooling is not formally versioned (and indeed has been split across multiple repositories over time), Beefy nonetheless adopts informal version names to differentiate between distinct generations of its zap tools:
Version
Introduced
Description
Zap V1
March 2021
Enter LP products on the chain with one of the LP tokens, swapping through the LP to obtain the other deposit asset.
Zap V2
January 2023
Enter any product on the chain with any supported token, swapping through 1inch to obtain all the necessary deposit assets.
Zap V3
December 2023
Enter any product on the chain with any supported token, swapping at the best price from several distinct DEX aggregators to obtain all the necessary deposit assets.
Zap V4
March 2026
Enter any product on any supported chain with any supported token, swapping at the best price from several distinct DEX aggregators to obtain all the necessary deposit assets.
Though each generation fully replaces the previous, community members may from time to time hear reference to a *"V3-style zap"* or *"V1 only, no V4 yet"*. In practice, Beefy's UI operates with a range of different options for zap to suit user needs. Not all products support all generations of zap. And sometimes users only need the most basic V1 style of zap.
### Integrated Services
To facilitate swapping and bridging as part of these zap processes, Beefy has partnered with a range of industry-leading providers:
| Service | Type |
| ---------------------------- | --------------- |
| 1inch Swap API | Swap Aggregator |
| KyberSwap Aggregator API | Swap Aggregator |
| LiquidSwap Route Finding API | Swap Aggregator |
| Circle CCTP | Bridge |
Where issues arise with any of these components during a zap, Beefy and its users may need to rely on the systems of these external providers and raise issues directly with them. However, Beefy makes a point of integrating neutral protocols which operate with a high degree of independence and neutrality, not blocking or excluding any portion of our user base.
For services looking to explore an integration into Beefy zap, please reach out in the #partnership-requests channel on the [Beefy Discord server](https://beefy.finance/discord).
### Fees
To fund the use and ongoing development of zap tooling, Beefy introduced new **Zap Fees** as part of zap workflows in the V2, V3 and V4 releases. There are currently three types of fees that together comprise the total Zap Fees charged to the user:
Type
Minimum
Maximum
Description
Swap Fee
0 Swaps @ 0.05%
2 Swaps @ 0.05%
Charged only on swapped assets where swaps are required. Can approach $0 where only minor swaps are needed. Can require 2 full swaps of all assets where zaps are required on 2 chains. Fee charged by Beefy.
Bridge Fee
No Fee or
0.01%
0.14%
Charged on bridged assets where bridging is required. Fee charged by CCTP and subject to change. See Fees Table for latest update.
Relay Fee
$0.10
$1
Charged as flat fee where bridging is required. Fee charged by Beefy to cover the cost of claiming bridged assets and initiating deposits.
Zap Fees
$0.10 + 0%
$1 + 0.24%
Aggregate fees; sum total of the above.
**The Swap Fee** is set and received by Beefy, and is the only payment Beefy receives from the swap. In some cases, this is recovered in partnership with the swap aggregator as part of their workflow. The swap aggregators also seek to gain something from these swaps, and each swap aggregator is different: in some cases, they are compensated for the integration by deducting any positive slippage from the trade; in others, they incorporate additional hidden fees into the quotes offered; finally, some are also subject to agreements with Beefy for the payment of API charges or subscriptions, or for a share of the revenue Beefy generates.
**The Bridge Fee** is set and received by Circle only as part of CCTP for fast transfers. On most chains, fast transfers are necessary to ensure swap quotes do not expire before the bridging process completes. On chains where fast transfers are not required, no Bridge Fee is charged. Beefy has no control over the fee mechanism of CCTP and accepts whatever fees are adopted by the protocol at the time of its operation. These fees may be subject to change by Circle without notice to Beefy or our users. Check the [Fees Table](https://developers.circle.com/cctp/concepts/fees#fee-tables) in the CCTP documentation for the latest rates.
**The Relay Fee** is set and received by Beefy to cover the cost of claiming the bridged funds, triggering the zap deposit workflow on the destination chain, and to cover the gas costs of both operations. The precise amount of the Relay Fee varies from chain to chain in accordance with gas costs on the destination chain. Beefy implements this as a static fee per chain: low-cost chains are $0.10 in fees; Ethereum and Linea are set at $1. The precise current breakdown of the fees is available in the `beefy-v2` repository under [`cctp-config.ts`](https://github.com/beefyfinance/beefy-v2/main/src/config/cctp/cctp-config.ts).
Applying these components to a few different circumstances for Beefy zap transactions, we can see how the breakdown of these fees varies from one action to the next:
Zap Type
Zap Fees
Explanation
Same-chain Zap with Swap
0.05% of assets swapped
Some or all of the deposited assets are swapped with a 0.05% fee charged only on assets being swapped.
Crosschain Zap From USDC
0.01% - 0.14% of assets bridged
$0.10 - $1 relay fee
0.05% of assets swapped
USDC deposits are bridged with a variable percentage fee charged by CCTP. Beefy charges a static relay fee to claim the assets and submit a deposit. Some or all of the received USDC is swapped with a 0.05% fee charged only on USDC being swapped.
Other Crosschain Zaps
0.05% of assets swapped
0.01% - 0.14% of assets bridged $0.10 - $1 relay fee 0.05% of assets swapped
All of the deposited assets are swapped for USDC with a 0.05% fee charged. USDC deposits are bridged with a variable percentage fee charged by CCTP. Beefy charges a static relay fee to claim the assets and submit a deposit. . Some or all of the received USDC is swapped with a 0.05% fee charged only on USDC being swapped.
Ultimately, the aggregate Zap Fees that users incur are highly dependent on the products and chains they're seeking to use. A few examples illustrate the different factors in the calculation of fees:
{% hint style="info" icon="1" %}
A user deposits **Base** **USDC** into a **Base** USDC-WETH CLM.
The CLM is unbalanced so that more of its assets are WETH, and the user can deposit most of their USDC without any corresponding WETH. Only 10% of the deposited USDC is swapped for WETH, and a 0.05% Swap Fee is charged on the 10%.
The total fee is just 0.005% of the total assets deposited (0.05% x 10%= 0.005%).
{% endhint %}
{% hint style="info" icon="2" %}
A user deposits **Base** **USDC** into an **Ethereum** USDC-WETH CLM.
The user first pays a Bridge Fee of 0.013% of assets to bridge out of Base. Next, a $1 Relay Fee is paid to claim the USDC on Ethereum, and relay the deposit into the CLM. The CLM is unbalanced so that more of its assets are in USDC, and the user must swap most of their USDC to WETH to deposit. 90% of the deposited USDC is swapped for WETH, and a 0.05% Swap Fee is charged on the 90%.
The total fee is 0.0463% of the total assets deposited (0.013% + (0.05% x 90%)= 0.013% + 0.045% = 0.0463%) plus the $1 Relay Fee.
{% endhint %}
{% hint style="info" icon="3" %}
A user deposits **Base** **WETH** into an **Ethereum** USDC-ETH CLM.
The user first must swap their WETH entirely to USDC, so a 0.05% Swap Fee is charged on all of the deposited assets. The user then pays a Bridge Fee of 0.013% of assets to bridge out of Base. Next, a $1 Relay Fee is paid to claim the USDC on Ethereum, and relay the deposit into the CLM. The CLM is unbalanced so that more of its assets are in WETH, and the user must swap most of their USDC to WETH to deposit. 90% of the deposited USDC is swapped back to WETH, and a 0.05% Swap Fee is charged on the 90%.
The total fee is 0.0963% of total assets deposited ((0.05% x 100%) + 0.013% + (0.05% \* 90%)= 0.05% + 0.013% + 0.045% = 0.0963%) plus the $1 Relay Fee.
{% endhint %}
As shown in the fee table above, the maximum aggregate Zap Fees for a user are $1 + 0.24%, involving the most expensive combination of chains with two full zaps of all deposited assets. By contrast, zap fees will approach zero for same-chain zaps requiring small swaps to acquire a secondary deposit asset (as shown in Scenario 1 above).
### Audits
As described more fully in our [Audits & Bounty page](/safety/bug-bounty-program), our Zap V3 codebase — particularly the core [`BeefyZapRouter` contract](/developer-documentation/zap-contracts#beefyzaprouter-contract) — was [audited](https://github.com/beefyfinance/beefy-audits/blob/master/2023-12-15-Beefy-OZ-Zap-Audit.pdf) by OpenZeppelin.
# Boost
Earn extra yield on top of your vault earnings!
As The Multichain Yield Optimizer, Beefy always wants to make sure that the users have the best experience possible using Beefy and get the highest APY with the least amount of manual effort. In order to do just that, we have expanded on the initial vault offering with a service called Beefy Boost in which we promote exciting projects on various chains. Together with the promotion, we boost certain vaults with the partner's token in order to give you the best APY.
## What is a Boost?
When you deposit in a Beefy vault, you receive a 'receipt' token prefixed with 'moo' in your wallet. When a Boost is available, you may stake that token in the Boost to receive the extra earnings benefit. You earn extra yield on top of your vault earnings!
## How do I use Beefy Boost?
First, look for a boosted vault in our main app and deposit the tokens that are asked for in the vault. Then, proceed to the Boost section to stake your [mooToken](#what-are-mootokens) "deposit receipts". Stake these [mooTokens](#what-are-mootokens) and you are all done! You can easily come back here to check on your earned partner tokens and withdraw at any time.
## How do I see my earned tokens?
Enter the vault where you deposited your [mooTokens](#what-are-mootokens) and it will show you a nice summary of your earned tokens.
## What are mooTokens?
A mooToken is an interest-bearing, tokenized proof of deposit that you will receive at the moment you deposit in a Beefy vault. One can view mooTokens as the receipt of your vault deposit. Read more about mooTokens under the [Vaults](/beefy-products/vaults) section:
* [What are mooTokens?](/beefy-products/vaults#what-are-mootokens)
* [How do mooTokens earn interest?](/beefy-products/vaults#how-do-mootokens-earn-interest)
* [How do I redeem mooTokens for the initially deposited tokens?](/beefy-products/vaults#how-do-i-redeem-mootokens-for-the-initially-deposited-tokens)
* [What are the advantages of the mooToken system?](/beefy-products/vaults#what-are-the-advantages-of-the-mootoken-system)
## How long will the Boosted vault last?
There is a timer shown in the Boost section for each boosted vault. This is nothing you really need to keep track of since you can always come back after a vault is finished and withdraw then.
## Do I have to manually unstake from the Boost when it is finished?
Yes, this is a mandatory user action when the Boost ends. For safety reasons, Beefy can not move your tokens back to your wallet. You can just come back after the Boost is finished to unstake your [mooTokens](#what-are-mootokens) together with the partner tokens, at any time, by hitting "Claim & Unstake".
## Can I enter multiple boosted vaults at once?
Absolutely! Just deposit the required tokens in one or multiple of our boosted vaults and then deposit your [mooTokens](#what-are-mootokens) in the Boost section. Repeat this step for every boosted vault you want to be a part of.
## Are boosted vaults safe to use?
Yes! Beefy always develops with *safety* in mind and has made sure the boosted vaults are completely safe. They are hosted by Beefy, and Beefy has gotten the boost tokens from our partners and uses our own vaults for the reward. The [mooTokens](#what-are-mootokens) you stake to receive the boost tokens do not leave Beefy.
## If I enter a partner vault with my mooTokens, will I still earn the ordinary vault reward?
Yes! The ordinary tokens you deposited in our main vaults will earn the ordinary rewards and be compounded as usual, even if it is boosted. This is because the [mooTokens](#what-are-mootokens) you deposit to enter the Launchpool boost are *interest-bearing*. By using the boosted vault, you earn both the vault tokens and partner tokens as a boost.
## Is there any fee on the Beefy Boosts?
Beefy takes a performance fee of 5% from the reward tokens. The fee is deducted when the boost starts and just like the [Vault fees](/beefy-products/vaults#what-is-the-vault-fee-structure), the APR that you see displayed is final so you don't have to account for the deduction.
## What does "Pre-Stake" mean?
This means there is an upcoming boost for this vault. You can stake your mooTokens ahead of time so that you will earn the Boost Rewards as soon the Boost begins.
## How come the APY shown at launch is not the same as it is now?
APY is the “annual percentage yield” and is calculated by compounding your yield interest daily. The daily yield in turn is based on factors such as the reward rate and the total amount of deposited tokens that share the rewards. When more people and in turn tokens enter the pool, the fixed yield is shared by more people (tokens) hence the daily yield will become lower and in turn, lower the APY. In the same way, if people (tokens) exit the vault, there are fewer people (tokens) sharing the fixed reward and the daily yield will increase and in turn, APY will increase.
## Are the promoted project and its tokens safe?
When partnering with a certain project, Beefy always makes an overall due diligence check of the project to get a sense of its sincerity and safety. For this, Beefy follows a stringent set of safety rules, as outlined in [Beefy SAFU Standards](/safety/beefy-safu-practices). Despite the project being safe code-wise, we can never guarantee if the partner token is worth holding. Therefore it is always up to you to make your financial decisions, to make sure that the partnering project is a project that you want to support or not, and that the partner token is one you want to hold or sell. Beefy cannot, and will not take any responsibility for your personal actions.
# Beefy-escrowed Tokens
Last Update: October 2022
## What is Escrow?
An escrow mechanism is where one party holds another's rights or assets in custody for them, pending fulfilment of a specific condition (e.g. safe receipt of goods purchased with those assets). In DeFi, escrow mechanisms involve you providing your tokens to a third party (e.g. Beefy) to allow them to implement some functionality with those tokens on your behalf. As such, all escrow mechanisms are typically built around some token economic (**"tokenomic"**) design in the tokens you hold.
For example, a blockchain's native token (e.g. Fantom's FTM) may be used for staking purposes to secure a blockchain by fairly and safely validating its transactions. The tokenomic design allows users to stake their tokens in order to earn transaction fees from users of the blockchain, giving the native token an ability to earn or generate value for the holder. However, staking is complicated and has trade offs, like locking your tokens and limiting your ability to trade in them. So third party escrow solutions (e.g. Beefy's beFTM) have been created to allow you to access the benefits of tokenomics (i.e. staking your FTM) without having to manage the staking yourself, and whilst allowing you to still trade your interest in the locked tokens.
## What is Vote Escrow?
A vote escrow mechanism is a form of tokenomic escrow design which aims to reward long term holders of a protocol's governance tokens with more voting power, to favour their interests in governance matters over short term holders. This is achieved by holders staking and typically locking their governance tokens with the protocol (typically for a return from protocol earnings), thereby limiting their ability to deal in those tokens. In doing so, the holder either unlocks voting rights (which are otherwise not available to holders) or boosts their existing voting power, typically in line with the amount of time that their tokens are staked/locked for. This voting power is often used to direct the economics of the relevant protocol, like by having users vote on how to distribute newly issued tokens as additional incentives among the protocol's liquidity pools.
The vote escrow system was pioneered in DeFi by Curve Finance's CRV and veCRV token design (hosted on Ethereum). Other notable examples of escrow designs include Convex's veCVX (Ethereum), Balancer's veBAL (Ethereum), Frax's veFXS (Ethereum), Mai Finance's eQI (Polygon), Trader Joe's veJOE (Avalanche), Platypus's vePTP (Avalanche), Velodrome's veVELO (Optimism).
## What are Vote-escrowed Tokens?
In most vote escrow systems, the voting power of users is not linearly related to the number of governance tokens held, but instead depends on factors like the length of time which the tokens are locked for. In light of this, the concept of vote-escrowed tokens (**"veTokens"**) was developed, to reflect the amount of voting power that a user has arising from their staked/locked tokens. As the factors that impact on voting power change over time, the user's amount of veTokens will also change, even as the number of governance tokens held stays the same.
One point of confusion is that - despite the name - veTokens aren't always represented by an ERC20 token, so aren't necessarily received and held by users in their wallet. This is because veToken economics ("**veTokenomics**") are designed to allow for voting power to change constantly as the input factors (e.g. length of the lock period) change. If veTokens were to be issued to users, they would require constant rebasing (adjusting the total supply and nominal holdings of all users) to maintain a fair record, which would add a lot of additional complexity and cost. Furthermore, as veTokenomics were designed to incentivise long-term holding of governance tokens, implementing voting power in a transferable ERC20 format may undermine that goal, as it would allow long term holders to trade their interests in the same way that short term holders do.
Example of veTokenomics
Imagine a voter holds 1 EXMPL token, issued by Example DAO and which entitles them to 1 whole vote in Example DAO's existing governance process.
Example DAO then implements a vote escrow design, where the voter can stake and lock their tokens for any length of time up to 2 years, and will receive a voting power boost equal to the number of time in years remaining in their lock.
In ordinary circumstances, the voter's 1 EXMPL token would entitled them to governance voting power equal to a static 1 veEXMPL, or 1 whole vote in the governance process.
The voter could then opt to lock their 1 EXMPL token for 2 years, and would receive 3 veEXMPL (1 base + 2 bonus), which amounts to 3 whole votes instead.
After a year of boosted voting, the holder's lock period would have decreased to 1 year, consequently reducing their bonus and veEXMPL so that they are entitled to 2 votes. The user can decide at any time to extend their lock back to 2 years to increase their veEXMPL, or they may decide that they want to exit the lock by waiting another year, and then sell their tokens.
## What are Beefy-escrowed Tokens?
Beefy-escrowed token ("**beTokens**") are wrapper tokens, designed and implemented by Beefy to unlock the benefits of escrow tokenomics whilst enabling our users to trade their interests in the partners' governance tokens. Effectively, we put in place an interim smart contract which can hold the governance tokens, lock them with the partner protocol for the maximum possible lock and gain access to the benefits of the escrow model. In addition, we add extra value by combining these features with issuing a new ERC20 beToken to you which you can then exchange to exit the lock at any time.
Each beToken is uniquely designed around the different veTokenomic model of our partner protocols, so they come with a range of different possible features. These can include: withdrawal reserves; supported DEX liquidity; pegged or free-floating pricing; a Beefy voting process for allocating votes on the underlying protocol; user-led or Beefy-led bribes; and boosts to associated Beefy vaults.
Beefy always support our beTokens with vaults on the Beefy platform, where you can stake your beTokens to earn a return. This may be in the form of an autocompounding beToken Vault (i.e. earn more beTokens) or an Earnings Pool (i.e. earning more of the underlying governance token). In either case, you're free to withdraw from your staking at any time, to trade in your beToken and exit your position.
## What Beefy-escrowed Tokens are there?
In this section, we provide a page covering each of the different beTokens that we currently operate. At the time of writing, these include:
{% content-ref url="/pages/cNuNeh5705Sxuv9VDSJh" %}
[beFTM](/beefy-products/beefy-escrowed-tokens/deprecated-products/beftm)
{% endcontent-ref %}
{% content-ref url="/pages/dTne9JFmyOE2KFGKZU1r" %}
[binSPIRIT](/beefy-products/beefy-escrowed-tokens/deprecated-products/binspirit)
{% endcontent-ref %}
{% content-ref url="/pages/I2cw9eSbRMhz7aTsADFH" %}
[beJOE](/beefy-products/beefy-escrowed-tokens/deprecated-products/bejoe)
{% endcontent-ref %}
{% content-ref url="/pages/26y3QgcOJI5hoTYG0BsF" %}
[beQI](/beefy-products/beefy-escrowed-tokens/beqi)
{% endcontent-ref %}
{% content-ref url="/pages/fXuSM1X1RdKcNg4YqJlJ" %}
[beVELO](/beefy-products/beefy-escrowed-tokens/deprecated-products/bevelo)
{% endcontent-ref %}
## Where can I find out more?
This section provides full details of the designs of each of our existing beTokens. You can also raise any specific questions about our beTokens by reaching out to us on the [Beefy Discord](https://discord.gg/yq8wfHd) server.
# beS
Last Update: April 2025
Beefy-escrowed Sonic (or ***"beS"***) is a liquid-staking token that supports the Sonic ecosystem. It aims to deliver the benefits of native staking on Sonic to Beefy's users, while increasing the quantity of staked Sonic securing the ecosystem.
In this section, we explore the functionality and details of beS' operations, and provide links to various resources to help you learn more.
## How does beS work?
New beS tokens are issued when users deposit wS tokens into the beS smart contract, whether directly or through the Beefy UI. Those wS tokens are automatically staked to generate rewards, which accrue to the beS tokenholders without further action — meaning beS is a yield-bearing token.
Behind the scenes, rewards are regularly claimed and redistributed to beS holders through the beS vault when the *`harvest()`* function is called. The harvest is automated by Beefy's Cowllector to occur at least every 24 hours. Unlike some Beefy products, beS does not have unconstrained harvests or harvest-on-deposit functionality, because a minimum quantity of tokens is needed for an effective restaking. The contract stores a *`lockDuration()`* variable (initially set to 1 day), during which no additional S can be staked. This prevents denial of service attacks.
When a user is finished with the product and wishes to exit, they initiate a withdrawal either directly to the contract or through the Beefy UI.
## How do beS withdrawals work?
Sonic withdrawals are configured to last 14 days, so beS withdrawals inherit an unavoidable 14-day delay period. Users can trigger a withdrawal either directly through the smart contract or through the Beefy UI.
Withdrawals can be made in whole or in part, meaning multiple withdrawals can be run in parallel. All current withdrawals associated with the user's address will be displayed when accessing the Beefy UI with that address connected.
The quantity selected by the user for withdrawal will include the nominal share of yield generated on those assets, meaning users will always withdraw with a larger quantity of wS per wS deposited (or *`pricePerFullShare()`* ) than when they deposited (provided beS has harvested between withdrawal and deposit). However, validators do not earn wS rewards while in the withdrawal process, so the amount of yield generated will be fixed when the withdrawal is triggered.
## Is beS always staked in Beefy's Sonic Validator?
No! Beefy's [Sonic Validator](https://my.soniclabs.com/stake/validators/0x1f/add-stake) has a limited capacity for staking, so it's foreseeable that the demand for beS may exceed the capacity of the validator. In such circumstances, additional validators can be added to beS' configuration, so that when all existing validators have zero capacity, the additional validator will receive any balance. This gives the product complete scalability.
In terms of the user experience, there is no impact of splitting staking across multiple validators. All the rewards are pooled and split equally among all users, so differences in the performance of different validators will affect all beS users equally. Likewise, if any of the validators used are slashed for any reason, the impact of that event on aggregate rewards will be socialised (or split equally) among all beS users.
Working with other partner validators opens up the possibility of deals and collaborations where Beefy is delivering significant volume. It also helps to encourage validator diversity across the ecosystem.
## What fees do I pay for using beS?
beS imposes two fees at the smart contract level through the *`_chargeFees()`* internal method. The two fees are both taken as a percentage of the staking yield generated by beS through staking user deposits. The two fees are:
* **the standard Beefy fee of 9.5%** - which is distributed to tokenholders and treasury;
* **a new *****"liquidity fee"***** of 10%** - which is indirectly distributed back to users through activities which support beS' liquidity, as described below.
## What is the *"liquidity fee"*?
The liquidity fee is a new mechanism introduced for beS, aimed at building a competitive and well-adopted product.
Liquid-staking products thrive on scale economics, and often require large amounts of bootstrapping (via issuer-led liquidity, incentives and partner deals) to build up momentum. Products that fail to scale typically perform worse. Where there is an element of chance in who is selected to propose new blocks, large staking operations with more validators are much more likely to be selected, and the benefits of being selected are shared with everyone, meaning users get much more frequent exposure to proposal rewards (even if those are spread more thinly).
beS' liquidity fee works by taking 10% of all earnings from its staking efforts and reinvesting them. The fees are sent to a [Liquidity Fee Safe](https://sonicscan.org/address/0xA3018Fd7ca0a3BA414cF52f06A6F1Be39b93b94E) wherein they are managed by members of the Beefy Treasury Council. These will then be used for bribes, boosts and other liquidity incentives whenever sufficient rewards have accrued. Decisions on how best to use the liquidity fee will be taken by the Treasury Council, always seeking to maximise uptake, liquidity and available yields for users. Where appropriate, the Treasury Council will seek to locate and make use of strategic deals with partners that leverage the liquidity fee to achieve an outsized benefit for users.
## How will the liquidity fee program benefit beS users?
As described in the [previous subsection](#what-is-the-liquidity-fee), liquid-staking products thrive on scale economics, so — in driving beS adoption forward — the liquidity fee should increase the likely yields of the product. Beyond that big picture goal, the liquidity fee provides a number of possible benefits to users:
* Increased yields for beS liquidity providers on exchanges;
* Increased liquidity for traders buying or selling beS on exchanges;
* Increased yields and liquidity for users of beS lending markets;
* Increased yields for Beefy users using beS products on Beefy;
* Increased yields for Beefy users participating in beS-related boosts on Beefy;
* A greater range of liquidity and integrations for beS;
* Increased price stability through greater depth and diversity of liquidity;
* A route for instant entry or exit without delay through exchanges; and
* Increased yields on beS through growing adoption of the token.
## Do I need to buy wS in order to access beS?
Not necessarily. Beefy is partnering with various exchanges across the ecosystem to add liquidity for beS. This means users will be able to go to a variety of major exchanges or aggregators and swap from the tokens of their choosing into beS. However, this does not increase the supply beS, but rather takes advantage of existing liquidity. There may also be price differentials between the market price of beS on exchanges and the underlying value of beS in terms of the wS tokens the user is entitled to, so it's always best to verify the market value before swapping.
## Is beS pegged to wS?
Not in a strict sense, no. beS can always be redeemed for more wS, but with the 14-day withdrawal. Beyond this mechanism, other means of accessing beS are subject to market forces, and price may vary substantially depending on factors outside of Beefy's control. As such, there is the possibility for arbitrage, either where beS is overpriced (in which case more wS can be staked to sell beS), or where beS is underpriced (in which case beS can be purchased and withdrawn to wS for a profit).
## Is beS Audited?
Yes! Electisec delivered a thorough audit of the beS code base in late March/early April 2025. Their findings are published in their [beS audit report](https://github.com/beefyfinance/beefy-audits/blob/master/2025-04-05-Beefy-Electisec-beS-Audit.pdf).
## Where can I find the beS contracts?
The addresses and links for the deployed contracts on Sonic are in the table below:
# beQI
Beefy-escrowed Qi
## What is Qi?
Qi is the native token of Mai Finance, a collateralised debt protocol native to the Polygon blockchain. Mai Finance is governed by QiDao, for which Qi is the governance token. Qi can also be used to participate in a share of the protocol's revenues. Qi has a fixed supply and decaying emissions model.
Users can stake Qi to earn eQi and receive an up to 4x boosted share of protocol revenues and governance voting power.
## What is beQI?
beQI is a Beefy-escrowed version of Qi staked to earn eQi, to boost the proportion of Mai Finance protocol revenues that Beefy earns and to participate in vault incentive gauge votes.
The token is fully backed 1:1 by Qi and can be redeemed for Qi held in reserve. This reserve fills up when new users deposit (if below the required reserve amount at the time), or the amount of reserve required gradually decreases as the contract's eQi gradually decreases and unlocks.
## How does one get beQI?
You can mint beQI on the beQI [vault](https://app.beefy.finance/#/vault/beefy-beqi) or [earnings pools](https://app.beefy.finance/#/vault/beefy-beqi-earnings) pages at a 1:1 ratio. There is no incentivised liquidty for beQI, instead there will be a withdrawal reserve.
## How does beQI work?
When you mint beQI, the contract will immediately try to stake and lock the deposited Qi into eQi, subject to the required reserve being maintained.
If the contract's Qi reserves at the time of minting exceed the required reserve amount (which is currently 20% of the contract's eQi), the contract can stake any excess Qi into eQi. If the Qi reserves are under the required reserve amount, then the deposited Qi will be added to the reserve to cover the current shortfall.
Once the contract's Qi is staked and locked into eQi, it receives two benefits: (1) boosted weekly protocol revenue rewards; and (2) voting rights in QiDao's governance and vault incentives gauge votes. Beefy's approach to voting for beQI is detailed [below](#can-i-vote-with-beqi).
Mai Finance protocol revenues are paid out weekly, and currently include 100% of all farming rewards from the protocol's deposit fee revenue, which is used to farm Qi-MATIC, together with 30% of the debt repayment fees for all collateral types (plus a 25% weekly bonus). Individual rewards can be boosted by up to 4x where a user has the maximum amount of eQi (i.e. has locked their Qi for 4 years).
As the beQI contract perpetually re-locks its Qi deposits, it always strives for the maximum amount of boost. All of our received rewards are then distributed to our Beefy beQI vault and earnings pool for the benefit of beQI holders.
## How can I earn with my beQI?
Once you're holding beQI, there are a couple of available options. You can either:
1. Stake it in the beQI vault to earn more beQI; or
2. Stake it in the beQI earnings pool to earn Qi.
As eQi boosted protocol revenue is paid out in Qi tokens, these can be paid back to beQI holders either directly in Qi (through the earnings pool), or by compounding beQI (through the vault) by minting more beQI with the Qi rewards.
## How does the beQI strategy work?
## But what about fees?
Beefy strives to maintain some of the lowest yield-optimizing fees, and charges standard fees on its beQI vaults.
## How does beQI keep its peg?
There's no liquidity provided for beQI, so it will always be at 1:1 with Qi. Users can burn beQI for Qi while the reserve lasts without affecting the peg.
## How can I get my Qi back?
Whilst there are Qi tokens available in the reserve, you will be able to burn your existing beQI tokens (up to the amount of the reserve) to receive back an equivalent amount of Qi.
Where the reserve does not hold sufficient Qi tokens to facilitate the requested withdrawal, you will only be able to withdraw up to the amount of the reserve. Unfortunately, eQi locking also does not include an emergency release mechanism, so in this scenario holders will need to wait until the reserve is replenished.
As the required reserve amount is tied to the amount of eQi held by the contract, and all eQi balances reduce over time as the time left until unlock decreases, the amount of reserve required will also naturally decrease over time until the eQi lock is extended. As such, and assuming that no further Qi deposits are made to replenish the reserve, the required reserve amount will gradually decrease over time, meaning the amount of Qi available to withdraw will increase constantly.
## Can I vote with beQI?
Not at the moment. All Qi voting power is currently used by Beefy to vote in the weekly vault incentives gauge. Votes will typically be directed to Beefy collateral types (e.g. mooBIFI Fantom), which rewards our users who deposit their Beefy assets as collateral on Mai Finance.
Where our preferred collateral types are unlikely to qualify for the incentives gauge, we may also choose to accept bribes from external parties. The proceeds of all bribes are then distributed directly to our beQI holders. If you are interested in proposing a bribe to Beefy, please reach out to the Core team on Discord, Telegram or Twitter to find out more.
# Deprecated Products
Last Update: April 2025
This section contains legacy documentation for Beefy-escrowed products that have been subsequently retired or deprecated.
In many cases, it is neither feasible nor appropriate to fully disable token-based products from on-chain operations. However, continued support within Beefy’s protocol, infrastructure, and user interface may become economically impractical. In such instances, Beefy discontinues active support and maintenance of these products.
While no longer supported, some of these products may still be accessible through alternative means—for example, through residual liquidity on decentralized exchanges.
{% hint style="warning" %}
It is not advisable to transact with any deprecated Beefy-escrowed products outside of the Beefy UI, and doing so can lead to permanent and undesirable loss of capital. Always research our products before investing, and raise questions or concerns through Beefy's public spaces and social media channels.
{% endhint %}
## Contents
This section contains documentation for the following Beefy-escrowed products:
{% content-ref url="/pages/cNuNeh5705Sxuv9VDSJh" %}
[beFTM](/beefy-products/beefy-escrowed-tokens/deprecated-products/beftm)
{% endcontent-ref %}
{% content-ref url="/pages/dTne9JFmyOE2KFGKZU1r" %}
[binSPIRIT](/beefy-products/beefy-escrowed-tokens/deprecated-products/binspirit)
{% endcontent-ref %}
{% content-ref url="/pages/I2cw9eSbRMhz7aTsADFH" %}
[beJOE](/beefy-products/beefy-escrowed-tokens/deprecated-products/bejoe)
{% endcontent-ref %}
{% content-ref url="/pages/fXuSM1X1RdKcNg4YqJlJ" %}
[beVELO](/beefy-products/beefy-escrowed-tokens/deprecated-products/bevelo)
{% endcontent-ref %}
{% content-ref url="/pages/6t7ZjYixcgL6GIqAbI4D" %}
[beOPX](/beefy-products/beefy-escrowed-tokens/deprecated-products/beopx)
{% endcontent-ref %}
# beFTM
Last Update: April 2024
{% hint style="warning" %}
Note that following the passage of [\[BIP-67\]](https://snapshot.org/#/beefydao.eth/proposal/0x895f2b854b98eef94acf5e2f77bea7e2e9bdabde7167b9de280f33f872a2bc1e), the current version of beFTM will be gradually deprecated with all existing FTM deposited to be unlocked by 3 April 2024. Beefy's developer team is exploring a replacement V2 beFTM, to be released closer to the end of the deprecation period.
{% endhint %}
## What is beFTM?
beFTM is short for Beefy-escrowed Fantom. beFTM gives stakers access to maximized Validator Node rewards that typically aren’t available to the individual investor without locking FTM for 1 year. The beFTM token is 1:1 backed by FTM and can be staked on the Beefy platform and in farms on major DEXes.
## How does one get beFTM?
To get your hands on beFTM, users must first deposit their FTM in the Beefy Delegator Vault. The FTM is then used to buy beFTM from a liquidity pool or minted 1:1 depending on which is most profitable for the user.
beFTM can also be manually purchased on many DEXes such as Solidly, BeethovenX, SpiritSwap, and SpookySwap. One might need the beFTM contract address for trading: [0x7381eD41F6dE418DdE5e84B55590422a57917886](https://ftmscan.com/token/0x7381eD41F6dE418DdE5e84B55590422a57917886)
## How does beFTM delegation work?
The collective pool of FTM is delegated to [Beefy’s Validator Node](https://ftmscan.com/address/0xe97a5292248c2647466222dc58563046b3e34b18#validatorinfo) and perpetually locked as long as possible (51 weeks) to earn maximum validator rewards. We supply 1/15 of the deposit to our validator so we never hit the delegation limit. By staking our users’ FTM together, the Cowmoonity enjoys a much higher rate of return.
## beFTM Earnings Pool and beFTM Vault
After depositing FTM to get beFTM, the FTM gets delegated to Beefy's Validator Node. The validator stakes the FTM tokens to help secure the Fantom network, and earns WFTM tokens as a reward. The WFTM rewards will be collected and distributed daily to the beFTM Earnings Pool where users can stake beFTM to earn WFTM. The beFTM Vault deposits the beFTM in the Earnings Pool and uses the share of the vault to buyback beFTM with the WFTM rewards. By doing so, the beFTM vault adds a continuous buying pressure to the beFTM token price.
## What can I do with beFTM?
* Deposit beFTM in the beFTM Vault for compounded interest in the form of more beFTM;
* Deposit beFTM in the WFTM Earnings Pool for simple interest with WFTM rewards;
* Stake in beFTM-FTM liquidity pools on all the major DEXes on Fantom.
## How does the beFTM strategy work?
## How does beFTM keep its peg?
{% hint style="info" %}
While beFTM is backed 1 to 1 by FTM, it is not designed to keep a 1 to 1 peg with FTM: ultimately its price determined by the market.
{% endhint %}
There are several mechanisms in place to help beFTM maintain peg against FTM. First of all, Beefy's Smart Minter will not issue new beFTM tokens when the price of beFTM is below the price of FTM, it will instead buy beFTM from a liquidity pool helping to restore the peg and giving the user a more profitable option. Secondly, the beFTM vault adds a continuous buying pressure to the beFTM token price. Lastly, arbitrageurs will either buy and sell beFTM depending on the peg.
In a hypothetical situation where the peg crashes to 0 with no signs of recovery, Beefy's Validator Node can be paused, forfeiting all pending rewards, and after waiting 1 full week everyone will be able to redeem their beFTM for the delegated FTM.
## V1 Deprecation
In late March 2023, the Beefy Core team proposed the deprecation of the existing version of beFTM, to allow all FTM deposited in the current version to be unlocked and an improved V2 to be developed and deployed. The [\[BIP-67\] proposal](https://snapshot.org/#/beefydao.eth/proposal/0x895f2b854b98eef94acf5e2f77bea7e2e9bdabde7167b9de280f33f872a2bc1e) called to initiate an unlock on 3 April 2023, with the full unlock being completed by 3 April 2024. The proposal also calls for a V2 to be developed closer to the time in include better redemption capabilities. The proposal passed with a 99% margin on 2 April 2023.
# binSPIRIT
Last Update: April 2025
{% hint style="warning" %}
Note that with the deprecation of Fantom blockchain (and replacement with Sonic), support for Beefy's binSPIRIT token has been deprecated from our user interface. The token remains accessible on Fantom, but with the wider deprecation of the chain, its ongoing operations will eventually cease.
{% endhint %}
## What is SPIRIT?
SPIRIT is the native token of SpiritSwap, a decentralized exchange native to the Fantom blockchain. It rewards holders with a share of the platform's revenues and also acts as a governance token. SPIRIT has a fixed supply and decaying emissions model.
Users can stake and lock their SPIRIT tokens on SpiritSwap for a fixed period between 1 week and 4 years, to receive a proportional amount of inSPIRIT. inSPIRIT holders receive a range of benefits, including: (1) a proportion of the protocol's revenues (which vary week by week, but have been as high as 80% APR); (2) voting rights in the protocol's governance and vault incentives gauge; (3) up to 2.5x boosted rewards from SpiritSwap farms, depending on the balance of inSPIRIT held by the user; and (4) access to bribes for voting for third party-incentivised gauges.
inSPIRIT is non-transferrable and the amount held by a given user decreases steadily to 0 when the lock is over. Users also cannot liquidate or transfer their locked SPIRIT positions until the end of the time lock.
## What is binSPIRIT?
binSPIRIT is the Beefy-escrowed version of inSPIRIT which is staked to accumulate inSPIRIT. Holders of binSPIRIT receive each of the benefits of inSPIRIT detailed above, but without being constrained by the SpiritSwap lock mechanism.
The token is fully backed 1:1 by SPIRIT, though is perpetually locked for inSPIRIT, so cannot be withdrawn back to SPIRIT. However, binSPIRIT is a transferrable ERC-20 token, so can be swapped for other tokens on decentralised exchanges, allowing holders to exit their positions at any time.
## How does one get binSPIRIT?
Users can mint binSPIRIT on the [binSPIRIT vault page](https://app.beefy.finance/#/vault/beefy-binspirit) at a 1:1 ratio. If it is more profitable to buy binSPIRIT, then Beefy's Smart Minter will do exactly that, yielding the user more binSPIRIT for their SPIRIT. Users can also get binSPIRIT by buying on a decentralised exchange.
## How does binSPIRIT work?
Beefy uses the deposited SPIRIT to accumulate as much inSPIRIT as it can by immediately and perpetually locking all deposits on SpiritSwap for the longest available period. It then puts the accumulated inSPIRIT to use to claim SpiritSwap protocol revenues, boost its SpiritSwap vaults and vote for SpiritSwap incentive emissions.
All protocol revenues are paid out in SPIRIT, which is automatically claimed by Beefy and then returned to the binSPIRIT vault, either by minting more binSPIRIT (if binSPIRIT is over peg) or by purchasing binSPIRIT on a decentralised exchange (if under peg) and then in either case redepositing the binSPIRIT into the vault.
All deposits, withdrawals and harvest rewards from Beefy's boosted SpiritSwap vaults are routed through the binSPIRIT contract, so that they may receive the benefit of its inSPIRIT boost. By keeping all of the accumulated inSPIRIT in one contract, and running all the vaults through that contract, binSPIRIT ensures that each vault receives the maximum available boost. All boosted rewards are retained by the individual Beefy vaults.
The binSPIRIT contract also submits votes on Beefy's behalf for SpiritSwap governance proposals and vault incentive gauges. binSPIRIT holders are empowered to [vote](#can-i-vote-with-binspirit) on gauges, as described furhter below.
For further details of binSPIRIT's specific functionality and methods, see the description of its main [GaugeStaker smart contract](/developer-documentation/other-beefy-contracts/gaugestaker-contract).
## How can I earn with my binSPIRIT?
Once you're holding binSPIRIT, there are a few available options. You can either:
1. Stake it in the Beefy binSPIRIT vault to earn protocol revenue, which is autocompounded into more binSPIRIT;
2. Deposit it into a binSPIRIT liquidity pool with a decentralised exchange (e.g. SpiritSwap, Solidly) to earn trading fees (and potentially rewards); or
3. Deposit it into the SPIRIT-binSPIRIT LP on SpiritSwap, and stake in the [Beefy SPIRIT-binSPIRIT LP vault](https://app.beefy.finance/#/vault/spirit-binspirit-spirit) to earn autocompounded trading fees and rewards.
## But what about fees?
Beefy strives to maintain some of the lowest yield-optimizing fees, and charges standard fees on its binSPIRIT vaults. No Beefy fees are charged for using Beefy's Smart Minter to convert SPIRIT into binSPIRIT.
## How does binSPIRIT keep its peg?
Should a user want to liquidate their position they will be able to trade binSPIRIT on an exchange. By contrast to inSPIRIT, users are never locked in and can exit their position at any time. This also means that binSPIRIT may not always be pegged to SPIRIT, but aims to maintain a loose peg.
If binSPIRIT goes under peg, then the contract will use the claimed SpiritSwap protocol revenues to buy back more binSPIRIT. This increases the size of each binSPIRIT holder's proportional share of deposited SPIRIT, leaving them with more than they would have achieved from locking the same SPIRIT directly on SpiritSwap.
If binSPIRIT goes over peg, then the contract will use protocol revenues to mint more binSPIRIT at at a profit.
## Can I vote with binSPIRIT?
No. Though Beefy had previously set up a binSPIRIT voting system and a [dedicated Snapshot page](https://snapshot.org/#/binspirit.eth), the move to SpiritSwap V2 has allowed Beefy to automate the process of bribing to help us obtain the highest return for holders. Beefy then returns all bribe earnings directly to the binSPIRIT vaults, facilitating high returns with minimal effort.
Though Beefy has automated the process, we are still open to receiving direct offers for binSPIRIT bribes. Please reach out to the Core team on Discord, Telegram or Twitter to find out more.
# beJOE
Last Update: January 2023
{% hint style="warning" %}
beJOE was deprecated on the 6th of January, 2023. All beJOE can be burned 1 to 1 for JOE, and Beefy no longer takes any fees.
{% endhint %}
## What is JOE?
JOE is the native token of Trader Joe, a decentralized exchange native to the Avalanche blockchain. It rewards holders with a share of the platform’s revenues and also acts as a governance token. JOE has a fixed supply and decaying emissions model.
Users can stake JOE to earn veJOE and receive boosted JOE rewards in selected Trader Joe Farms and governance voting power.
## What is beJOE?
beJOE is a Beefy-escrowed version of JOE staked to earn veJOE, maximizing emissions on boosted Beefy vaults. beJOE stakers earn 5% of emissions from those boosted vaults.
The token is fully backed 1:1 by JOE and can be redeemed for JOE held in reserve. This reserve only fills up when a new user deposits.
## How does one get beJOE?
You can mint beJOE on the beJOE [vault](https://app.beefy.finance/#/vault/beefy-beJoe) or [earnings pool](https://app.beefy.finance/#/vault/beefy-beJoe-earnings) pages at a 1:1 ratio. There is no incentivised liquidity for beJOE, instead there will be a withdrawal reserve.
## How does beJOE work?
When you mint beJOE, the contract will immediately try to stake the deposited JOE into veJOE, subject to two conditions: (1) the required reserve must be maintained; and (2) the staking must trigger a “Speed Up" bonus.
If the contract's JOE reserves at the time of minting exceed the required reserve amount (which is currently 20% of the contract's JOE already staked into veJOE), the contract can stake any excess JOE into veJOE. If the JOE reserves are under the required reserve amount, then the deposited JOE will be added to the reserve to cover the current shortfall.
The “Speed Up" bonus on Trader Joe doubles the rate of veJOE accruals for 14 days after JOE is staked, provided that the amount of JOE staked adds an additional 5% (or more) on top of the total amount of JOE already staked into veJOE . The contract therefore checks before staking whether the available balance (including both the deposit and any pre-existing excess over the required reserve) would meet or exceed the 5% threshold, and will only stake the available balance if it does. Otherwise, it waits for further JOE deposits to increase the available balance before staking.
Once the contract's JOE is staked into veJOE, it will automatically accrue veJOE rewards. veJOE provides 2 benefits: (1) boosted rewards on certain Trader Joe farms; and (2) (future) voting rights in Trader Joe governance. The amount of each benefit is proportional to the balance of veJOE held by the contract, so the aim is to accrue as much veJOE as possible.
Though veJOE rewards accrue constantly on the contract's staked JOE, the rewards must be harvested to be added to the contract's balance of veJOE. Rewards are automatically harvested whenever JOE is staked into veJOE, and otherwise manually harvested by the contract when new beJOE is minted but the conditions for staking are not met.
## How can I earn with my beJOE?
Once you’re holding beJOE, there are a couple of available options. You can either:
1. Stake it in the beJOE vault to earn more beJOE; or
2. Stake it in the beJOE earnings pool to earn JOE.
In every Beefy vault for a Trader Joe farm which is boosted for veJOE holders, 5% of the value of every harvest will be diverted to the beJOE reward pool to be paid out to beJOE holders. This reflects the value added by the beJOE contract, which gathers the veJOE needed to boost these vaults.
As the boosted rewards on Trader Joe farms are paid out in JOE, these can be paid back to beJOE holders either directly in JOE (through the earnings pool), or by compounding beJOE (through the vault) by minting more beJOE with the JOE rewards.
## How does the beJOE strategy work?
## But what about fees?
Beefy strives to maintain some of the lowest yield-optimizing fees, and charges standard fees on its beJOE vaults, plus an additional 5% delivered directly to beJOE stakers.
## How does beJOE keep its peg?
There's no liquidity provided for beJOE, so it will always be at 1:1 with JOE. Users can burn beJOE for JOE while the reserve lasts. This reserve only fills up when a new user deposits.
In a last-resort scenario, all locked JOE in beJOE can be unlocked and released to the reserve. Beefy's competitors do not have this. However this would also end the boosts available for Beefy vaults and the rewards streamed to the beJOE reward pool, so is unlikely to be triggered.
## Can I vote with beJOE?
Not yet, but beJOE implements EIP-1271 (signature validation for contracts), so future governance/bribes with TraderJoe can be organised.
# beVELO
Last Update: August 2023
{% hint style="warning" %}
From June 2023, Velodrome has [migrated](#whats-this-i-hear-about-migration) to its V2 protocol, and $VELO V1 has been retired in favour of $VELO V2. To continuing earning from $beVELO, all users are advised to redeposit in the [beVELO Migration Pool](https://app.beefy.com/vault/beefy-bevelo-v2-earnings), where earnings are paid out in $VELO V2.
{% endhint %}
## What is $VELO?
$VELO is the native token of Velodrome Finance, a decentralised trading and liquidity marketplace native to the Optimism blockchain. It rewards holders with a share of the platform's revenues and also acts as a governance token for its weekly pool incentives gauge. $VELO has a fixed supply and decaying emissions model.
Users can stake and lock their $VELO tokens on Velodrome for a fixed period between 1 week and 4 years, to receive a vote escrow NFT ("**veNFT**"), which is used to record the amount of veVELO held by the user. Accumulating veVELO provides users with three benefits: (1) a share of the trading fees from swaps using the platform's liquidity pools; (2) the ability to direct $VELO emissions distributed to platform liquidity providers; and (3) the opportunity to earn bribes from external parties by voting for their incentivised liquidity pools. $VELO staking can can be done through Velodrome's [web app](https://velodrome.finance/).
veVELO is non-transferrable and the amount held by a given user decreases steadily to zero as the lock period moves towards its completion. Users also cannot liquidate or transfer their locked $VELO positions until the end of the time lock.
In June 2023, Velodrome [migrated](#whats-this-i-hear-about-migration) from $VELO V1 to $VELO V2.
## What is beVELO?
$beVELO is a Beefy-escrowed version of $VELO V1, staked for veVELO to take advantage of the various benefits offered to Velodrome stakers.
The token is fully backed 1:1 by $VELO V1, which can be redeemed where tokens are available in the reserve. This reserve fills up on several circumstances:
1. when new users deposit $VELO into $beVELO, if below the required reserve amount at the time; and
2. if the contract's staked $VELO V1 is left to gradually unlock.
beVELO is designed to capture the maximum possible rewards and benefits from Velodrome's vote escrow tokenomics.
## How does one get $beVELO?
You can mint $beVELO on the $beVELO [vault page](https://app.beefy.finance/vault/beefy-bevelo) at a 1:1 ratio. There is also a Velodrome [liquidity pool](https://optimistic.etherscan.io/address/0xC6c7B143295b2920DA41369e9627245FaB8c1CcE) for swapping between $beVELO and $VELO V1, though in light of the [migration](#whats-this-i-hear-about-migration) to $VELO V2, there is limited liquidity and a risk of high slippage when using this pool.
## How does $beVELO work?
When you mint $beVELO, the contract will immediately try to stake and lock the deposited $VELO into veVELO, subject to the required reserve being maintained.
If the contract's $VELO reserves at the time of minting exceed the required reserve amount (which is currently 20% of the contract's veVELO), the contract can stake any excess $VELO into veVELO. If the $VELO reserves are under the required reserve amount, then the deposited $VELO will be added to the reserve to cover the current shortfall.
Once the contract's $VELO is staked and locked into veVELO, it receives $VELO V2 rewards paid out by Velodrome's protocol. As the $beVELO contract perpetually re-locks its $VELO V1 deposits, it always strives for the maximum amount of voting power and benefits. $VELO V2 rewards are regularly harvested and returned to holders in the [beVELO Migration Pool](https://app.beefy.com/vault/beefy-bevelo-v2-earningshttps://app.beefy.com/vault/beefy-bevelo-v2-earnings).
## How can I earn with my $beVELO?
Once you're holding $beVELO, you can stake it in our [beVELO Migration Pool](https://app.beefy.com/vault/beefy-bevelo-v2-earnings) to earn $VELO V2. $VELO V2 rewards are paid out directly rather than autocompounded as the underlying $VELO V1 has been retired.
$beVELO can be deposited into our beVELO Migration Pool to earn $VELO V2
## But what about fees?
Beefy strives to maintain some of the lowest yield-optimizing fees, and charges standard fees on its $beVELO vault.
## Can I vote with my $beVELO?
No. All $VELO voting power will be used by Beefy to vote in the weekly liquidity pool incentives gauge.
Votes will typically be directed either to the liquidity pools offering the most in trading fees and bribes, or to the liquidity pools which support our $BIFI token (e.g. BIFI-OP LP). Voting on Velodrome's incentivised liquidity pools takes place on its [web app](https://app.velodrome.finance/vote).
If you are interested in proposing a bribe to Beefy, please reach out to the Core team on Discord, Telegram or Twitter to find out more.
## What's this I hear about migration?
In June 2023, Velodrome retired their original $VELO V1 token as part of the upgrade to their V2 web app, and adopted the new $VELO V2, which provides a range of additional features. As a result, Beefy has retired and redeployed many of the existing Beefy Velodrome vaults. Users can swap their V1 tokens for V2 at a 1:1 ratio on the [Velodrome app](https://velodrome.finance/).
For $beVELO, the new protocol design does not include functionality for $VELO V1 liquid-staking derivatives, meaning the product cannot be upgraded. Instead, Beefy has implemented a [$beVELO Migration Pool](https://app.beefy.com/vault/beefy-bevelo-v2-earnings), which allows users to get the benefit of the its $VELO V1 voting power, and rewards paid out in $VELO V2. All users are urged to redeposit their $beVELO into the Migration Pool to continue earning following the migration.
# beOPX
Last Update: April 2025
{% hint style="warning" %}
With the deprecation of the OPX protocol, beOPX is no longer supported by the Beefy interface. Though the token remains accessible on OP Mainnet, with the wider deprecation of the project, its ongoing operations will eventually cease, and it is not advisable to purchase OPX or beOPX.
{% endhint %}
## What is OPX?
OPX is the native token of OPX Finance, a decentralised spot and perpetual exchange native to the Optimism blockchain. The OPX token is used to reward holders with a share of protocol revenues, whilst providing voting rights for use in protocol governance. OPX has adopted a fixed token supply model, though the current OPX token incorporates both minting and burning methods.
OPX offers a novel form of vote escrow tokenomics for its governance and profit share mechanics. This requires holders to stake and lock both their OPX tokens and an OPX NFT with the protocol. For this, holders receive veOPX, which reflects the holder's rights to participate in protocol governance and profits. OPX NFTs can only be obtained from an OPX mystery box (or third party sale) and are minted with a randomised level, which determines the percentage of boost applied to the holder’s veOPX.
The key governance mechanism of veOPX is to decide on the distribution of OPX tokens among: (1) OPX liquidity (OLP) providers; (2) OPX stakers' profit share; (3) OPX protocol-owned liquidity; (4) OPX's developer treasury; (5) OPX's buy back and burn program; and (6) returning profit to DarkCrypto DAO - the creators of OPX. OPX [staking](https://www.opx.finance/#/stake) and [voting](https://www.opx.finance/#/vote) can can be done through OPX's web app.
veOPX is non-transferrable and the amount held by a given user decreases steadily to zero as the lock period moves towards its completion. Users also cannot liquidate or transfer their locked OPX positions until the end of the time lock.
## What is beOPX?
beOPX is a Beefy-escrowed version of OPX staked for veOPX to take advantage of the various benefits offered to OPX stakers. As Beefy holds an OPX NFT of top-tier rarity (level 5), beOPX gives holders access to the maximum boosted profit share, which otherwise is reserved for the lucky few who acquire a similar rare NFT.
The token is fully backed 1:1 with OPX and can be redeemed for OPX held in reserve. This reserve fills up in several circumstances:
1. when new users deposit OPX into beOPX, if below the required reserve amount at the time;
2. when the contract harvests protocol revenues from OPX, if below the required reserve amount at the time; or
3. if the contract's staked OPX is left to gradually unlock.
beOPX is designed to capture the maximum possible rewards and benefits from OPX's vote escrow tokenomics.
## How does one get beOPX?
You can mint beOPX on the beOPX vault page at a 1:1 ratio. There is no incentivised liquidity for beOPX, instead there will be a withdrawal reserve.
## How does beOPX work?
When you mint beOPX, the contract will immediately try to stake and lock the deposited OPX into veOPX, subject to the required reserve being maintained.
If the contract's OPX reserves at the time of minting exceed the required reserve amount (which is currently 30% of the contract's veOPX), the contract can stake any excess OPX into veOPX. If the OPX reserves are under the required reserve amount, then the deposited OPX will be added to the reserve to cover the current shortfall.
Once the contract's OPX is staked and locked into veOPX, it receives a proportion of OPX protocol revenues which have been allocated for stakers, together with the ability to vote on future distributions of protocol revenue among the different available options.
As the beOPX contract perpetually re-locks its OPX deposits, it always strives for the maximum amount of voting power and protocol revenues. Earned revenues are regularly harvested, swapped for beOPX and redeposited to the beOPX vault to autocompound the return for beOPX stakers.
## How can I earn with my beOPX?
Once you're holding beOPX, you can stake it in our beOPX vault to earn more beOPX.
Where our beOPX contract earns protocol revenues by deploying its veOPX on the protocol, those protocol revenues are swapped back to beOPX and redeposited into the beOPX vault to give rise to an autocompounding effect. This maximises the yield for holders above what they could obtain alone from the protocol.
## But what about fees?
Beefy strives to maintain some of the lowest yield-optimizing fees, and charges standard fees on its beOPX vault.
## How does beOPX keep its peg?
There's no liquidity provided for beOPX, so it will always be at 1:1 with OPX. Users can burn beOPX for OPX while the reserve lasts without affecting the peg.
## How can I get my OPX back?
Whilst there are OPX tokens available in the reserve, you will be able to burn your existing beOPX tokens (up to the amount of the reserve) to receive back an equivalent amount of OPX.
Where the reserve does not hold sufficient OPX tokens to facilitate the requested withdrawal, you will only be able to withdraw up to the amount of the reserve. Users can then wait until the next harvest of protocol revenues, which will refill the reserve and allow them to burn their beOPX. Otherwise, OPX's locking mechanism does not include an emergency release mechanism.
As the required reserve amount is tied to the amount of veOPX held by the contract, and all veOPX balances reduce over time as the time left until unlock decreases, the amount of reserve required will also naturally decrease over time until the veOPX lock is extended. As such, and assuming that no further OPX deposits are made to replenish the reserve, the required reserve amount will gradually decrease over time, meaning the amount of OPX available to withdraw will increase constantly.
## Can I vote with my beOPX?
No. All OPX voting power will be used by Beefy to vote in the protocol revenue distribution votes. Voting takes place on OPX's [web app](https://www.opx.finance/#/vote).
# Advanced Vaults
# GMX and GLP
Last Update: November 2022
## What is GMX?
[GMX](https://app.gmx.io/#/trade/?ref=beefy) is a multi-chain decentralized exchange on Arbitrum One and Avalanche, letting you easily trade perpetual futures. On the GMX DEX, you can trade BTC, ETH, AVAX, LINK, and UNI with up to 30x leverage from your self-custodial crypto wallet.
As a trader, you enter and exit your positions with zero price impact, while profiting from minimal spreads and deep liquidity. Reliable price data is realized by aggregating price feeds, so users also benefit from lowered liquidation risks.
## What is GLP?
GLP is a token minted to liquidity providers on GMX. GLP represents an index of assets, used for leverage trading and swaps on the GMX platform. You can mint it using any of the index assets and burn it to redeem any of the index assets. The cost of minting and redeeming is calculated based on:
*(the total worth of assets in the index including profits and losses of open positions) / (GLP supply)*
After minting GLP, it’s automatically staked to earn escrowed GMX (esGMX, an escrowed version of GMX’s utility and governance token), multiplier points, and ETH or AVAX rewards depending on the network.
## How does Beefy's GLP strategy work?
Beefy is creating two new Vaults, each one taking GLP deposits on either Arbitrum or Avalanche. To mint GLP, you’ll have to deposit an asset contained in the GLP index on GMX as outlined previously. GLP is not bridgeable between Arbitrum and Avalanche.
The strategy works as follows:
1. Users stake GLP in one of the two Beefy Vaults: [The Arbitrum GLP Vault](https://app.beefy.finance/vault/gmx-arb-glp) and [Avalanche GLP Vault](https://app.beefy.finance/vault/gmx-avax-glp).
2. Beefy claims and stakes all the earned esGMX and multiplier points.
3. The earned esGMX is never vested but instead used to boost earnings for more native tokens.
4. The earned multiplier points also boost earnings for more native tokens.
5. Beefy claims fees and mints additional GLP to also earn more fees.
## What are the benefits of the strategy?
GLP holders provide liquidity for leverage traders and profit when leverage traders make a loss. If leverage traders profit, GLP holders make a loss. In a long-term crab market, these Vaults are essentially a bet against traders while also taking a stable index position.
## The GLP transfer cooldown
There is a 15-minute cooldown between minting and transferring GLP. Depositing GLP to the Beefy Vault will only succeed when the cooldown period on the user’s account has expired. The cooldown also affects withdrawals from the Beefy Vault as every harvest will mint new GLP to the Vault’s strategy address.
Withdrawals will therefore only work 15 minutes after the most recent harvest. This will be displayed on the Vault UI. At the contract level, Beefy has introduced safeguards to prevent withdrawal griefing.
## The Beefy GMX Referral Link
Traders who use our [GMX link](https://app.gmx.io/#/trade/?ref=beefy) will get a 5% discount and grant Beefy treasury addresses a 5% rebate.
# Team & Goals
## When was Beefy launched?
Beefy was born on September 21, 2020, the day our [governance distribution contracts](https://medium.com/beefyfinance/bifi-contracts-are-live-on-mainnet-6080577269d7) went live. Our first set of vaults opened on October 8, 2020.
## How is Beefy organized?
Beefy is a decentralized working hub for people with a vision to come together and build the future of global finance. Smart contract devs, UI, UX, strategists, statisticians, designers, and artists - anyone can join and contribute (no matter your nationality, sex, or views). By investing in Beefy, you are investing in the idea that a group of highly technical individuals can safely, securely and creatively leapfrog the dinosaurs of traditional finance.
## DeFi, anonymity and Beefy
Personalities get in the way of projects, and we believe Beefy speaks for itself. By having a team that operates anonymously, even amongst itself, we can focus on providing the best experience for our users. That’s because we believe the strength of Beefy comes from what we build, which is an opportunity for investors to both automate and maximize the return of investment of their holdings. We urge anyone with concerns that anonymity diminishes credibility to join our Discord community and get a first-hand feeling for the strength and depth of the project.
That being said, Beefy is not fully anonymous. Team members go to conferences and get interviewed, both requiring physical presence. Integrations with large crypto exchanges, like Binance, requires providing personal information.
## How can I get in touch with Beefy?
Our global community managers and team members can be contacted anytime through our official [Telegram](https://t.me/beefyfinance) and [Discord](https://discord.gg/yq8wfHd) channels. We should mention that generally speaking within investment communities there are some bad actors around looking to scam, phish, or maliciously target users. Please double check the validity of whoever you talk to, and remember that no one representing Beefy will ever ask you to provide wallet keys or recovery codes.
# Contributor Compensation
Last Update: February 2023
At the heart of Beefy is our culture of innovation and rapid development. From Day 1, Beefy's contributors have worked tirelessly to produce, distribute and iterate on products at lightning speed, both with our own work and in collaborating with the wider DeFi community.
Effective compensation and rewards are essential to building this culture, in order to continue attracting and developing talent and growing the DAO. In the spirit of openness and transparency, this page explains how we at Beefy think about compensation, and our initiatives to motivate engagement and growth.
{% hint style="warning" %}
Note that access to the archived Beefy voting site is available at . The archived site requires users to connect their wallet to both the site and the BSC Mainnet to display historic proposals. The current voting site is available live at .
{% endhint %}
## Token Distributions
At Beefy, we pride ourselves on our simple but highly effective tokenomics design, which avoids relying on governance tokens as a means of effective compensation. As explained in the [Tokenomics & Governance section](broken://pages/-M_6SqdtoTuOnFJZKL_Y), our governance token - BIFI - has a fixed supply capped at only 80,000 tokens, so no new tokens can be minted to compensate our members. In fact, over 90% of the total BIFI supply was distributed to the cowmoonity in the first 2 months after Beefy went live in September 2020, so the Beefy [Treasury](/dao/treasury) doesn't contain a stockpile of freshly minted BIFI either.
Rather, we prefer to focus on two use cases for BIFI: governance rights and protocol revenue, paid out through our BIFI Maxi and BIFI Earning Pool vaults. We feel these mechanisms encourage holders to cherish their BIFI and share in the protocol's success as owners, rather than investors or speculators.
The consequences of this design on compensation are clear: our Cowmoonity is encouraged to acquire and hold BIFI for themselves to participate in our success, but we have a strong preference for any payments to be made in stablecoins, rather than BIFI. Aside from the last remaining emissions from the 10% founder's fund (due to expire in July 2022), Beefy does not use BIFI as a form of compensation.
## Retroactive Payments
Given that the BIFI token wasn't designed for payments and compensation, the default method for compensating individual contributions has historically been retroactive payment proposals. Cowmoonity members who have found ways to bring value to Beefy are free to get stuck in and prove themselves useful, and instances of good work (if made known) will be rewarded.
Contributors are able (and encouraged) to submit "Requests for Funds" or "Retroactive Reward" proposals on Beefy's Snapshot page, for deliberation by the Cowmoonity. Proposals can include a range of options for different levels of rewards, or just a simple fixed amount. Proposers are encouraged to give details of the work they've done, or make themselves available for questions in the #🗣-proposal-discussion channel on the Beefy Discord.
In the early months of Beefy's development, retroactive rewards were an effective means of compensating the cowmoonity's efforts. Though our approach to compensation has advanced since then, today they continue on as a useful way to introduce newer or lesser known contributors to the cowmoonity, and compensate individuals for support work that might be difficult to value.
## Developer Incentives
By contrast, product development work (such as building new Beefy vaults) is far easier to value by measuring the profits the products generate. One-time payments are therefore clearly an inferior form of compensation for product development, as we can't know the value of future profits successful products will produce. Similarly, though we believe that holding BIFI over time will also return the output of our developers' hard work to the cowmoonity, we recognise that this does not incentivise developers to participate over and above ordinary BIFI holders.
In recognition of these issues, and the value of incentivising product development, Beefy therefore offers developers a 0.5% share of all harvests for any vaults they successfully develop and deploy (as part of the performance fee structure). Anyone is welcome to try their hand at becoming a Strategist and developing their own vaults using Beefy's open source code, and our nifty [guide](https://github.com/beefyfinance/beefy-contracts/blob/master/tutorials/deploy-pancakeswap-vault.md#setting-up-a-development-environment).
A similar incentives problem also arises for the maintainers of our codebase , as cowmoonity-endorsed compensation will likely always undervalue a critical bug fix (particularly when compared to the reward the fixer could have received by exploiting the bug for theft or ransom). To compensate these contributions, we have also launched an additional [bug bounty program](https://immunefi.com/bounty/beefyfinance/) with Immunefi - a crypto bug bounty platform for whitehat hackers. Successful claimants can receive up to $75,000 for exposing significant exploit, attack or theft opportunities.
## Reoccurring Payments
By August 2021, Beefy's development team had grown to over 20 active contributors covering a range of functions, including smart contracts, UI/frontend, backend/APIs, data engineering, maintainers, DevOps and security. Many of these functions weren't captured by any of the existing developer incentives, and many devs had contributed months of labour without reward or compensation. To address this, Beefy founder Sirbeefalot considered a range of measures to further support and incentivise development and innovation in a sustainable manner.
The first major change was a move to a more holistic rewards framework for the entire dev team. Sirbeefalot devised a new [proposal](https://vote-archive.beefy.finance/#/beefy/proposal/Qman1BHs6Po497hf14pBXhC3AxTov3nHdmnMG6H2EcESV6) format in August 2021, which required existing devs to provide details of all of their unpaid contributions in recent months, together with estimates of hours worked and the complexity of their tasks. These notes were published to the DAO, and a budget allocation was proposed, which rewarded each dev with a proportion of the total payment aligning with their individual contributions. On 24 August 2021, 99.82% of the DAO voted to award the highest reward payment of $150,000 to the dev team, demonstrating the cowmoonity's strong support of the change.
Though grouping developer compensation together was a clear step forward, the process of gathering and analysing unpaid contributions was cumbersome and inconsistent. Following a re-organisation of leadership roles in September 2021, a further [proposal](https://vote-archive.beefy.finance/#/beefy/proposal/QmVjSv8e7ApJ9wYggxoLkJLNywZ8ru3XNnaNUxErY8LVsp) was put forward by Weso in November 2021, proposing to move to reoccurring monthly payments for defined roles across the DAO (both developers and other contributors). In an accompanying forum post, Weso explained the different core contributor roles, and proposed that the DAO would need to regularly re-approve the reoccurring payments. He also suggested that the DAO should retain authority to remove roles and amend or remove proposed payments. On 8 November 2021, the cowmoonity approved Weso's proposal with a consensus of 97.69%.
Since that time, reoccurring contributor pay requests have been repeatedly authorised by DAO votes. The full list to date is:
## BeefyGrants
The second limb of Sirbeefalot's efforts to incentivise development was the introduction of the BeefyGrants system. In a [paper](https://docs.google.com/document/d/1hBnQcbxkRvhmHASqivI3g8rBS_4m4mmTaT_jW4VjE7c/edit) and blog post introducing the idea, Sirbeefalot explained that the system would be aimed at giving direction to Beefy's development efforts, creating a virtuous cycle of fund allocation, and fairly rewarding community members for their contributions.
Since that time, a range of BeefyGrants and other initiatives have received DAO support and funding, leading to a range of unique and exciting Cowmoonity-led initiatives. As such, our contributors are encouraged to considering applying for larger-scale grants and funding arrangements to support their ideas for new products and initiative.
# Governance
Last Update: September 2023
Beefy is run as a decentralised autonomous organisation (DAO), meaning it is controlled and directed by a decentralised network of contributors and community members, who enable Beefy to function on its own. This page outlines how the governance process behind our DAO works, and how you can get involved.
## How is Beefy governed?
As a decentralised organisation, Beefy is proudly governed by our $BIFI tokenholders. This includes our founders, Core contributors and the wider Cowmoonity, as well as some external holders. Most major decisions that Beefy takes are put to and voted on by our $BIFI holders, including how our fees are set, how the protocol and its contributors are funded, how we market Beefy and what direction we should take on certain decisions. Think of our $BIFI holders as members of the Beefy legislature.
The key mechanism for this is governance voting, which is undertaken through our [Snapshot page](https://vote.beefy.finance/). $BIFI holders are entitled to raise proposals (if they hold at least 1 $BIFI) and vote on them. Discussion of all proposals is actively encouraged on our social media channels. In particular, we would encourage you to head to the #🏛-proposals and #🗣-proposal-discussion channels on the [Beefy Discord](https://discord.gg/yq8wfHd) server. In the threads for the #🏛-proposals channel, you'll find a dedicated space for discussion of individual proposals, or #🗣-proposal-discussion serves as a more general forum.
In addition, the day-to-day operations of Beefy are governed by our Core contributor team, who take the role of the executive wing, and are tasked with carrying out the will of our BIFI holders. As with any growing organisation, it's impossible to run every decision through formal governance, so our Core team have been delegated the necessary authority to look after the protocol. That said, any area of Core's decision-making can instead be raised through governance voting, to ensure that they may be held to account.
## **How do I take part in governance?**
By simply holding $BIFI, even if deposited in the BIFI Pool or BIFI Vault, a user earns the right to create proposals and vote in them. Voting sway and power are derived from the $BIFI holdings of the participant. The reasoning behind this follows that those holding more $BIFI are more invested in the project, and therefore have a larger incentive for the platform itself to succeed and prosper.
Beyond voting for yourself, you can also register to participate as a delegate, so others can delegate their voting power to you for inclusion with your own vote. Through this mechanism, trusted voices in the community can leverage their support with a small amount of effort on the part of their supporters. It also allows those short on time to ensure that their $BIFI is participating in governance, without requiring them to engage with every proposal. See below and the [DelegateRegistry Contract](/developer-documentation/third-party-contracts/delegateregistry-contract) page for further details.
You can see proposals and vote on them yourself by heading to [vote.beefy.finance](https://vote.beefy.finance/).
## **How do I vote?**
Voting requires you to hold $BIFI, which can either simply be held in your wallet or deposited in the BIFI Pool or BIFI Vault. You do not need to remove your stake either to vote. Voting power is based directly on the amount of $BIFI each voter holds.
To submit your vote, simply head to to our [Snapshot page](https://vote.beefy.finance/), connect your wallet to Snapshot and then head to an open proposal you wish to vote on. Here you'll find an interface to "Cast your vote" by selecting your preferred option(s) and clicking "Vote". You'll then be required to sign a transaction through your wallet to formally submit your vote.
## How do I delegate my vote?
You can delegate your vote on Ethereum by interacting directly with [the DelegateRegistry contract](https://bscscan.com/address/0x469788fE6E9E9681C6ebF3bF78e7Fd26Fc015446). A full tutorial of how to delegate is available in the [DelegateRegistry Contract](/developer-documentation/third-party-contracts/delegateregistry-contract) page at [DelegateRegistry Contract](/developer-documentation/third-party-contracts/delegateregistry-contract#delegation-walkthrough). Please note that, due to our bespoke Snapshot tooling, you must delegate on Ethereum for your delegation to be effective. Delegations on other chains may register in the relevant DelegateRegistry contract, but will not be recognised by our tooling.
## How do I become a delegate?
If you'd like to represent the Cowmoonity by acting as a delegate for others to direct their voting power to, you can do so by reaching out to us and providing your name and public wallet address. A full list of the current delegates offering to represent your interests is maintained in this [Google sheet](https://docs.google.com/spreadsheets/d/1sJH4jg3eEEJDpbws55qUmzPeLDiDuL_5OAQobSn7m2Y/edit?usp=sharing). We'd recommend that budding delegates seek to provide as much information as they can for the sheet, for the benefit of users who may delegate to them.
## How are votes counted?
For each proposal, a snapshot of the blockchain is taken at the time of posting and used to calculate how many $BIFI tokens are held by each voter. This voting power is locked from the time of posting, so you can't buy more $BIFI to influence a live vote.
Through our Snapshot page, proposals can take a number of different forms, each of which weigh votes slightly differently. The different options include:
* Basic voting - voters can either approve, reject or abstain from the vote, with the majority (absent abstentions) winning the vote.
* Single choice voting - voters can choose one of several choices, with the option with the largest proportion of votes winning.
* Weighted voting - voters can spread their voting power across multiple choices, with the option with the largest proportion of voting power winning.
* Quadratic voting - weighted voting, but with voting power adjusted logarithmically, so that smaller voters have more voting power per token than larger voters. The option with the largest proportion of voting power wins.
* Ranked choice voting - voters can select several options by an order of preference, with votes then counted by eliminating the option with the least highest preference votes, and reallocating those votes to their next highest preference, until only one option remains.
{% hint style="info" %}
Please note that for all Beefy governance votes which include an "abstain" option, a vote to abstain will be interpreted as a vote for the side that has the most votes, when ignoring the abstaining votes. If a quorum is introduced and is met only through the inclusion of abstaining votes, this remains a valid proposal, and the outcome will be accepted.
The Snapshot user interface may recognise the outcome of a vote as "abstain" where abstaining votes are the largest group, though the outcome will in fact be the option with the most votes otherwise. See for example the outcome of the Permissionless 2022 reimbursement proposal below.
{% endhint %}
Where abstain receives the most votes, the outcome with the second most will be adopted.
## What is the quorum for voting?
To ensure that proposals that don't receive much interest aren't passed by default, Snapshot includes an option for a voting quorum, where a proposal needs to receive more than a specified proportion of total available votes in any direction to be considered valid.
No formal quorum has ever been adopted by Beefy, so no quorum has applied to any of our previous governance proposals. However, in some historic proposals, our Snapshot space has included references to the Snapshot quorum in the default user interface, even though these did not in principle apply to the formal proposal. Please note that where any such historic proposal appears to have failed to meet the stated quorum, **it is still considered to have been adopted by the DAO.**
## **How do I create a proposal?**
Proposals can be created if the submitter holds or stakes at least 1 $BIFI. Simply visit and click New Proposal.
Each proposal is made up of a question to pose to the community, along with the option of choices that others can vote on in response to your question. Simply set a start and end date for your proposal and publish it.
## What types of proposals are there?
As our governance process has developed, we have adopted a number of different forms of proposal for different purposes. These include:
* Beefy Improvement Proposals (BIPs) - the default form of proposal, for an issue aimed at improving the protocol in some way.
* This now includes proposals for [reoccurring contributor payments](/dao/contributor-compensation#reoccurring-payments).
* Beefy Signally Proposals (BSPs) - an alternative, non-binding proposal, aimed at establishing consensus amongst $BIFI holders, or demonstrating their opinions/preferences.
* [Requests for Funds / Retroactive Payments](/dao/contributor-compensation#retroactive-payments) - a simple request for funding from the Beefy [Treasury](/dao/treasury) for a particular work stream or contributors. These are typically a form of expense, rather than an investment.
* [Grant Proposals](/dao/contributor-compensation#beefygrants) - a more detailed request for funding from the [Treasury](/dao/treasury), typically relating to a large project that requires significant funding and input, but is aimed at delivering future revenues or cost-savings to Beefy (so is an investment, rather than an expense).
## How do we protect against malicious votes?
It's no secret that open governance brings a range of risks, including malicious votes aimed at hacking the protocol or damaging our Cowmoonity. To protect against this possibility, our Core team actively moderates the governance process, looking to take down any potentially harmful proposals.
This include proposals that are: (1) clearly harmful or malicious; (2) unfair, impossible or fundamentally irrational; (3) don't allow sufficient time to vote; or (4) which lack sufficient clarity or comprehensibility to be executed. It may also include attempts to force through a proposal by changing the voting system or parameters for a failed vote (e.g. moving to quadratic voting to circumvent large $BIFI holders), or leaving too little time for voting.
## Where can I find details of past votes?
Recent votes are stored on the our [Snapshot page](https://vote.beefy.finance/). At the end of 2021, Beefy transitioned from a custom Snapshot fork running exclusively on Binance Smart Chain (BSC) to a modern instance of Snapshot, capable of supporting each of Beefy's chains. As a result of the transition, proposals ending before the start of 2022 were not carried forward to the new site. Instead, an archived copy of the original site has been preserved.
{% hint style="info" %}
Note that access to the archived Beefy voting site is available at . The archived site requires users to connect their wallet to both the site and the BSC Mainnet to display historic proposals. The current voting site is available live at .
{% endhint %}
Alternatively, we have prepared and maintain a [proposal repository](/dao/proposal-repository) here in our docs, where you can quickly get access to any of the major proposals on either voting site throughout our history.
# Proposal Repository
Last Update: February 2023
Beefy is governed by and for our Cowmoonity through our governance process. Any user can submit a Beefy Improvement Proposal (BIP), Beefy Signalling Proposal (BSP), request for funds or other general proposal for consideration and voting by the Cowmoonity.
This page lists some of the most important proposals from our history, together with links to the full proposal text and results. The list focuses on key initiatives, governance changes, product developments and events in our history. Common matters like individual payments, bounties and partnerships are generally excluded. The page also includes a list of significant proposals that did not receive approval, to inform those considering raising similar issues in the future.
At the end of 2021, Beefy transitioned from a custom Snapshot fork running exclusively on Binance Smart Chain (BSC) to a modern instance of Snapshot, capable of supporting each of Beefy's chains. As a result of the transition, proposals ending before the start of 2022 were not carried forward to the new site. Instead, an archived copy of the original site has been preserved. This page consolidate the two sites, and provide a seamless history of governance at Beefy.
{% hint style="info" %}
Note that access to the archived Beefy voting site is available at . The archived site requires users to connect their wallet to both the site and the BSC Mainnet to display historic proposals. The current voting site is available live at .
{% endhint %}
## Approved
## Signalling Proposals
Beefy Signaling Proposals (BSPs) are non-binding proposals intended to signal the Cowmoonity’s feelings and intentions on the issue being raised, without tying the DAO to the outcome. This allows members to express their views honestly, without concern for tactical voting or the practicalities of implementation.
In theory, a clear outcome in favour of change should be a strong signal to the Core to pursue the change independently. Where the Core refuses or fails to deliver on that signal, a binding Beefy Improvement Proposal can be used instead. Alternatively, a strong signal against proposed changes should quieten pressure for those changes amongst the Cowmoonity, at least for the near future.
# Treasury
Last Update: April 2026
At the heart of Beefy's operations is our Treasury, which is managed by our Core contributor team. As our $BIFI token is fully distributed, with no tokens reserved for later use, our entire operation is funded by our ongoing revenue-generating activities. To keep the lights on and our vaults autocompounding, Beefy relies on the constant vigilance of its treasury team to manage the use of our Treasury responsibly, and with the DAO's best interests at heart.
This page explains the history and structure of the Beefy Treasury, summarises our approach to treasury management, and provides the details you'll need to access our live treasury activities.
## History
Beefy's core product - our Beefy Vaults - are designed from the ground up to generate fees for the project (see [Beefy Fees Breakdown](/ecosystem/beefy-bulletins/beefy-finance-fees-breakdown)) to sustain our activities. As such, we have always been a revenue-generating project, and have always had some level of treasury inflows and outflows.
Over time, our treasury activities have become increasingly sophisticated. Initially, the project's founders privately managed the inflows from the smart contract to cover their costs in operating and maintaining the protocol. The original [BeefyTreasury contract](https://bscscan.com/address/0x4a32de8c248533c28904b24b4cfcfe18e9f2ad01#code) was [deployed](https://bscscan.com/tx/0xccc2a94cde6aa10e3928a837b17cb7705f8ec3104afb66842627cc9cdaf4621c) on 6 November 2020. The Treasury contract was very basic in functionality, allowing the native chain token and ERC-20/BEP-20 tokens to be withdrawn by the owner, which was the [BeefyDeployer EOA](https://bscscan.com/address/0x565eb5e5b21f97ae9200d121e77d2760fff106cb).
By March 2021, Beefy had expanded to include more contributors, and so the Core contributor team created the #💵-treasury channel in the [Beefy Discord](https://discord.gg/yq8wfHd) as a place for discussion of all treasury-related issues. Over the next few months, Beefy became increasingly multichain, and additional BeefyTreasury contracts were deployed on [Avalanche](https://snowtrace.io/address/0xa3e3af161943cfb3941b631676134bb048739727#code), [Polygon](https://polygonscan.com/address/0x09ef0e7b555599a9f810789fff68db8dbf4c51a0#code), [Fantom](https://ftmscan.com/address/0xe6cce165aa3e52b2cc55f17b1dbc6a8fe5d66610#code) together with some other early chains. However, the Core team recognised the limitation of the early Treasury's design, and a move multisig wallets was debated, despite multisig solutions not being available on all chains.
By September 2021, the DAO had settled on moving to multisig wallets on BSC and Polygon (as the two chains with multisig solutions available at the time), and establishing the Treasury Council as the signers of the multisig. On 3 September 2021, a soft vote was concluded on Discord to appoint the new members of the Treasury Council. This was followed up by a [Snapshot Proposal](https://vote-archive.beefy.finance/#/beefy/proposal/QmafULDojJ4StzJtuwjBZutnUkzb9TUhTLCLZe5R7deWLo), which confirmed the initial 7 members. On 11 September, ownership of the original BeefyTreasury contract on BSC was [transferred](https://bscscan.com/tx/0x34a89b3cd5564fbd22672169b9cce43a538cf764cb73e1a28fe4db89241ae7ad) to the new multisig. Since then, the multisig system and Treasury Council has continued and expanded to each of Beefy's new chains.
Also in September 2021, Beefy's Core team began to implement bots in the #💵-treasury channel, initially displaying the value of the Treasury for the benefit of DAO members. By October 2022, this had evolved to include each new transactions live when posted from any of the Treasury's multisig wallets. Some of the key bot commands are:
* **Show Full Treasury:** `@Bitch I'm a Cow#9189 treasury`
* **Show Full Treasury on Specified Chain:** `@Bitch I'm a Cow#9189 treasury {blockchain}`
* **Show Current Cowllector Balances:** `@Bitch I'm a Cow#9189 cowllector balances`
## Treasury Council
As described above, the Treasury Council was formed in September 2021 as the team that should conduct and manage all Treasury transactions and related activities for Treasury management. The role of the Treasury Council has expanded gradually, to now include:
* Orchestrating, signing and executing all Treasury transactions (i.e. payments out of Treasury);
* Managing Treasury assets, such as creating and exiting protocol-owned liquidity and holding grants, pending rewards and other external assets;
* Monitoring and providing operating capital (e.g. gas) for Beefy's infrastructure, including our Cowllector, Fee Batch Harvester and contributor EOAs;
* Arranging for payment of key expenses, including contributor salaries, sponsorships, recurring hosting and service fees and reimbursement for contributor expenses; and
* Handling regular bribe payments to partner exchanges.
The Treasury Council has 7 members, and requires consensus from any 4 to sign off on any multisig transaction before it can be executed. See the [treasury multisig](/safety/contracts-and-timelocks#treasury-multisig) page for more details.
Any questions for the Treasury Council should be directed to the #💵-treasury channel on the [Beefy Discord](https://discord.gg/yq8wfHd). For security purposes, please do not directly message Council members instead, or your messages will be ignored and potentially blocked or reported.
## Treasury Infrastructure
Beefy's Treasury relies on a few core building blocks of infrastructure to facilitate the secure inflows and outflows of funds from Treasury. The core elements are:
* **Treasury Multisig** - multi-signature wallets controlled by the Treasury Council, used to hold all of the main assets of the treasury securely, and in a manner that can't be exploited by any single individual;
* **Treasury Contributor Wallets** - externally-owned accounts (**EOA**s) controlled by different Beefy contributors, such as our Treasury Council members and other key DAO contributors. By using EOAs to interact with external protocols and contracts, we isolate the risk of hacks or exploits impacting the Beefy Treasury, by isolating it from externals and giving no or very limited exteranl approvals;
* **Cowllector** - the Beefy Cowllector is a bot created and maintained by the Beefy Core which seeks to harvest Beefy vaults regularly (at least every 24 hours for all chains but Ethereum) and wherever a profitable opportunity presents itself. As the harvest caller claims a small fee as a proportion of the harvest, the Cowllector analyses the size of the potential reward versus the cost of harvesting, and makes automatic calls where appropriate;
* [Revenue Bridge](/ecosystem/protocol/revenue-bridge) - the Beefy Revenue Bridge is a set of contracts on each chain which facilitate the bridging of Beefy's fees back to Ethereum. The bridge contract performs a few functions to allocate and prepare them for bridging. The bridge itself contains multiple different bridging services, and will use the preferred method which has been specified to the contract. The bridge can either bridge directly to Ethereum, or back via any number of intermediate chains; and
* [Fee Batch](/ecosystem/protocol/fee-batch) - the Beefy Fee Batch is a set of contracts on each chain, which aggregate Beefy's fees from across the protocol into one place, to be able to efficiently distribute them to stakeholders. On Ethereum, the fees arrive to the Fee Batch, which aggregates all of the protocol's fees. Once a sufficient amount of tokens are batched token, the Fee Batch distributes them both to Treasury and - after swapping back to native $ETH - to the [Incentive Programmes](/ecosystem/protocol/incentive-programmes).
The treasury multisigs can be found at the following addresses for the following chains:
* Arbitrum: [0x3f5eddad52C665A4AA011cd11A21E1d5107d7862](https://gnosis-safe.io/app/arb1:0x3f5eddad52C665A4AA011cd11A21E1d5107d7862/balances)
* Avalanche: [0x26dE4EBffBE8d3d632A292c972E3594eFc2eCeEd](https://gnosis-safe.io/app/avax:0x26dE4EBffBE8d3d632A292c972E3594eFc2eCeEd/balances)
* Base: [0x1A07DceEfeEbBA3D1873e2B92BeF190d2f11C3cB](https://app.safe.global/home?safe=base:0x1A07DceEfeEbBA3D1873e2B92BeF190d2f11C3cB)
* BSC: [0x7C780b8A63eE9B7d0F985E8a922Be38a1F7B2141](https://gnosis-safe.io/app/bnb:0x7C780b8A63eE9B7d0F985E8a922Be38a1F7B2141/balances)
* Canto: [0xF09d213EE8a8B159C884b276b86E08E26B3bfF75](https://safe.neobase.one/canto:0xF09d213EE8a8B159C884b276b86E08E26B3bfF75/home)
* Cronos: [0xa9721Ae5042482D7a884A2138f580459B680920f](https://cronos-safe.org/cro:0xa9721Ae5042482D7a884A2138f580459B680920f/home)
* Ethereum: [0xc9C61194682a3A5f56BF9Cd5B59EE63028aB6041](https://gnosis-safe.io/app/eth:0xc9C61194682a3A5f56BF9Cd5B59EE63028aB6041/home)
* Fantom: [0xdFf234670038dEfB2115Cf103F86dA5fB7CfD2D2](https://safe.fantom.network/#/safes/0xdFf234670038dEfB2115Cf103F86dA5fB7CfD2D2/balances)[
]()
* Fuse: [0x1C124c2CaB83b3C3B5D0f0899CeeA5e06964599F](https://gnosis-safe.fuse.io/fuse:0x1C124c2CaB83b3C3B5D0f0899CeeA5e06964599F/balances)
* Kava: [0x07F29FE11FbC17876D9376E3CD6F2112e81feA6F](https://app.oryy.io/kava:0x07F29FE11FbC17876D9376E3CD6F2112e81feA6F/home)
* Metis: [0x0f9602B7E7146a9BaE16dB948281BebDb7C2D095](https://metissafe.tech/metis-andromeda:0x0f9602B7E7146a9BaE16dB948281BebDb7C2D095/balances)
* Moonbeam: [0x3E7F60B442CEAE0FE5e48e07EB85Cfb1Ed60e81A](https://multisig.moonbeam.network/mbeam:0x3E7F60B442CEAE0FE5e48e07EB85Cfb1Ed60e81A/home)
* Moonriver: [0x617f12E04097F16e73934e84f35175a1B8196551](https://multisig.moonbeam.network/mriver:0x617f12E04097F16e73934e84f35175a1B8196551/balances)
* Optimism: [0x4ABa01FB8E1f6BFE80c56Deb367f19F35Df0f4aE](https://gnosis-safe.io/app/oeth:0x4ABa01FB8E1f6BFE80c56Deb367f19F35Df0f4aE/home)
* Polygon PoS: [0xe37dD9A535c1D3c9fC33e3295B7e08bD1C42218D](https://gnosis-safe.io/app/matic:0xe37dD9A535c1D3c9fC33e3295B7e08bD1C42218D/balances)
* Polygon zkEVM: [0x6fdfb18D09d5fa9a76ac76cb6Cdc53c8F23C3B29](https://zksafe.quickswap.exchange/home?safe=zkEVM:0x6fdfb18D09d5fa9a76ac76cb6Cdc53c8F23C3B29)
* zkSync: [0x9F9FE15FDa14eAA2d878Ed667C805A7CC13c2560](https://zksafe.protofire.io/home?safe=zksync:0x9F9FE15FDa14eAA2d878Ed667C805A7CC13c2560)
Older retired treasuries (either on retired chains or replaced by new treasuries) include:
* Arbitrum: [0xc3a4fdcba79DB04b4C3e352b1C467B3Ba909D84A](https://arbiscan.io/address/0xc3a4fdcba79db04b4c3e352b1c467b3ba909d84a)
* Aurora: [0x088C70Ddff3a3774825dd5e5EaDB356404248d83](https://app.safe.global/home?safe=aurora:0x088C70Ddff3a3774825dd5e5EaDB356404248d83)
* Avalanche: [0xA3e3Af161943CfB3941B631676134bb048739727](https://snowtrace.io/address/0xa3e3af161943cfb3941b631676134bb048739727)
* BSC: [0x4A32De8c248533C28904b24B4cFCFE18E9F2ad01](https://bscscan.com/address/0x4a32de8c248533c28904b24b4cfcfe18e9f2ad01)
* Celo: [0xca807d809f9639cefb3d31a7951cec3ab405a2fd](https://www.xdao.app/42220/dao/0xCA807D809f9639CEfb3d31a7951Cec3ab405a2fd)
* Cronos: [0x3f385082Ee3dFf58ca0a6a7fe44Ea0B5d6b4168E](https://cronoscan.com/address/0x3f385082ee3dff58ca0a6a7fe44ea0b5d6b4168e)
* Emerald: [0x8fd0869271d26e6653f5d5650685630f75b6aedf](https://www.xdao.app/42262/dao/0x8FD0869271d26E6653f5d5650685630F75b6AEDf)
* Fantom: [0xe6CcE165Aa3e52B2cC55F17b1dBC6A8fe5D66610](https://ftmscan.com/address/0xe6cce165aa3e52b2cc55f17b1dbc6a8fe5d66610)
* Fuse: [0x922f8807E781739DDefEe51df990457B522cBCf5](https://explorer.fuse.io/address/0x922f8807E781739DDefEe51df990457B522cBCf5)
* Harmony: [0x523154a03180FD1CB26F39087441c9F91BcD0389](https://multisig.harmony.one/#/safes/0x523154a03180FD1CB26F39087441c9F91BcD0389/balances)
* HECO : [0xdbb72c8b7ebdd52a4813b9d262386dfdab69c9ba](https://www.xdao.app/128/dao/0xdbB72c8B7eBdD52A4813B9D262386dfDAB69c9bA)
* Moonriver: [0xB6Fb58eea08b5539f371A744bb9Ef86283F1B3c2](https://moonriver.moonscan.io/address/0xb6fb58eea08b5539f371a744bb9ef86283f1b3c2)
* Polygon PoS: [0x09EF0e7b555599A9F810789FfF68Db8DBF4c51a0](https://polygonscan.com/address/0x09ef0e7b555599a9f810789fff68db8dbf4c51a0)
* zkSync: [0x8cE3fE8b9Ec8Ab80967c9771909385E3e3A272fA](https://explorer.zksync.io/address/0x8ce3fe8b9ec8ab80967c9771909385e3e3a272fa)
## Treasury Management
Management of Beefy's Treasury has also evolved over time, to reflect the changing needs of the protocol and the DAO. Operating on so many chains, each with their own sets of vaults, infrastructure and MultiSig wallets makes it a complicated process to actively manage the Treasury. Instead, a number of overarching principles have emerged to guide current best practices.
First and foremost, Beefy's contributor team have opted to operate the Treasury on each major chain primarily in stablecoins, to mitigate the downside risk of holding volatile assets. This allows Beefy to make clear and deliberate decisions about how to use its funds, free from the risks of current market condition. As such, the Fee Batcher on each major chain swaps all Beefy's vault fees into a designated currency for that chain, as detailed in [#inflow-currencies](#inflow-currencies "mention") below.
Secondly, it was decided that investing a portion of treasury assets in Beefy Vaults to generate passive income would be a sensible and smart use of funds. Generally speaking, only a small proportion of the Treasury held on our major chains is ever invested in Beefy Vaults, and they are always allocated to stablecoin-only vaults. Though returns on invested funds are generally relatively small, this mechanism does help to mitigate the inflationary nature of stablecoin valuations.
Finally, to facilitate liquidity for our tokens across the different chains, Beefy also invests in and maintains liquidity positions in our tokens, including both our [$BIFI Token](/ecosystem/bifi-token), and our [Beefy-escrowed Tokens](/beefy-products/beefy-escrowed-tokens). Our $BIFI token is typically paired with native or gas tokens on the relevant chain, to provide the easiest route into the token for new arrivals on the chain. Once the bridged $BIFI token contract is deployed on a new chain, the contract is connected to the Beefy Bridge and our partners at Multichain, so that more $BIFI can be bridged onto the chain and so that an initial LP can be created.
Live summary details of the current state of the Beefy Treasury, including all liquid, staked/invested and locked tokens and liquidity positions, are available in the [Treasury Dashboard ](https://app.beefy.finance/treasury)page of the Beefy App.
The Beefy Treasury Dashboard was introduced in January 2023 to provide immediate summary insights into the current state of the Beefy Treasury.
## Inflow Currencies
As described above in [Treasury](/dao/treasury#treasury-management), inflows on our key blockchains are swapped into stablecoins for treasury management purposes, with each chain's [Revenue Bridge](/ecosystem/protocol/revenue-bridge) contract adopting a key stablecoin for its operations. The following chains have the following nominated currencies:
* Arbitrum: USDC
* Avalanche: USDT
* Base: WETH
* BSC: BUSD
* Canto: USDC
* Cronos: USDC
* Ethereum: USDC
* Ethereum Validator: WETH (retained in validator)
* Fantom: USDC
* Fantom Validator: WBTC (gradually bridged to Ethereum)
* Fuse: WFUSE
* Fuse Validator: Fuse (retained in validator)
* Kava: USDC
* Metis: USDC
* Moonbeam: MAI
* Moonriver: USDC
* Optimism: USDC
* Polygon PoS: USDC
* Polygon zkEVM: WETH
* zkSync: WETH
Volumes and liquidity on Aurora, Celo, Emerald, Harmony and HECO are all currently too small to warrant stablecoin management, so vault fee inflows are typically swapped into the relevant native chain token instead.
# Cowmoonity
Last Update: March 2024
## Core contributors
Beefy's Core contributors are working hard every day to improve Beefy in various domains. Most have a paid function.
Name
Discord
Twitter
armads
armads.
@armadsjt
chebiN
chebin.
-
DefiDebauchery
defidebauchery
@DefiDebauchery
EPETE
epete
@__ePete
Eren
erenjaegar
@eren_beefy
frondoto
frondoto
@frondoto1
jackgale.eth
jackgale.eth
@iamjackgale
kexley
kexley
@kexleyBeefy
RXP
RXP
-
Pablo
pablodotcom
@pablo_beefy
Power
.power
@PowerBeefy
ReflectiveChimp
chimp..
@ReflectiveChimp
Roman Monk
romanmonk
@roman_mnk
TBC
thebeefycow
@thebeefycow
Weso
wesobeefy
@w3soBeefy
YR2150 | Beefy Pulse
yr2150beefypulse
@yr2150T / @beefypulse
## Contributors
| Name | Discord | Primary Role |
| ----------------- | ----------------- | ----------------------- |
| Appel \| Gear | \_appel | Cowmoonity Hero / Gear |
| crypto\_peter | crypto\_peter | Cowmoonity Hero |
| MisterDollahSignz | misterdollahsignz | Cowmoonity Hero / Media |
| Sim One | simuan9602 | Cowmoonity Hero / Mod |
| Terry | terrys999 | Cowmoonity Hero |
| ZukoWick | zukowick | Cowmoonity Hero / Mod |
| C L | cl272. | Mod |
| dcFX | dcfx0 | Mod |
| Bustin Jieber | bustinjieber420 | Strategist |
| Cartman | cartman42069 | Strategist |
| Frog | geschnarkus | Strategist |
| pumpingGhost | pumpingghost | Strategist |
| shatterproof | shatterproof. | Strategist |
## Beefy OG's
Below is the list of Beefy OG's who were around in Beefy's first year, some even from the start, and helped to grow Beefy in the early stages. The stats are based on [Beefy's Discord](https://discord.gg/yq8wfHd), plus Twitter account if available. This role is no longer given to new contributors. Most of Beefy's Core contributors are Beefy OG's as well.
Name
Discord
Twitter
Primary Role
Name
Discord
Twitter
Primary Role
0xbeefy
0xbeefy#0679
-
-
AllTradez
alltradez
@AllTradesz
-
zxcvzxcv
bagholder#0845
-
-
barnyard
barnyard#6764
-
-
Broken Robot (they/them)
brknrobot#0952
-
-
Cassandra
Cassandra#2104
-
-
CHIP - BLUE CHIP/LOW RISK
Chip#1528
@Chip_Penguin
Mod
Destructible Fruit
Destructible Fruit#4578
-
-
Dibby
Dibby#5165
-
-
dingbat
dingbatx#6073
-
-
DoD4uFN | BIFI Maxi
DoD4uFN#9980
@DoD4uFN
Dev
dydymoon.eth
dydymoon.eth#3133
@dydymoon1
-
FEEDZED
FEEDZED#9625
-
-
felipe_bifi
felipe_bifi#1224
-
-
GPMS
GPMS#0844
-
Mod
kaltoro
kaltoro#2974
-
-
kevboard
kevboard#3813
-
-
Mo0o0
Mo0o0#1628
-
-
mooncow
mooncow#8411
-
-
Moonster
Moonster#4130
@Moonster_BSC
-
Oglop
Oglop#8007
-
-
Ravified
Ravified#4133
-
Mod
Zupori
redwoods#0108
-
-
roastyb
roastyb#3775
@roastyb1
-
Sens0ryYard
Sens0ryYard#6988
-
-
shibacrypt
shibacrypt#2756
-
-
Snorlax
Snorlax#5376
-
-
SpittingNickels
SpittingNickels#7142
-
-
Tumbledyer
Tumbledyer#8408
@tumblenomics
-
UnphaZeD
UnphaZeD#4758
-
-
wivern
wivern#0410
-
-
wwp
wwp#2782
-
-
Beefy is a community of contributors. Below is a list of Cowmoonity members with an active role.
## Unique contributors
As of 16-03-2024, there are 81 unique contributors among the following roles:
* 18 @Core
* 13 @Dev
* 11 @Strategist
* 46 @Beefy OGs
* 27 @Cowmoonity Heroes
* 18 @Cowmoonity Farmhand
* 13 @Mod
# Partnerships
Looking for a collaboration with Beefy? All the info you'll need is right here.
Beefy's network of partners and collaborators from across the world of DeFi are at the centre of what we do as a protocol. As a longstanding and trusted name in multiple DeFi markets, there are very few types of projects that we haven't collaborated with (though we're always keen to add more!). This page overviews our partnerships team and efforts, as well as the process that we have in place to handle requests from prospective partners.
## The Beefy Partnerships Team
Our relationships with existing and new partners are managed by our dedicated partnerships team. The key members of the team are:
* Frondoto - Business Development Lead
* Armads - Business Development
* GPMS - Business Development
* TBC - Social Media / Marketing Lead
Even with our dedicated team, we're still inundated with partnerships requests. To manage this, we ask that prospective partners follow the process outlined below to kick things off, rather than reaching out directly to the team.
## How do I connect with Beefy?
Prospective partners should head to the #🕵-partnership-vetting channel on the [Beefy Discord server](https://discord.gg/yq8wfHd), to introduce yourself to our Cowmoonity. The channel is a dedicated space to discuss new and existing partnership opportunities, and for prospective partners to introduce themselves and their projects to our Cowmoonity.
Alternatively, if you prefer not to reach out via Discord, you can contact us through any of our other social media channels (including [Twitter](https://twitter.com/beefyfinance), [Reddit](https://www.reddit.com/r/Beefy/) and [Telegram](https://t.me/beefyfinance)), and we'll put you in touch with our vetting assistants.
## What does vetting consist of?
Our vetting process doesn't follow any strict guidelines or procedures, but simply involves our members gathering information from you and presenting this back to the Core team and Cowmoonity, together with a decision on whether to refer you to our Core team. Our members will look to assess the size and growth of your project or organisation, the nature and fit of your products and the kind of partnerships that could be pursued. We gladly accept projects volunteering their own information (check the channel for past examples), though our members will aim to come to their own verdict of whether to refer your request to Core.
To keep the process above board, we kindly ask that you refrain from directly messaging any of our Core team or Cowmoonity Heroes or Farmhands, unless specifically invited to. We're proud that our partnerships process embraces transparency, and hope that public vetting will provide you a platform to introduce your project to our Cowmoonity.
## Can't I just speak to Core?
We get it. Sometimes a request may feel too pressing or a project may feel too important to need to go through vetting. Or you may have tried our vetting process, but found that our assistants are standing in your way. You might think it's a good idea to start messaging our Core team directly, to make sure your request is heard... but please, don't.
Our Cowmoonity Heroes and Farmhands are longstanding friends of the DAO, and have our best interests at heart. They're also well aware of when a request *really* is important, and won't hesitate to put you straight in touch with Core if appropriate. However, taking matters into your own hands is likely to pull Beefy's key resources away from their hard work building the protocol, and isn't the best first impression if you're then referred back to vetting. So take a deep breath, smile and trust in the process... our vetting assistants are here to help you.
## What kinds of partnerships are there?
Beefy's network of partners spans every corner of the DeFi world, and beyond. There are really no limits to what a partnership with Beefy could entail. With that said, there are a number of common types of partnerships that we regularly engage in:
* Blockchain partners - add Beefy to your chain to build out its DeFi ecosystem.
* Decentralised exchange partners - bring liquidity to your exchange by having Beefy build autocompounding vaults on top of your farms.
* Protocol co-marketing partners - market your project with Beefy's vaults and launchpools.
* Wallet integration partners - have Beefy integrate your wallet into our site.
* Insurance partners - protect and market to Beefy's users with dedicated products.
* Infrastructure and security partners - bring your technology and services to bolster Beefy's operations.
## Any last tips for prospective partners?
Now that you mention it:
* Have a look through our #🕵-partnership-vetting channel on Discord, as well as all the threads attached to it. This'll give you a sense of how the vetting process goes, and what kind of information you'll be asked to give.
* If you want to give a really good first impression, perhaps consider preparing your own summary in the style adopted by our vetting assistants for previous requests. Our assistants will still want to double check what you say, but this may save both you and us a fair amount of time and effort.
* We'll often want to know about what you want Beefy to bring to a partnership, and what your project proposes to bring. Some points you may want to consider ahead of time are:
* For common requests, like integrating a wallet into our site, we simply can't say yes to everyone who asks. So explain what separates you from others in the market, or what you plan to bring to Beefy to make an additional integration worth our while.
* Where you're asking for co-marketing, bear in mind the relative size of your project and ours. For Beefy, partnering with tiny fledgling protocols often means we're giving more than we're getting in marketing efforts.
* If you're considering asking Beefy's dev team to help you build your product, it's worth thinking about: (1) is your product a better use of their time than continuing to build our existing and successful protocol? and (2) if Beefy's team did want to build that product, why would they want or need to do it with you rather than doing it themselves?
* For projects with your own token, consider whether you may want a Beefy [vault](/beefy-products/vaults) to attract liquidity to your project, and whether a [launchpool](/beefy-products/boost) partnership may be of benefit to you.
* If you're interested in a Beefy vault for your project, we'd recommend reading through our [SAFU Standards](/safety/beefy-safu-practices) page first, and assess whether you meet our criteria. This is one of the first questions you'll be asked in vetting, so best to come prepared with a "yes"!
* If you're an individual looking to get involved with Beefy, you don't need a formal partnership! Head to the #💼-we-are-hiring page on the Beefy Discord to see what kind of paid and volunteer roles are available. And get stuck in with us from there.
# SAFU Standards
Last Update: January 2026
At Beefy, we recognise three words to live by: *SAFU First. Always.* You can craft the most incredible features into your smart contracts, but if you can’t adequately safeguard user funds, your contracts don’t deserve to have users. That’s why safety is the first, last and foremost consideration in every product we release.
This page describes the various practices that Beefy's contributors take to ensure that: (i) our new products are meet safety standards before launch; (ii) our existing products are properly maintained and observed; and (iii) our response to any security concerns are issues are rapid and safe. It also explains how live risk points are managed on the Beefy UI, to ensure users are appraised of any threats they may face.
Beefy has adopted a stringent risk management framework - our SAFU Standards - that assess a range of considerations for our autocompounding strategies to ensure all products meet our high security standards.
## New Token Requirements
Before Beefy will consider a farm for vaulting, we ensure that the underlying tokens included in the product are all suitably SAFU for our users. New tokens must meet the following:
* token contracts must have been verified in the block explorer;
* non-native tokens must be from reputable bridges;
* new tokens must have sufficient liquidity; and
* tokenholders with more than 5% of circulating supply must not be either an externally-owed account (**"EOA"**) or a multi-signature account.
In addition, tokens are flagged as risky in our UI if they do not also meet the following:
* token contracts (and related protocol functionality) should be properly audited by reputable third-party providers;
* rug/migrator functions should be either completely removed or timelocked sufficiently;
* token emission rates should be either hard capped or timelocked sufficiently; and
* all proxy implementation changes (i.e. upgrades to the contracts) should be timelocked.
As described in [Risk Checklist](/safety/risk-checklist), we also look to identify and flag the following risk checks for all new tokens:
* If a large proportion of the circulating supply is concentrated in a small number of large holders, we flag the concentrated in the addressbook token flags; and
* If the article is a synthetic copy of another asset, meaning intended to be pegged to another asset's price but not backed and redeemable 1:1 for the underlying asset, we indicate that products using this asset involve synthetic assets.
## New Farm/Pool/Market Requirements
Before a new farm, pool or marekt is vaulted on Beefy, it must meet the following:
* contracts must have been verified in the block explorer;
* liquidity must be sufficient for swapping farm token rewards; and
* reward token emissions should be timelocked to ensure they cannot be changed unpredictably.
In addition, products are flagged as risky in our UI if they do not also meet the following:
* rug/migrator functions should be either completely removed or timelocked sufficiently;
* all proxy implementation changes (i.e. upgrades to the contracts) should be timelocked;
* if the underlying protocol is relatively new or has not secured significant value for a sustained duration, we indicate that it is not battle-tested;
* if the strategy for the new farm involves multiple layers of contracts or particularly novel or complicated logic, we indicate that it is a complex strategy; and
* if the underlying protocol involves the use of external curators to manage risk in their pools or markets, we flag that the product is curated.
## Vault Testing Procedure
Once a product has gone through due diligence and is being prepared, our strategists will follow a manual testing procedure on every new vault before it can go live on our app. This is to ensure that the vault works as intended and user funds are always SAFU. The sequential procedure is:
1. deposit a small amount of the asset;
2. withdraw all;
3. deposit again, wait 1 minute and check that `callReward()` is not 0;
4. harvest the strategy;
5. panic the strategy;
6. withdraw 50% while panicked to make sure users can leave;
7. try to deposit, an error should pop up but don't send the deposit through;
8. unpause the strategy; and then
9. deposit the 50% that has previously been withdrawn and harvest again.
## Strategy Upgrades
Occasionally, Beefy strategists will come out with a new innovative strategy, or yield farms change their reward contracts. In those circumstances, Beefy vaults have the flexibility to adapt to these changes, and can swap strategies so users don't have to migrate their funds to a new vault. This is done automatically by way of a strategy upgrade.
The new strategy is deployed with a dummy vault and all of the manual tests outlined above are completed. After passing the checks, the new strategy is assigned to the existing vault. The existing vault receives an onchain proposal for the new strategy to be added by way of the Beefy developer multi-sig wallet, and has to wait until the timelock delay has passed before the strategies are switched.
## Timelock Monitor
During the life of our vaults, the projects and protocols that we build on top of will naturally need to use functionality in their smart contracts which are susceptible to abuse (and for which a timelock was advisable for implementing a Beefy vault). To protect against the risk of abuse, we have implemented the #👀-timelock-monitor channel in the [Beefy Discord Server](https://discord.gg/yq8wfHd).
By displaying the relevant contract and protocol, the triggered event, the method scheduled to be called and the end time for the timelock, the Timelock Monitor provides all the information needed to assess the risk and protect user funds. As a public channel, the monitor provides free access to this information for our users, as well as insight into how Beefy’s team is handling these risks, to inform decision-making.
## Panic
Even with all of our precautions, sometimes something can go wrong with the underlying farm or assets in a Beefy vault, for which reacting quickly is of great importance. Beefy strategies have a keeper that is allowed to ["panic"](/developer-documentation/strategy-contract#panic) the relevant strategy, which withdraws the staked funds from the farm back to the strategy contract and removes all allowances. This ensures that users funds are then kept available for the users to withdraw.
# Risk Checklist
Last Update: January 2026
Cover image for the Beefy Risk Checklist introductory article.
The Beefy Risk Checklist is a module for [Beefy's web application](https://app.beefy.com/) aimed at updating users on the risk profile of the products they're exploring with a clear and succinct overview of key risk checks performed by Beefy.
{% hint style="danger" %}
The Risk Checklist is not intended as a substitute for user due diligence, nor as an endorsement of the safety of underlying assets or protocols included within the Beefy product. It is intended as an aid to user or professional due diligence only. **Don't trust, verify.**
{% endhint %}
Due diligence and risk evaluation in DeFi is an enormous and significant topic that all users face. We at Beefy recognise that it is impossible to concretely capture the full risk profile of any digital assets in a manner befitting a sleek and simple user interface. Nonetheless, we aim to ensure our users are prompted to explore key risks when using Beefy, and to kickstart their due diligence by showcasing some of the common checks performed by Beefy when onboarding new products.
In DeFi, projects like Beefy are often faced with a choice: either wash your hands of risk analysis entirely (*Do Your Own Research*), or help your users to navigate risks (while yourself suffering some risk of overreliance on that help). **Beefy chooses to help.** We care deeply about our users and always want to assist in identifying and managing risk where reasonably possible.
With that said, risk is a complex grey area, and one in need of constant improvement. We're always grateful for thoughts and feedback from our users to help us improve (see [Comment & Review](#comment-and-review)).
{% hint style="info" %}
To learn more about the context of the Risk Checklist and the specific updates introduced at the end of 2025, check out our [introductory article](https://beefy.com/articles/risk-checklist/) on safety changes introduced at the end of 2025.
{% endhint %}
## Checklist Items
The Beefy Risk Checklist is comprised of a selection of common checklist items that are applied to each and every product listed on the Beefy web application.
Within the app, we attempt to display these checks simply with a one-line explanation of what the check indicates about the product. We then use red coloring and ❌ crosses to identify checks that have failed to fully pass our check (i.e. indicate some risk item that users ought to be aware of). We use green coloring and ✅ ticks to indicate checks performed which did not identify a specific risk.
By default, we only display risk items and do not show the checks that have passed (users must actively select *"Other checks"* to see what other checks have been performed). We recognise that user psychology can sometimes assume that if most checks are green then the product is mostly safe. This is not the case: failing any one of our checks means that a material risk is inherent in the product which the user should research and understand.
The checklist design is flexible, meaning that more risk items can be added over time. Below we describe each risk item one by one.
Screenshot of the Beefy Risk Checklist as it appears by default on the Beefy web application.
### Highly Complex
By *“highly complex”*, we mean that the product is inherently difficult for users to understand and assess risk for due to its combination of many layers of smart contracts, intertwined processes or even novel code that the user is unlikely to have seen before.
There is nothing inherently risky about a system being complex, though experience tells us that — for smart contracts at the very least — complexity is correlated with risk.
We look at several key factors in determining high complexity:
* [ ] The Beefy strategy contains novel elements or many intertwined processes which may be likely to cause issues due to their complexity.
* [ ] The underlying protocols combine to add multiple layers between the user and the ultimate deployment of their assets.
* [ ] The underlying assets of a product involve multiple layers between the user and the ultimate exposure those assets provide.
The key factors listed above are alternative conditions for a product to be considered complex. If even one element of the product exhibits an unusually high level of complexity, then the whole product must be labelled as complex.
### Curated
By *“curated”*, we mean that the Beefy product depends directly upon the ongoing management of some designated curator or third party beyond Beefy and the issuers of the underlying platform/protocol.
Though often thought of as external parties, we include as curators any project which retains centralised discretion to curate their products’ exposure to different underlying assets and strategies. Users should be made aware that they are putting their assets in the hands of a dedicated party who has some meaningful discretion over their allocation.
The sole factor in determining this checklist item is whether the underlying platform or asset relies on curators or other third parties to manage the product’s asset or risk allocations.
### Audited
By *“audited”*, we mean that all the core components which comprise the Beefy products (including all underlying protocols and assets) have been properly and publicly audited.
The use of the *"core components"* is important here. Smart contract designs are often tweaked or feature minor updates over time without the need to re-audit the core logic. We do not look for fresh audits with every version update, but instead require that a public audit is available for the core logic (and any functionality which touches user funds) in the product we are building on top of.
We look at several key factors in confirming audited status:
* [ ] All Beefy contracts involved in the product should be derived from properly audited code.
* [ ] All underlying protocols involved in the product should have issued public audits for the core components of the system which the product relies on.
* [ ] All underlying assets involved in the product should have issued public audits for their core token contracts and any associated mechanisms (e.g. staking mechanisms).
The key factors listed above are all necessary conditions for a product to be considered audited.
### Battle-tested
By *“battle-tested”*, we mean that a protocol has been well tried and tested over a long-enough period and with sufficient value to indicate that the code is well proven. Were there to be relatively-obvious and exploitable issues with the code, we would expect that a protocol hosting sufficient value would be exploited at some stage.
Importantly, this is about more than just age or value. A codebase that has been around doing nothing for years and suddenly surged in value does not automatically become battle-tested by virtue of that value increase. It’s important that the value has been sustained consistently for a good portion of the protocol’s age (or that reasons for interruption are understood).
We look at several key factors to determine whether or not a product (and its underlying protocol) should be classified as *"battle-tested"*:
* [ ] Underlying protocols’ code has been public and live in production for at least 1 year.
* [ ] Underlying protocols’ code has secured an average of at least $100 million in value over a three-month period.
* [ ] If code is copied or forked from a battle-tested protocol, any material changes have been thoroughly reviewed, and must also be battle-tested independently if they secure meaningful value.
The key factors listed above are all necessary conditions for a product to be considered battle-tested.
### Correlated
By *“correlated”*, we mean that the directional exposure a product faces in only one direction, indicating a limited risk of impermanent loss at most. This is a careful choice of language, as we are not opining on the actual extent of impermanent loss, but rather the nature of the underlying assets and their theoretical profile with respect to impermanent loss.
We look at several key factors to assess the degree of correlation of a product:
* [ ] The product incorporates only single-asset markets and pools, indicating no exposure to impermanent loss.
* [ ] The product incorporates only identical or derivative assets, indicating minimal exposure to impermanent loss.
* [ ] The product incorporates only closely-correlated assets, indicating a more-limited risk of impermanent loss.
The key factors listed above are alternative conditions for a product to be considered correlated. Only products exhibiting no, minimal or limited risk of impermanent loss should be labelled as *"Correlated"*. All other products should be labelled as *“Not Correlated”*.
By *“identical assets”*, we mean assets that should in theory reflect the same thing, for example different deployments of the same stablecoin (e.g. a USDC-USDC.e pair). By “derivative assets”, we mean assets that are derived solely from another asset, and are purely intended to track its exact value (e.g. Synthetix’s sETH is a derivative of ETH).
By *“closely-correlated assets”*, we mean assets that are based on the same core asset, but are expected to gradually alter their precise value over time. For instance: (i) a wrapped liquid-staking token that gradually grows in value as staking gains are compounded beneath the same deposit token (e.g. Lido’s wstETH); (ii) yield-bearing deposit tokens (e.g. Sky’s sUSDS); (iii) fiat-denominated money market instruments like treasury bills (e.g. Ethena’s USDtb).
### Timelocked
By *“timelocked”*, we mean that a project is making proper use of timelock smart contract standards to protect key functions from abuse.
Critical functionality which can be called without warning or delay exposes products to risk; offering a timelock over these functions helps to build confidence that a project is not seeking to abuse these powers. This should apply across all protocols and assets incorporated into any Beefy product.
A proper timelock should rely on sound code from tried-and-tested timelock contracts, as well as incorporating a sufficiently-long timelock. What length is sufficient depends on the function, but we like to see a 24-hour timelock as a base standard, unless there is sufficient justification for a shorter time period.
We check the following sources for timelocks to validate this checklist item:
* [ ] All underlying protocols have guarded any critical functions from misuse by way of a timelock contract guarded by a project multi-sig wallet.
* [ ] All underlying assets have guarded any critical functions from misuse by way of a timelock contract guarded by a project multi-sig wallet.
The key factors listed above are all necessary conditions for a product to be considered timelocked.
### Verified
By *“verified”*, we mean that a project has properly ensured that all core smart contracts are publicly-verified and fully visible on at least one major blockchain explorer.
This involves a process of submitting the deployed smart contract code to the explorer, to indicate that a live account can demonstrate that it has deployed the code. Only once verified can a project’s code be fully and properly reviewed by external parties.
We check the following timelock sources to validate this checklist item:
* [ ] All underlying protocols have publicly verified the core smart contracts involved in the products incorporated into the relevant Beefy product.
* [ ] All underlying assets have publicly verified the core smart contracts involved in the products incorporated into the relevant Beefy product.
The key factors listed above are all necessary conditions for a product to be considered verified.
### Synthetic Assets
By *“synthetic asset”*, we mean an asset that is pegged to and does not have 1:1 backing and redemption with a specified underlying asset, such as a fiat currency.
This covers a wide variety of products, from fully-algorithmic stablecoins (which lack backing), to synthetic derivatives (e.g. Synthetix’s sETH), right the way through to overcollateralised stablecoins backed by assets other than fiat or other backed stablecoins (e.g. USDS).
The sole factor in determining this checklist item is whether any underlying assets in the Beefy product are synthetic in nature.
Screenshot of the Beefy Risk Checklist on the Beefy web application when extended to show all checks performed.
## Application Configurations
Risk Checklist items are configured for each product on the Beefy web application through the [`beefy-v2` repository](https://github.com/beefyfinance/beefy-v2) (for Beefy products and platforms) and the [`beefy-api` repository](https://github.com/beefyfinance/beefy-api) (for tokens).
These items are set by the relevant strategists involved with onboarding a new product, token or platform/protocol, and reviewed periodically as updates are added.
### Vault Config
The [vault config files](https://github.com/beefyfinance/beefy-v2/tree/main/src/config/vault) contain the full metadata of each Beefy product, including all of the items in the risk checklist. They are displayed as boolean values, where `false` indicates the risk is not relevant to this product, and `true` signals that the risk should be displayed on the app.
```json
// beefy-v2/src/config/vault/{chain}.json
{
"id": "{platform-token0-token1}",
...
"risks": {
"complex": false,
"curated": false,
"notAudited": false,
"notBattleTested": false,
"notCorrelated": false,
"notTimelocked": false,
"notVerified": false,
"synthAsset": false
},
...
}
```
### Platforms Config
{% hint style="info" %}
Note that we refer interchangeably to *"Platform"* and *"Protocol"* in respect of the Risk Checklist. We mean the DeFi application that Beefy builds on top of to deposit user assets and earn fees or rewards.
{% endhint %}
The [platforms config file](https://github.com/beefyfinance/beefy-v2/blob/main/src/config/platforms.json) details all of the different DeFi protocols that Beefy builds on top of, providing the metadata to populate the web application. It also specifies platform-specific risks, ensuring that these risks are automatically inherited by the Risk Checklist (even if not flagged in the vault config).
```json
// beefy-v2/src/config/platforms.json
{
"id": "{platform}",
...
"risks": ["NO_TIMELOCK", "HIGHLY_COMPLEX", "NOT_BATTLE_TESTED"],
...
},
```
### Tokens Configs
The tokens config files form part of the Beefy [`blockchain-addressbook` package](https://www.npmjs.com/package/blockchain-addressbook), which lives within the [`beefy-api` repository](https://github.com/beefyfinance/beefy-api/tree/master/packages/address-book). Every token which has ever been added to Beefy is detailed in the addressbook.
The `tags` field of each token entry in the addressbook is used to both identify the asset category and identify any checklist items arising in the token. As with the platform risks, these risks are then automatically inherited by the Risk Checklist, and override anything not flagged in the vault config.
```typescript
// beefy-api/packages/address-book/src/address-book/{chain}/tokens/tokens.ts
{token}: {
...
tags: ['LARGE_HOLDERS', 'NO_TIMELOCK', 'STABLECOIN', 'SYNTHETIC'],
},
```
## Comment & Review
Beefy aims to provide one of the most effective and consistent risk reviews in DeFi, whilst ensuring our process remains accessible for users of any experience level and efficient for management across thousands of products.
With that said, risk profiles are ever-changing and keeping our reviews up to date is a constant struggle. We fully encourage and embrace comments and reviews from our community and from the projects we integrate and work alongside.
If you spot something in our checklists that you think is no longer accurate or needs to be revised, or want to provide general feedback on Beefy's approach to risk assessment, don't hesitate to reach out in the [Beefy Discord server](https://beefy.finance/discord).
# Contracts & Timelocks
Last Update: April 2026
### Addressbook
All addresses used are open source and verifiable. A collection of useful addresses on Beefy's chains for DeFi development are stored on GitHub: [Addressbook](https://github.com/beefyfinance/beefy-api/tree/master/packages/address-book).
### Contracts
From the Vault UI, one can easily find the Strategy addresses and Vault addresses. Additionally, all Beefy vault contracts can be viewed on [app.beefy.com](app.beefy.comhttps://app.beefy.com/). One can use this dashboard for example to check the [harvesting and compounding rate of a vault](/faq/how-to-guides/how-to-check-harvesting-compounding-rate).
### Oracles
Beefy's contracts do **not** use external oracles. The problem with oracles is, in short, that its data can be inaccurate or manipulated, and unreliable oracles can lead to exploits. Because Beefy's contracts do **not** rely on external data in any form, such as asset prices, our vaults are **not** susceptible to flashloan exploits.
### Timelocks
Beefy ensures that all privileged functions and upgrades are protected by standardised smart contract timelocks.
Our strategy, vault and reward pool contracts (as well as any other contracts that handle user funds) are made ownable with ownership transferred to either the Beefy vault owner or the Beefy strategy owner on the relevant chain. Timelocked functions are then queued by the [Beefy Developer Multisig](#developer-multisig), and may be executed by individual contributors once the timelock has elapsed.
By default, a 6-hour timelock is configured for all strategy changes and upgrades. This allows sufficient warning and notice of significant changes, while allow Beefy to react rapidly to material changes or new risk vectors. Detailed of scheduled timelock transactions are published live to the Beefy Discord server in the #-citadel channel.
Vault and strategy owner addresses can be found in the [addressbook](#addressbook) under the Beefy protocol files.
### Developer Multisig
The Beefy developer multisig is staffed by Beefy's experienced senior developers and maintains responsibility for all privileged functions across Beefy's smart contracts. It is a 3 of 6 multisig
To effect these responsibilities, the dev multisig is set as either the direct owner of Beefy's contracts or as the owner of the timelock which in turn owns Beefy's contracts. The intention is that all privileged functionality should run through and be secured by the protection of the multisig.
All transactions are proposed either by members of the Developer Council or using automated bots to gather standardised calldata for common transactions. Only the Developer Council has signing rights, and the multisig facilitates no delegates or external roles.
The dev multisig is operating with best practices in line with Beefy's [multisig policies](#multisig-policies).
### Treasury Multisig
The Beefy's treasury multisig is staffed by Beefy's senior core contributors and maintains responsibility for gathering, custodying, deploying and spending Beefy DAO's treasury assets. It is a 4 of 7 multisig
Unlike the [dev multisig](#developer-multisig), the treasury multisig does not have access to any privileged functions or assets held by the Beefy protocol, and its functionality is solely linked to the Beefy DAO. Nonetheless, it secures millions of dollars of assets at any given time, and so great care and attention is paid to the signing and execution of transactions.
All transactions are proposed either by members of the Treasury Council or using automated bots to gather standardised calldata for common transactions. Only the Treasury Council has signing rights, and the multisig facilitates no delegates or external roles.
The dev multisig is operating with best practices in line with Beefy's [multisig policies](#multisig-policies). See the [Treasury](/dao/treasury) page for further information about the Beefy Treasury.
### Multisig Policies
Both Beefy's dev and treasury multisigs are operated in accordance with standard best practices for the operation of multisigs:
* Each signer is an independent human and distinct from all other signers;
* All signers are longstanding contributors to Beefy DAO who have been known and vetted over the course of several years;
* Signers are anonymous, and details of their precise signing capabilities and setup are kept confidential;
* All signers are located in different geographic locations from all other signers;
* All signers must be EOAs and not multisigs or other smart contract accounts where ownership is capable of being transffered or shared;
* Contributors with private pre-existing relationships (e.g. friends, colleagues, couples) may not sit on the same multisig as one another;
* A quorum of signers on any multisig should not be allowed to attend the same event and meet in person;
* No external delegations or roles are granted to either multisig, save for automated proposal generation by bots developed and maintained by the Beefy Developer Council;
* Signers are occasionally reshuffled, bringing different members of the contributor team onto the multisigs and ensuring that all multisig signers are active contributors;
* Regular advice and security updates are provided to all signers to ensure they are aware of best practices; and
* Private accounts for email, cloud storage and password management are provided to all signers, helping them to operate their roles without using personal or preexisting accounts or comingling their work.
Importantly, Beefy multisig signers are not doxxed or identity checked, and no personal data on our signers is stored. Where traditional institutions may rely on identification and audit trails to provide legal certainty and accountability, Beefy prioritises privacy and relies on modern technology and security standards to ensure the safe operation of multisigs.
Put simply: Beefy focuses on minimising the surface area for issues with our multisigs, rather than paths for recourse after issues have already arisen.
# Audits & Bounty
Last Update: January 2026
{% hint style="info" %}
For immediate access to Beefy's completed audit reports, visit the [`beefy-audits` repo](https://github.com/beefyfinance/beefy-audits).
{% endhint %}
To strengthen our mesh of security measures, Beefy also makes use of external assistance from industry-leading developers to identify problems and help craft solutions.
External support is typically *ad hoc* in nature, arising particularly around new product development and launches, and where major upgrades or novel bugs emerge. Though Beefy seeks to maintain relations with a wide range of external blockchain security experts and organisations, we do not have standing engagements with preferred providers (save for our ongoing bug bounty).
## Formal Audits
Beefy's contributor team have gone through over a dozen audits across the project's lifetime for different products and variations on Beefy's core design. Each of the completed audit reports is available in the [`beefy-audits` repo](https://github.com/beefyfinance/beefy-audits).
In the below table, we divide those audits into several core categories:
For auditors interested in working with Beefy, we maintain lists of potential providers, and will be happy to open a conversation and include you for consideration. Please reach out via the Beefy Discord to learn more.
## Audit Competitions
Audit competitions are a growing trend in DeFi to augment or substitute a traditional formal audit. Providers open up submissions to the public (and typically their own network of independent security researchers) and implement a process to review submissions alongside the project, looking for valuable contributions to be rewarded.
Unlike a traditional bug bounty, audit competitions aim to accelerate the process of reviewing a new codebase by incentivising many reviewers to evaluate the code simultaneously and in competition with one another. They guarantee a pot of prizes for submissions, encouraging participants to submit as many issues as they can in case there are few other submissions (meaning they take a larger share of the prize pot).
The downside of audit competitions is they can involve a huge amount of work from the team, and incentivise nonsense or low-quality submissions. Though the quality of reviewers can be very high, there are no assurances that actual participation will be of a high-quality, unlike a traditional audit. As such, competitions are typicall complimentary to (not contrasted with) audits and bug bounties.
Beefy hosted a [CLM contest](https://audits.sherlock.xyz/contests/303) with Sherlock in May 2024, receiving 134 submissions but finding only 1 medium-severity bug.
## Bug Bounty
Beefy has offered a bug bounty program with [ImmuneFi](https://immunefi.com/bug-bounty/beefyfinance/information/) since July 2021. ImmuneFi is a platform for white-hat hackers and security experts to identify DeFi projects with bounty programs for them to review. Successful bugs identified by participants (and submitted through ImmuneFi) will receive a payout from Beefy's bug bounty fund to incentivise cooperation and support.
Due to the nature of how ImmuneFi works, the program shows specific contract addresses that are included within scope. However, the Beefy protocol integrates several thousand contracts at any given time, meaning that it is not always possible to ensure every contract is included with the scope. Beefy will generally honour the bounty in respect of live operational products displayed in our web application (not retired or paused) if submitted via ImmuneFi.
Questions in relation to our bounty program and audits can be submitted to the contributor team through the [Beefy Discord server](https://beefy.finance/discord).
# Insurance
Last Update: February 2024
{% hint style="warning" %}
**Disclaimer:** Nothing on this page constitutes any formal insurance, legal or financial advice, or any recommendation to purchase or not purchase the products described herein. This page is intended for general information and educational purposes only. No warranty, whether express or implied, is given in relation to the information on this page. Beefy shall not be liable to readers for any technical, editorial, typographical or other errors or omissions associated with this page, or any harm, damage, losses or claims that may result from your use of this information. Always check the date of last update, to ensure the information on this page is not materially outdated.
{% endhint %}
Though Beefy does not offer insurance coverage directly to our users, there are a number of available products which offer cover for our protocol, smart contracts and users' portfolios. This page summarises the key types of DeFi insurance products that are available at present, some of the risks associated with them, and the different Beefy products that are available right now (including from our official partners and unaffiliated products).
## Why Insurance?
On a simple level, insurance can feel like a counterintuitive concept in DeFi, as the pace of change and technology development necessarily makes DeFi an inherently risky pursuit. But digging a bit deeper, we can observe that insurance is actually one of the earliest forms of decentralised financial products, in that it seeks to socialise risk and cost among thousands of willing participants, to ensure neither is concentrated at an individual level.
At Beefy, we recognise that insurance is a requisite component of a stable, modern financial system, as it safeguards against massive damage and disruption arising from unlikely or unknowable, but retrospectively inevitable risks and events. Insurance allows users to enter the DeFi ecosystem and interact with this technology in a safer and more measured way, with protection against downside risks. It also helps to facilitate institutional capital, which may have more stringent risk management requirements that would otherwise isolate them from the space. As such, we think insurance helps to develop and extend DeFi, paving the way for mass adoption.
However, insurance is a complicated area of finance. Each and every underwritten policy is ultimately unique and deals with different types and levels of risk. As a result, it is vitally important that our users do their own research before buying insurance, and ensure their chosen products are suitable for them and priced fairly. It is always prudent to make sure to: (a) read the provider’s documentation and policy documents; (b) research the provider's financial position/backing to ensure it has sufficient liquidity to cover a pay out; and (c) check to ensure the policy's coverage is appropriate for the kinds of risks you wish to ensure against.
## Types of Insurance
As DeFi expands, the list of available insurance products is growing in tandem, including from both corporate and decentralised providers. Some of the key types include:
* **Smart Contact Coverage** - covers a specific smart contract-based product for a range of common issues like contract bugs, multi-sig failures and economic attacks. **For example:** [InsurAce's Smart Contract Vulnerability Cover](https://docs.insurace.io/landing-page/documentation-1/cover-wording/smart-contract-cover).
* **Protocol Coverage** - covers a specific DeFi protocol for a range of common risks and issues, like contract bugs, economic attacks and governance attacks. **For example:** [Nexus's Protocol Cover](https://nexusmutual.gitbook.io/docs/users/types-of-cover/protocol-cover).
* **Token Coverage** - covers a specific token product (e.g. an LP or autocompounding vault) for cross-stack risks in the underlying assets and protocols that the insured product is built on. **For example:** [Nexus's Yield Token Cover](https://nexusmutual.gitbook.io/docs/users/types-of-cover/full-stack-coverage-with-yield-token-cover) (e.g. Convex 3CRV), which covers failures in the issuing protocol (Convex), the LP/farm protocol (Curve) and the underlying tokens (DAI, USDC, USDT and CRV).
* **Portfolio Coverage** - covers a particular wallet up to a specified value of loss, including all applicable assets from insured protocols which the wallet holds. **For example:** [Solace's Portfolio Insurance cover](https://docs.solace.fi/docs/overview/faq/cover-products).
* **Custody/Custodian Coverage** - covers risks associated with custodial wallets and arrangements with centralised entities, including halted withdrawals, custodian hacks and haircuts arising from mismanagement. **For example:** [InsurAce's Custodian Risk Cover](https://docs.insurace.io/landing-page/documentation-1/cover-wording/custodian-risk-cover), and [Nexus's Custody Cover](https://nexusmutual.gitbook.io/docs/users/types-of-cover/custody-cover).
* **De-peg Coverage** - covers risks in an individual token product that arise as a result of the value of the asset de-pegging (i.e. failing to hold market value in line with the underlying assets that it is supposed to reflect). **For example:** [InsurAce's Stablecoin De-Peg Risk Cover](https://docs.insurace.io/landing-page/documentation-1/cover-wording/stablecoin-de-peg-cover) and [Nexus's Yield Token Cover](https://nexusmutual.gitbook.io/docs/users/types-of-cover/full-stack-coverage-with-yield-token-cover), which includes a number of specific de-peg risks.
* **Staking Coverage** - covers several risks that arise out of blockchain network staking and validating, such as missed rewards and slashing losses. **For example:** [Nexus's ETH2 Staking Cover](https://nexusmutual.gitbook.io/docs/users/types-of-cover/eth2-staking-cover), which specifically covers Ethereum's proof-of-stake beacon chain.
* **Bundled Product Coverage** - covers a combination of different protocols, products or different risks to create a single product that covers the users' overarching needs. **For example:** [InsurAce.io's CRV+CVX Bundled Cover](https://files.insurace.io/public/en/cover/Bundle_CRV_CVX_v3.0.pdf), which targets Convex users with additional coverage for failures in Curve (which Convex is built on).
## Risks
Though Beefy advocates for the benefits of insurance, we also warn our users that insurance products themselves give rise to a number of risks which may result in your investment in the products being lost. In particular, we'd suggest users consider:
* **Coverage Amount** - insurance products typically require that you state upfront the amount of coverage that you want to purchase, typically denominated in fiat currencies. You may be encouraged to buy coverage up to the current value of your investment, or even above that. The coverage amount is typically not a guarantee of the amount you will be paid out, but does limit the maximum value of a pay-out. Furthermore, as the value of your assets change, the suitability of your coverage level will be impacted. For instance a sharp drop in the value of your portfolio will reduce the likelihood of claiming for the full coverage amount you obtained beforehand. Be sure to actively monitor your coverage levels.
* **Coverage Limitations** - coverage tends to be constrained to a closed list of claimable risk events (e.g. smart contract vulnerability covers "malfunction or programming flaw, or unauthorized, malicious, criminal attacks, hacks or exploits of any malfunction or programming flaw"). This may mean certain foreseeable events that you want cover for are not included in the product (e.g. a de-peg does not fall within the above definition, so is not covered by smart contract vulnerability cover).
* **Captured Products** - insurance products do not always seek to actively point out the limitations of their coverage and which products aren't captured. For instance, portfolio coverage may be tied to products which can be identified by the protocol, and may miss newer products or blockchains, resulting in inadequate coverage for your needs. As the product is general and the UI is user-friendly, you likely won't be told until your claim is rejected that specific products weren't captured in the coverage you purchased.
* **Pay Out Process** - all insurance products have strict conditions for paying out for a claim which must be met. For instance, some protocols require members to vote/decide on a claim before the protocol will pay out, which is a factor that is typically outside of users' control and unrelated to the pay out event. Be careful to check the process carefully when assessing whether a product is right for you, including assessing how frequently the product pays out for claims.
* For example, insurance covering Beefy's protocol or smart contracts will likely pay out if our contracts fail, but will not pay out if the underlying assets that our contracts are built on top of fail. This happened with the Terra UST collapse, where our smart contracts worked as intended, even as the underlying assets' value sank towards zero.
* **Providing Coverage** - some decentralised insurance providers (e.g. InsureDAO, Bridge Mutual) offer peer-to-peer insurance products, where users can provide coverage to the protocol as an investment in exchange for a share of the premiums paid by coverage purchasers. Beefy warns our users that these products expose coverage providers to an asymmetric risk of losing your **entire** investment if there is a pay out event under the policy.
* Providing insurance coverage is effectively a bet on the security of the underlying protocol or smart contracts. Though our [SAFU Standards](/safety/beefy-safu-practices) are Beefy's top priority, we would not encourage ordinary users to bet on the security of any rapidly changing DeFi technologies.
* Where Beefy can offer you a similar rate of return on your assets whilst avoiding the pay-out risk, we know where we'd rather invest our funds... :cow: :cow: :cow:
## Partner Products
To bring the benefits of DeFi insurance to our users, Beefy has partnered with a selection of the leading insurance providers in the space, to create products which offer coverage over our protocol, products and contracts. At the time of writing, these are:
### Nexus Mutual
Nexus Mutual is an Ethereum-based insurance alternative that provides coverage against specific protocols, yield tokens and custodians (i.e. centralised exchanges). It offers protocol coverage for Beefy across the vast majority of our deployed chains.
Unlike most other providers, Nexus is a discretionary mutual whose members receive insurance-like protection, though it doesn't formally sell insurance. The project uses aligned incentives to enable risk-sharing among all its members, as members act as risk and claim assessors, whilst contributing capital to the protocol. Ownership of Nexus Mutual’s token, NXM, is used to buy cover and navigate the claims and risk assessment process. Holders can also take part in the Mutual's governance too.
Nexus offers a range of products including general protocol cover (i.e. covering all different products offered by the protocol) as well as "yield token cover", which covers the full stack of a yield bearing asset (e.g. base assets, liquidity pool and autocompounding vaults). Nexus also offers other novel products such as Ethereum 2.0 staking cover, and custodian cover which protects against the risk of loss caused by keeping assets in the custody of a centralised exchange.
For more information, see our blog post on the partnership [here](https://beefy.com/articles/cover-your-deposits-with-nexus-mutual/), and the Nexus Beefy product page [here](https://app.nexusmutual.io/cover/buy/get-quote?address=0x453D4Ba9a2D594314DF88564248497F7D74d6b2C). Details of the different types of coverage and their terms and conditions are available in Nexus' documentation [here](https://nexusmutual.gitbook.io/docs/users/types-of-cover).
### Open Cover
[Open Cover](https://opencover.com/) is a decentralized coverage distributor, that operates novel solution to access the ample coverage available on Ethereum from the comfort of lower-cost rollup chains. With Open Cover, you can obtain coverage from Nexus Mutual for a fraction of the cost on Optimism, Arbitrum or Base, by paying a small fee to Open Cover. For smaller positions, this enables access to coverage that otherwise would be prohibitively expensive in light of Ethereum gas fees. Open Cover's docs are available [here](https://docs.opencover.com/).
## Deprecated Products
Beefy has also partnered to issue other coverage products which have since been deprecated - i.e. no new first-party products are being issued on the open market. Because of the nature of coverage, residual claims can survive for longer periods of time after a product has been deprecated, so the details of these products appear below.
### InsurAce.io
InsurAce is a multi-chain insurance provider deployed on a range of chains including Ethereum, BSC, Avalanche, and Polygon. It offers coverage against Beefy smart contract vulnerability over more than half of the chains Beefy is deployed on.
The precise make up of InsurAce's organisational is not entirely clear, though InsurAce has some incorporated legal forms (e.g. InsurAce Global Limited in the UK). It's protocol is made up of two parts: an insurance arm and an investment arm. The investment arm generates profits from fees collected to fund their insurance activities. Users pay a fee (typically 2-5% APY) when using covered smart contracts and are reimbursed for their deposits if it fails.
InsureAce operates a dedicated claims department that will review the different types of claims that can be submitted and vote on the outcome. The claim is first investigated by InsureAce's Advisory Board, which includes experts in Insurance, Security and Legal/Compliance. InsurAce are also aiming to develop a decentralised governance process over time, including the use of community Claim Assessors (who are $INSUR holders that have staked their tokens on the platform) to decide the outcome of claims. However, at the time of writing, the [Claim Assessor page](https://app.insurace.io/claim-assessor) is not live, and the current state of affairs is not made clear on the protocol site.
For more information, see our blog post [here](https://beefy.com/articles/get-to-grips-with-beefy-s-smart-contract-insurance-provided-by-insurace/) and find the InsurAce Beefy product on the coverage products page [here](https://app.insurace.io/coverage/buycovers) (Product ID #110). You can find raw data on InsurAce's coverage [here](https://data.insurace.io/cover-records).
### Solace
Solace was a decentralised insurance protocol. It offered coverage for funds invested in Beefy as part of its all-encompassing portfolio insurance product. For more information, see Solace's twitter thread on the Beefy partnership [here](https://twitter.com/SolaceFi/status/1491533263936098305?s=20\&t=jZMt6Lw4uyPfW5NUPtW6UA), and check out Solace's documentation [here](https://docs.solace.fi/). Solace [ceased operating](https://medium.com/solace-fi/to-the-valued-solace-community-0d106d1ee7be) in November 2023.
### Comparison
Criteria
InsurAce.io
Nexus Mutual
Solace
Deployed Chains
Ethereum, BSC, Polygon, Avalanche
Ethereum
Ethereum, Polygon, Aurora, Fantom
Beefy Chains Covered
9 chains, including BSC, Polygon and Fantom
15 chains including BSC, Polygon and Fantom
Not stated. Portfolio detected through Zapper. Includes coverage beyond deployed chain.
## Unaffiliated Products
As Beefy is entirely open source and public, anyone is free to build on top of our products and code. However, this transparency can cause some confusion for ordinary users as to which products are built and tested by our team, and which aren't. Some insurance providers seek to add to this confusion by stating that their products are "official" or "verified", when they are nothing to do with Beefy. It is ultimately up to the user to do your own research and check that the product is what you think it is.
Below is a list of known products insurance products that offer coverage for Beefy's products or protocol, but are not officially offered in partnership with Beefy and have not been formally verified by our teams. Use at your own risk, and always do your own research.
{% hint style="danger" %}
Readers are warned to note and consider the "Providing Coverage" risk in the [#risks](#risks "mention") section above when considering these unaffiliated products.
{% endhint %}
# General
## Is Beefy audited?
Our first auditor was DefiYield, which audited $BIFI token, the RewardPool and all the timelocks.
Beefy is also audited by Certik, which guarantees the robustness of our smart contracts and the safety of funds invested through Beefy.
Certik has audited some of the most complex and reusable investment strategies used within the platform. This ensures the safety and sturdiness of important smart contract aspects that the majority of our users interact with.
[All Beefy audits can be found here.](https://github.com/beefyfinance/beefy-audits)
## What is a yield optimizer?
A yield optimizer is an automated service that seeks to gain the maximum possible return on crypto-investments, much more efficiently than attempting to maximize yield through manual means.
Each vault has its own unique strategy for farming, which normally involves the reinvestment of crypto assets staked in liquidity pools. At the most simple level, it farms the rewards given from staked assets and reinvests them back into the liquidity pool. This compounds the amount of interest received and increases the amount staked that the yield is based on. A yield optimizer can repeat this up to process up to thousands of times a day.
This fairly simple method is the principle reason behind the large APYs found on Beefy. Compounding fees are amortized among all vault participants, making it cheaper for the user.
## What’s the difference between APR and APY?
APR (Annual Percentage Rate) is the yearly interest, minus fees. This does not include compounding effects that occur from reinvesting profits. If you were to invest $100 with 100% APR, you would make $100 in profit in a year time.
If you however reinvest your profits regularly, you will compound your interest. This calculated over a year gives you your APY (Annual Percentage Yield). The more often you compound your interest, the greater the difference between APR and APY.
## How does APY work?
APY is the annual percentage yield offered from a particular investment. This takes into account compound interest, giving you an accurate idea of your returns compared to simple interest.
Large APYs in the percentage of thousands are possible with investments that provide daily yields of 1% or more. Due to your liquidity pool rewards being constantly farmed and reinvested, the interest compounds on larger and larger amounts.
## What do Vault Daily and Trading Daily mean?
Trading Daily means how much your liquidity tokens will increase in value. Liquidity pools share trading fees amongst all liquidity providers, as introduced by the [Uniswap liquidity model](https://docs.uniswap.org/protocol/V2/concepts/advanced-topics/fees). Trading Daily is affected by trading volume and the percentage of swap fees allocated to liquidity providers.
Vault Daily means how much your token will increase in number. Due to the vault constantly farming rewards, and reinvesting that, your deposited token amount will increase. Vault Daily is affected by the yield farm rewards (i.e. additional incentives besides trading fees), such as CAKE on Pancakeswap.
Trading Daily and Vault Daily can be multiplied by 365 to compute Trading APR and Vault APR. Vault APR is then converted to Vault APY to factor in compound interest. The displayed total APY percentage is calculated as follows:
$$
APY = (1 + vaultAPY) \* (1 + tradingAPR) - 1
$$
{% hint style="info" %}
To calculate the Trading APR, Beefy uses on-chain data and a 24 hour period to determine the trading volume and subsequent fees, whereas most DEXes use a 7 day period. This may lead to differences in the displayed APY when compared with a DEX, but know that it is due to the calculation method. In fact, we argue that Beefy is more accurate because it uses a shorter time span which reflects changes in Trading APR sooner.
{% endhint %}
A handy tool to convert APR to APY is: [APRtoAPY.com](https://www.aprtoapy.com)
## How do I contribute to Beefy?
Beefy is a community powered project from day one. If you want to join the ever growing pool of contributors, it depends what you would like to work on. We have open places for Solidity devs, or devs wanting to start a career in Solidity, to join as strategist and deploy vaults (and earn passive income from the strategist fees). Beefy is on a lot of chains and there are often opportunities for simple and complex vaults. You can start with simple ones and then progress to the harder ones as your knowledge of Solidity grows. You don't have to be the best right at the start, and rest assured that there is a rigorous review process in place to ensure safety and quality. You can reach out to our lead strategists in [Beefy's Discord](https://discord.gg/yq8wfHd) in #strategy-devs.
Beefy would also like people to work on non-strategy projects; pretty much anything you can think of can be formulated into a grant. Speak with others in the cowmoonity about projects and join one of the teams or lead one up yourself, you can be paid for any work you do to make Beefy better. A quick list of previous grants: [here](https://forum.beefy.finance/c/grant-ideas/11) and [here](https://forum.beefy.finance/c/grant-requests-b1/10). Beefy V2 is an ongoing project that requires all kinds of devs, not just technical ones; design input is crucial to improve the UI/UX.
Beefy's [GitHub](https://github.com/beefyfinance) embraces the idea of open collaboration, hence many of the repositories are open-source. We use CONTRIBUTING.md files to allow people to just make contributions or recommendations by means of Pull-Requests. You can get started even just by updating the Git docs or fixing a typo, it helps you get closer to the team of contributors.
If you have an interest in business development you could help with partnerships and proposing business decisions to the DAO. Beefy is still a relatively new business that can use talented people to help advise the core team.
There is marketing that you can contribute to too, if you can write a decent tweet then you can help out in #tweet-development. The [Discord](https://discord.gg/yq8wfHd) has a #social-watch channel where links to Beefy mentions on social media are posted, you can help out with user queries there or in the [Discord](https://discord.gg/yq8wfHd) or [Telegram](https://t.me/beefyfinance) itself. Moderators of Discord and Telegram are (variably) paid positions too and are usually the first line of customer support.
The best way to get involved is to just go ahead and get started, help where you can, contribute to discussions and collaborate with everyone.
## What is the difference between a Vault and an Earnings Pool?
In a Vault you earn more of what you deposited into it, with compound interest (APY). In an Earnings Pool you earn a different token than the asset you deposited, with linear interest (APR).
An example is the BIFI Maxi Vault, in which you earn more BIFI exponentially, and the many BIFI Earnings Pools, in which you earn linear interest in the form of $ETH, $BNB, $AVAX and more.
## Why does it cost so much gas to deposit into a Beefy vault?
Many of Beefy's vaults "[Harvest on Deposit](/beefy-products/vaults#what-is-harvesting-on-deposit)". This means that when you deposit into the vault, you are also calling the harvest function. Calling the Harvest function is more complex than a simple deposit and thus has a higher gas limit/fee. Beefy does this so that it is impossible for malicious actors to steal yield so a withdrawal fee is not required. This greatly benefits long-term investors since the withdraw fee can be removed.
Almost all of the vaults on more inexpensive chains like Fantom and Polygon harvest on deposit. You can also tell if a vault harvests on deposit if there is no withdrawal fee.
As the Harvest Caller, you will also receive some of the wrapped native chain token in as a reward for calling the harvest. See [Beefy Fees Breakdown](/ecosystem/beefy-bulletins/beefy-finance-fees-breakdown) for more information on the Harvest Caller.
## How can I find out how much earnings I have accumulated?
Your rewards are added to your deposited token amount on each harvest and compound cycle. You can use a DeFi dashboard that will be able to calculate exactly how much profit you have made on your investments. External tools such as [TopDeFi](https://thetopdefi.com/) will read your wallet address and give you an accurate picture of your initial investment and current earnings.
# Crosschain Zaps
Last Update: April 2026
### What are crosschain zaps?
Crosschain zaps are a massive upgrade to the Beefy user experience that lets you deposit into thousands of different yield strategies across multiple networks with a single click.
You can now enter Beefy products in a single transaction using any supported token across 10 different blockchains.
You no longer need to figure out manual bridging or learn the nuances of individual networks—just select a route, approve the token, and zap.
### Why did Beefy build crosschain zaps?
Traditional yield farming is often difficult, time-consuming, and risky. To get into a single vault, a user might have to navigate and wrap funds through 5 or 6 different protocols. By bundling all of these complex steps into one straightforward workflow, zap blurs the lines between active yield farmers and set-and-forget investors, making high yields accessible to users of all skill levels.
### How do crosschain zaps work under the hood?
Crosschain zaps aggregate and automate processes like simulating deposits, fetching quotes from multiple aggregators (like KyberSwap or 1inch), calculating precise swaps, and executing the crosschain bridge. On a technical level, it relies on three core components:
* The “BeefyZapRouter”: a contract on the source chain that receives your transaction and processes arbitrary logic to deploy your assets for bridging and zapping.
* The “Hook Executor”: a private Beefy service that listens for your bridging event, fetches a cryptographic attestation from Circle’s API, and relays the message to your destination chain.
* The “CircleBeefyZapReceiver”: a contract on the destination chain that receives the bridged message, mints your bridged funds, executes the final deposit into the target Beefy Vault, and returns your receipt token (mooTokens).
For a more detailed explanation, see the [Zap page](https://docs.beefy.finance/beefy-products/zap#beneath-the-hood).
### How do I know what assets I have to zap?
A crosschain zap starts as a normal zap: after clicking deposit or withdraw, you’ll see a list of all supported chains and the top assets you have on them (shown with their token icons). Clicking a chain shows you a detailed overview of all of the assets on that chain which you can use to zap with.
### Which networks can I zap across?
Currently, crosschain zaps are available on 10 networks: Ethereum, Base, Arbitrum, OP Mainnet, Polygon, Avalanche, Linea, Monad, HyperEVM, and Sonic.
### What are the fees for crosschain zaps?
For crosschain zaps there are fixed and variable price elements.
The fixed element ($) - known as the Relay fee - is $0.10 for all chains save for Ethereum and Linea (where it’s $1). It's charged by Beefy to cover the cost of claiming bridged assets and initiating deposits.
The variable element (%) is an aggregate of Beefy’s swap fees and bridge fees charged by CCTP. They're applicable on any step that swaps or bridges respectively. Zap fees displayed on the app are an approximation - check the tooltip for a precise breakdown.
For a more detailed breakdown of fees, see the [Zap page](https://docs.beefy.finance/beefy-products/zap#fees).
### I’m not seeing crosschain zap as an option for my chosen vault. Is this a glitch?
Though crosschain zap supports almost 1,000 Beefy products, not all products are currently zappable, meaning the option to zap from other chains will not be shown. Underlying protocols like Balancer V3 and Pendle require complex integrations to facilitate zaps, meaning zap may only be supported for some products or chains, or even for none at all. To find products which benefit from crosschain zaps, filter to the 10 supported chains and then check the “Zappable” tag in the filter bar.
### I tried using a crosschain zap but my transaction didn’t fully complete. Where did my funds go?
Depending on where in the process things stalled, your funds may be on the source chain in your deposit asset or USDC, or on the destination chain in USDC, the product’s deposit assets or the product’s deposit token. Your funds are typically returned to your wallet address, or waiting to be minted via CCTP on the destination chain (from which they can always be recovered later).
To begin with, check your transacting wallet’s balances and history, looking for any indication of additional USDC or deposit assets arriving in your wallet. If neither are found on the source or destination chain, reach out to Beefy in the #tech-support channel on our Discord server, and we will assist with minting from CCTP on the destination chain.
The Beefy web application displays the progress of zaps and invites users to continue zapping where the process is interrupted. Don’t panic if you don’t see these notifications or accidentally close the app, the process can always be resumed if you reach out to us.
### Why do crosschain zaps use Circle CCTP for bridging?
Circle's Cross-Chain Transfer Protocol (CCTP) is the perfect intermediary because it offers a consistent and uniform experience across highly fragmented blockchain architectures. Because USDC is stable and prioritized across DeFi, Beefy can use it to securely bridge value without having to stitch together a complicated fabric of different native tokens and smart contract standards.
### How are my assets secured during a crosschain zap?
Crosschain zaps build exclusively on Circle CCTP, so all bridged assets are secured by Circle’s technology throughout the bridging process.
CCTP is a crosschain messaging service (meaning it orders the release of equivalent assets on the destination chain) rather than a canonical bridge (which guarantees the storage of underlying assets on their native chain). Though traditionally canonical bridges have been viewed as offering stronger guarantees as to the backing and security of the underlying assets, in Circle’s case native USDC is all backed by underlying US dollars supported by a uniform guarantee from Circle. As such, all of the assets used during a crosschain zap’s bridging process carry the exact same level of security and legal guarantees throughout the process.
CCTP’s positioning as a messaging service helps to dramatically lower the time and cost of bridging transactions, making it the perfect choice for DeFi integrations when coupled with their trusted institutional backing.
### Are crosschain zaps safe? What happens if a crosschain transaction fails in the middle?
Beefy built the UI and the smart contracts to be highly robust and capable of handling external issues with swap and bridge providers. On the destination chain, the final zap execution is wrapped in a "try/catch" mechanism. This means if a step fails, the transaction doesn't simply revert and get stuck; instead, it safely triggers a recovery path to ensure a proper refund or recovery outcome. Additionally, the Zap V3 core router codebase that this is built upon was audited by OpenZeppelin.
# Infographics
Explaining Beefy using simple infographics
This page helps to explain various key aspects of Beefy's vaults, tooling and protocol using easy to understand infographics and short descriptions. Though the services we offer are advanced and highly technical, we agree with the adage that *"if you can't explain it simply, you don't understand it well enough"*.
## Vault Yield Farming
At Beefy 'you earn what you stake', regardless if this is a liquidity pool (LP) token or a single asset. In this example, staking CAKE-BNB LP will result in more CAKE-BNB LP over time. This effectively grows your share in the liquidity pool and thus allows for more and more rewards over time. All of this with Beefy doing the required work, while you can sit back and relax!
## Vault Fee Structure
"What you see is what you get": the fees are already accounted for in the displayed APY!
More on the vault fees [here](/beefy-products/vaults#what-is-the-vault-fee-structure).
## Beefy ZAP
Our Beefy ZAP tooling automatically builds the deposit (or withdraw) positions you need for our Beefy vaults from other assets, thereby saving you the time, energy and cost of obtaining the necessary assets and building the necessary liquidity positions yourself. Here's a guide on [How to Use Beefy ZAP](/faq/how-to-guides/how-to-beefy-zap).
Our ZAP V1 tool automatically builds liquidity pool (LP) tokens from any of the base deposit assets, such as from BNB for the CAKE-BNB LP2 shown above. When the time has come that you want to withdraw from a LP vault, ZAP V1 also supports withdrawing back into any base asset, for instance you can exit into CAKE instead of BNB. This saves you the hassle of manually adding and removing liquidity at a yield farm.
ZAP V2 goes one step further, so users can enter supported vaults from any of a selection of blue chip, native or stablecoin assets, regardless of whether the asset forms part of the vault's asset base.
The ZAP V2 tool takes things one step further, using the power of DEX aggregators like 1inch to add initial swaps to the process, so users can move from common blue chip tokens (e.g. WBTC, ETH), native tokens (e.g. MATIC, BNB) or stablecoins (e.g. USDC, USDT, DAI) into the underlying tokens needed for the liquidity position. That way, you can access our market-leading returns on new products without handling anything but the tokens and stables you already have in your wallet.
The ZAP quote that's displayed during the deposit or withdraw process already has the ZAP fee taken into account. Additionally, the ZAP fee is only deducted from token swaps. The fees first accumulate in a batch treasury, and after some time are swapped to stables and sent to [Beefy's Treasury](https://app.beefy.com/treasury). The original Beefy ZAP V1 remains free to use.
{% hint style="info" %}
When using ZAP, always check your quote! While ZAP does protect you against market slippage (price changes at the time of order and time of fulfillment), it does **not** protect you against price impact (how much your transaction will change the price of the tokens in the liquidity pool). As a general rule, the smaller the liquidity of the asset, the larger the risk of price impact.
{% endhint %}
## Beefy Launchpool Boost
When a vault gets boosted in Beefy's Boost, you earn both the base asset and the partner's token! For more info, read the Boost FAQ [here](/beefy-products/boost).
# mooVaults APY
## What is the APY?
Let's look at a typical yield farm, where they state an APY (annual percentage yield) as +100% for example. The traditional definition of APY ***is the real rate of return earned on an investment taking into account the effect of compounding earnings***. Using this terminology would indicate that the yield farm was compounding earnings for you. That is simply not the case. A more applicable terminology to use would be APR (annual percentage rate), meaning the annual rate earned through an investment. By definition this would mean that your 100% yield farm would double your original investment at the end of year 1 without reinvesting any earnings. But what about if you reinvested that entire amount the next year and the year after that?
## Understanding Exponential Growth (Compounding)
Growth whose rate becomes ever more rapid in proportion to the growing total number or size. The simple formula for this is ***growth = (1 + r)^x*** , where 'r' = return and 'x' = number of 'times'. For example, your money doubles every year if you get 100% yearly return. After 3 years you would have 8x your original investment.
## Ok, so what REALLY is the APY?
A typical investment does not just pay out on a yearly basis, but in smaller terms (ie: daily, monthly, etc). For yield farming, returns are even paid out on a per block basis. With an average of 28,800 blocks a day and cheap transaction fees this can allow for a significant amount of exponential growth or compounding of your return. Let's look at how to break that down...
* Compound = **P \* (1+r/n)^nt** Example : 100 \* (1+1/12)^(12\*1)
* P = principal or starting balance
* r = APR = 100%
* n = compounding periods = 12 months
* t = time = 1 year
* The simple APY calculation in excel can also be stated as =EFFECT(r, n)
# How-To Guides
{% content-ref url="/pages/-MKPlFREnjJBFAYJEzz4" %}
[How to deposit in a Vault](/faq/how-to-guides/how-to-deposit-in-a-vault)
{% endcontent-ref %}
{% content-ref url="/pages/-MKPms5q7l62Q7Vf0kKE" %}
[How to Add a Custom Token to Metamask](/faq/how-to-guides/how-to-add-a-custom-token-to-metamask)
{% endcontent-ref %}
{% content-ref url="/pages/-Max2mRREHQVZtTGHNao" %}
[How to Add and Remove Liquidity](/faq/how-to-guides/how-to-add-remove-liquidity)
{% endcontent-ref %}
{% content-ref url="/pages/-MaxTXfuPWfWXOblaJRQ" %}
[How to use Beefy ZAP](/faq/how-to-guides/how-to-beefy-zap)
{% endcontent-ref %}
{% content-ref url="/pages/-MYopsjzbeCQfOJ28dN8" %}
[How to add and switch networks on Beefy](/faq/how-to-guides/how-to-add-and-switch-networks-on-beefy-finance)
{% endcontent-ref %}
{% content-ref url="/pages/-MZiV-E2G0t\_1NVJLaP-" %}
[How to check the harvesting and compounding rate of a vault](/faq/how-to-guides/how-to-check-harvesting-compounding-rate)
{% endcontent-ref %}
# How to deposit in a Vault
This visual guide will walk you through every step in depositing funds in a Vault
## Prerequisites
* You must have the vault's underlying token(s) in your wallet. See here how to fund your wallet: [Funding your wallet](/get-started/funding-your-wallet)
* You must use a supported wallet, such as Metamask or Trustwallet: [Connecting your wallet to Beefy](/get-started/connecting-your-wallet-to-beefy).
## Walkthrough
### 1. Go to the [Beefy app](https://app.beefy.com/) page:
Screenshot date: 10 October 2022
Again, make sure that your wallet is connected and that it is funded with tokens.
### 2. Use the filters to find a vault you want to deposit into:
The blockchain logos, the preset selection buttons and the search field all act as filters.
### 3. Example of filter usage
In this guide, we will use the BIFI Maxi vault on Arbitrum as an example:
Note that the BIFI Earnings Pool, in which you can earn WETH by depositing BIFI, also shows up. Open the BIFI Maxi vault by clicking anywhere in the field above.
### 4. Inside the BIFI Maxi vault:
There is a lot of information inside the vault, such as TVL (Total Value Locked), Price and APY (Annual Percentage Yield) historical rates, the [Broken mention](broken://pages/-MfExLtJdEBcKnLQrqlZ), Token Asset details, and the Vault's compounding strategy ([Strategies](/beefy-products/strategies#what-is-a-vault-strategy)).
### 5. The Deposit and Withdraw module:
The vault already sees we have 1 BIFI available in our wallet to deposit. There is a "Buy Token" link provided in case you do not have any BIFI or wish to buy more BIFI to deposit, as well as a "Bridge BIFI" button to bridge BIFI from another blockchain to Arbitrum. A deposit field and a "Max" button are used for entering the exact amount of BIFI you want to deposit. Furthermore, the Beefy Vault Fees ([Vaults](/beefy-products/vaults#what-is-the-vault-fee-structure)) are shown.
### 6. An example deposit:
In this example, we first click the "Max" button to deposit all the BIFI in our wallet, followed by clicking on the "Deposit All" button.
When it is the first time you deposit in this vault, you need to grant permission to the vault's contract and allow it to access your funds:
In the next transaction you will be actually depositing in the vault:
In summary, depositing into a new vault always requires two transactions: one for approving the spending permission and one for the actual deposit.
### 7. Deposit confirmation:
Once the transaction succeeds, a message will pop up confirming the deposit and it contains a link to the transaction in the block explorer. It is very important to understand that your wallet now holds a tokenized proof of deposit called a "mooToken" ([Vaults](/beefy-products/vaults#what-are-mootokens)). This mooToken is required to withdraw from the vault, don't lose it!
On the block explorer page of the deposit transaction you can find out that the mooTokens are indeed supplied to your wallet after depositing in the vault. The token transfer will look something like this:
Since mooTokens are interest-bearing, they are more valuable than their "normal" token counterpart. This is also the reason why the mooToken amount does not 1:1 match with the token amount initially deposited ([Vaults](/beefy-products/vaults#how-do-mootokens-earn-interest)).
That's it, once the harvest function on this vault is called, you are already earning yield!
# How to Add a Custom Token to Metamask
Here's how to add a custom token to Metamask. This guide uses BIFI as an example.
## Visual Walkthrough
#### 1. Open Metamask and click 'Assets' to see the tokens in your wallet
#### 2. Scroll down to the bottom and click 'Add Token'.
#### 3. Click 'Custom Token'
#### 4. Past the contract address for BIFI into the 'Token Contract Address' field
BIFI token BNB Chain Contract Address : [0xCa3F508B8e4Dd382eE878A314789373D80A5190A ](https://bscscan.com/token/0xCa3F508B8e4Dd382eE878A314789373D80A5190A)\
\
The BIFI token Contract Address on other chains can be found here: [Contract Addresses](broken://pages/-M_6Sqduw-sWh1CZcOBL)
#### 5. Click 'Next'
#### 6. Click 'Add Tokens' to add the new token
#### 7. Moooo! BIFI should appear in your assets list so it's easier to track and use
# How to Add and Remove Liquidity
In this guide you will find the required steps how to Add and Remove Liquidity as well as staking and unstaking it from the vault.
As an example, we are going to work with BIFI-BNB LP in this guide. In a liquidity pool, both BIFI and BNB need to be provided at a 50/50 ratio value wise. Since we start with 100% BNB, this guide covers swapping BNB to BIFI too.
## Adding liquidity
### 1. Click "Buy Token"
### 2. Confirm the "Token imported" screen on PancakeSwap
### 3. Swap BNB for BIFI
Our wallet currently holds 4.0757 BNB; we will use a maximum total of 4 BNB to provide liquidity. Since we need to provide liquidity at a 50/50 ratio value wise, we will need to swap 2 BNB for BIFI first.
Confirm Swap in the next pop-up screen.
### 4. Click "Add Liquidity"
### 5. Click "MAX" for BIFI input, Approve BIFI and Supply Liquidity
### 6. Confirm Supply
### 7. The vault now shows a balance!
Click on the vault to open up the deposit and withdraw menu.
### 8. "Approve"
### 9. "Deposit All"
That's it! We now created liquidity and deposited BIFI-BNB LP in the vault. You can check [this guide](/faq/how-to-guides/how-to-check-harvesting-compounding-rate) to see when the vault will harvest rewards and compound for more BIFI-BNB LP tokens.
## Removing Liquidity
### 1. "Withdraw All"
Note: withdrawal fees will be deducted from your deposited token amount.
### 2. Go back to [PancakeSwap](https://exchange.pancakeswap.finance/#/pool)
and head over to the Liquidity section. It will show the BIFI-BNB LP tokens under "Your Liquidity"
### 3. Click "Remove"
In the next screen, click "Max" and Approve", and then "Remove".
### 4. Optional: Swap BIFI back to BNB
# How to use Beefy ZAP
One-click Beefy Vault Investing!
Beefy ZAP lets you create liquidity pool tokens and deposit into Beefy vaults with just one transaction. You no longer need to [manually add and remove liquidity](/faq/how-to-guides/how-to-add-remove-liquidity)! Our ZAP tooling is a simple, quick and safe solution that eliminates the need for you to handle complicated LP tokens or obscure tokens, and even saves you from needing to leave the comfy environs of the Beefy app.
This page sets out a short tutorial on depositing and withdrawing into Beefy vaults with our different ZAP tools. For a higher-level conceptual explanation of our ZAP tooling, see the [Infographics](/faq/infographics#beefy-zap) infographics section.
{% hint style="info" %}
When using ZAP, always check your quote! While ZAP does protect you against market slippage (price changes between the time of order and time of fulfillment), it does **not** protect you against price impact (how much your transaction will change the price of the tokens in the liquidity pool). As a general rule, the smaller the liquidity of the asset, the larger the risk of price impact.
{% endhint %}
## Example Vault
{% hint style="info" %}
Last Update: January 2023. As the site is under constant development, the interface that you see may vary slightly from the below screenshots over time.
{% endhint %}
For the purposes of these tutorials, we will use Beefy's stMATIC-MATIC sLP vault for the Dystopia DEX on the Polygon blockchain. This vault supports both ZAP V1 and ZAP V2.
The first step is to navigate to the relevant page for the vault you want to enter. For this tutorial, we will use the stMATIC-MATIC sLP vault for the Dystopia DEX on the Polygon blockchain.
For those following along with this tutorial, just navigate to the relevant page for the vault you would like to enter. However, be aware that our ZAP tools are not available for every vault on every blockchain, so you should check at this stage whether the deposit token dropdown menu under *"Select token"* does permit deposits with different assets. Make sure to also *"Connect Wallet"* before trying to deposit.
The second step is to check which tokens you can use for the deposit. Without ZAP, you can only deposit the vault asset (e.g. the LP token at the top of the list). For V1, you can deposit the underlying assets of the vault (e.g. WMATIC, stMATIC or MATIC). For V2, you can deposit from a broader range of other assets (e.g. USDC, USDT, DAI, etc).
Where ZAP V2 is available and you select a token that can be used for either V1 or V2, you will also be able to decide which tool to use. To switch between the two, look for the side arrow on the *"Beefy"* header at the top of the *"Zap Route"* box.
Where both ZAP V1 and ZAP V2 are available for your chosen deposit asset, the Zap Route box allows you to select your preferred tool/provide to use. Click the side arrow on the "Beefy" header.
The interface will then offer you to *"Select provider"* and show all available ZAP providers and tools that you can use. In this case, you can select between ZAP V1 (or *"Beefy"* shown below) or ZAP V2 (or *"Beefy x 1inch"* shown below).
The interface allows you to select between using Beefy's own tool (using ZAP V1) or alternatively a swap aggregator like 1inch (using ZAP v2).
## ZAP V1: Entering Vaults
To use ZAP V1 for deposits, ensure you've selected the *"Deposit"* tab at the top of the box shown at the right hand side in the image below. Use the *"Select token"* dropdown to select one of the underlying assets for the vault (e.g. WMATIC, stMATIC or MATIC), but not the main deposit token (e.g. stMATIC-MATIC sLP). You can then enter the amount of the token you wish to deposit from your wallet, or hit *"MAX"* to deposit all of your tokens at once.
The UI will then display an estimate for how much of the main deposit token (e.g. stMATIC-MATIC sLP) you will receive and then deposit through the ZAP V1 workflow. Below, the *"Zap Route"* box shows the different steps of the workflow and estimates for how much of each token will be received and used in each part of the transaction. Please note that it is impossible to know in advance exactly how much you will receive for the swaps in a ZAP workflow, so the final amounts may vary slightly from the estimates.
For the ZAP V1 deposit workflow, select one of the underlying assets in the vault and input the quantity of that token you wish to deposit into the vault.
To execute the proposed transaction, click on *"Deposit"* or *"Deposit All"*, and your chosen wallet will trigger a transaction (possibly including an approval transaction first, if your allowance for the chosen asset is insufficient). Once you've executed the transaction, you will receive confirmation that the transaction has been submitted to the blockchain and that confirmation is pending. Once the transaction is validated on the blockchain, you will then receive confirmation that the transaction was completed, meaning the vault tokens will now be in your wallet.
And that's it! Deposit complete. Beefy ZAP V1 automatically created liquidity with Dystopia and deposited that liquidity into the Beefy vault. You can check [this guide](/faq/how-to-guides/how-to-check-harvesting-compounding-rate) to see when our vaults will harvest rewards and compound for more LP tokens.
## ZAP V1: Exiting Vaults
In the reverse, you can withdraw by selecting the *"Withdraw"* tab instead of *"Deposit"*. Use the *"Select token"* dropdown to select one of the underlying assets of the vault (WMATIC, stMATIC, MATIC). You can then select the quantity of LP tokens that you wish to withdraw, or use the *"MAX"* button to select all. Please note that the number of LP tokens is ordinarily different to the number of mooTokens or the number of underlying asset tokens you will receive, so the figure displayed can cause confusion.
The UI will then display an estimate for how much of the chosen withdrawal token (e.g. MATIC) you will receive through the ZAP V1 workflow. Below, the *"Zap Route"* box shows the different steps and estimates for how much of each token will be received and used in each subtransaction. As with deposits, it is impossible to know in advance exactly how much you will receive for the swaps in a ZAP workflow, so the final amounts may vary slightly from the estimates.
For the ZAP V1 withdrawal workflow, select one of the underlying assets in the vault and input the number of LP tokens you wish to withdraw from the vault.
To execute the proposed transaction, click on *"Withdraw"* or *"Withdraw All"*, and your wallet will trigger another transaction (including approvals if needed). Once you've executed the transaction, you will receive confirmation that the transaction has been submitted to the blockchain and confirmation is pending. Once the transaction is validated on the blockchain, you will then receive confirmation that the transaction was completed, meaning the withdrawal tokens will now be in your wallet.
There you go! Withdrawal complete. Beefy ZAP V1 took all the steps to exit the vault, break the liquidity position and swap back to your chosen asset.
## ZAP V2: Entering Vaults
The ZAP V2 workflow is nearly identical to V1 from a user perspective. You can select any of the available tokens in the *"Select token"* dropdown menu, and input the amount to deposit in the box to the right. Again the UI will show you estimates to the number of LP tokens you will receive for depositing into the vault, and each of the steps in the workflow (including the initial swaps to the underlying vault assets).
For the ZAP V1 deposit workflow, select any of the available assets in the dropdown menu and input the quantity of that token you wish to deposit into the vault.
As with the V1 process detailed above, simply hit *"Deposit"* or *"Deposit All"*, run through the transaction on your wallet, and watch the transaction complete on the blockchain. Deposit complete! Beefy ZAP V2 took you from your chosen assets into the underlying vault assets, and then ran the same workflow as ZAP V1.
## ZAP V2: Exiting Vaults
Similarly, the ZAP V2 withdrawal workflow is also near identical to V1 for users. As with deposits, you can now select any of the available tokens in the *"Select token"* dropdown menu, and input the amount to deposit in the box to the right. Again the UI will show you estimates for how much of the chosen withdrawal token (e.g. ETH) you will receive, and how much of each token will be received for each step in the process.
For the ZAP V2 withdrawal workflow, select any of the available assets in the dropdown menu and input the number of LP tokens you wish to withdraw from the vault.
As with the V1 process detailed above, simply hit *"Withdraw"* or *"Withdraw All"*, run through the transaction on your wallet, and watch the transaction complete on the blockchain. Withdraw complete! Beefy ZAP V2 took you through all the steps in V1 to exit the vault and break the liquidity position, before swapping back to your chosen asset with V2.
{% hint style="info" %}
The ZAP quote that's displayed during the deposit or withdraw process already has the ZAP fee taken into account. Additionally, the ZAP fee is only deducted from token swaps. The fees first accumulate in a batch treasury, and after some time are swapped to stables and sent to [Beefy's Treasury](https://app.beefy.com/treasury). The original Beefy ZAP V1 remains free to use.
{% endhint %}
# How to add and switch networks on Beefy
In this guide new Metamask network settings will be added for you using the Beefy network switcher.
As Beefy is a Decentralized, Multichain Yield Optimizer, users will need to have properly configured wallets for each chain that they want use Beefy on. Using this guide and the Beefy network switcher, new blockchain networks can be added automatically with ease. As an example the Huobi ECO chain (HECO) network will be used in this How-To guide, but you can repeat the same process for any other network listed in the network switcher.
## Prerequisites
* A Binance Smart Chain (BSC) configured Metamask wallet is needed. Beefy started on BSC so you probably already have this set up, but if you do not have a configured wallet you can use the following guide from Binance Academy: [Connecting Metamask to Binance Smart Chain](https://academy.binance.com/en/articles/connecting-metamask-to-binance-smart-chain) (you may skip the testnet section, it is not needed).
## Walkthrough
### 1. Go to [app.beefy.finance](https://github.com/beefyfinance/beefy-docs/tree/aab629bafbc230570677e0471b162bbd46e2e0ba/faq/how-to-guides/app.beefy.finance) and connect your BSC configured Metamask wallet.
### 2. Click on the BSC icon under 'Select Network'.
### 3. Select HECO (or any other network you want to add).
### 4. Approve new network creation to your Metamask
### 5. Allow Beefy to switch to the HECO network
And that's it! HECO is now configured and added to your Metamask wallet. You can repeat the process for any other network that you want to add or want to switch to.
# How to check the harvesting and compounding rate of a vault
In this guide you will find the required steps to check a vault's harvesting and compounding rate.
Beefy's [vaults](/beefy-products/vaults), or more specifically the investment strategy tied to the vault, will automatically increase the amount of your deposited asset by compounding arbitrary yield-farm rewards back into more of that asset. This constant cycle of harvesting rewards, and compounding, happens usually multiple times per day. In this How-To we walk you through steps to check precisely how often the compounding occurs.
## Walkthrough
NOTE: No matter which chain you choose, you can use Beefy's [dashboard.beefy.finance](https://dashboard.beefy.finance) to launch your investigation.
### Binance Smart Chain (BSC) example
Let's choose the CAKE-BNB LP vault on the Binance Smart Chain to demonstrate:
#### 1. Go to [dashboard.beefy.finance](https://dashboard.beefy.finance)
This dashboard chooses which statistics and vaults to show based on the blockchain network your wallet (e.g. MetaMask) is connected to. So if it's not now on BSC, simply switch networks to that and the dashboard page will refresh to display Beefy's statistics and vaults on BSC.
#### 2. Find the contract for the vault you wish to inspect, and click on it, opening a page in the BscScan block explorer
#### 3. On the BscScan page, open the "Contract" tab and subsequently the "Read Contract" tab
#### 4. Scroll down to find the strategy contract, and click on it
#### 5. Click on the Events tab to view the strategy events that have fired
The "StratHarvest" events are where LP-farming rewards are culled and in turn compounded into more of the underlying LPs, the initial deposited asset, and then redeposited into the Beefy vault. As the timestamps reflect, this CAKE-BNB vault compounds roughly once per hour.
### Other Chains (except Harmony, Celo, Cronos)
Each of the chains supported by Beefy may be investigated via the same method shown above for BSC. The only difference will be the block explorer opened. For example on Polygon, PolygonScan will open.
### Harmony, Celo, Cronos
The basic method shown in the BSC example above still applies, except for the last, key step 5. This owes to these chains using different block-explorer softwares. In these cases, step 5 switches to the Transactions tab to view the strategy events fired, as exemplified below
# Vault Contract
Last Update: February 2023
The [Beefy Vault Contract](https://github.com/beefyfinance/beefy-contracts/blob/master/contracts/BIFI/vaults/BeefyVaultV7.sol) is the central user-facing implementation of the Beefy protocol, which accepts and manages user deposits and mints mooTokens as a proof of receipt to facilitate withdrawals. It follows the ERC-20 [standard](https://eips.ethereum.org/EIPS/eip-20) for fungible, transferrable tokens.
Besides handling deposits and withdrawals, the primary function of the vault is to direct deposited funds to the relevant autocompounding [Strategy Contract](/developer-documentation/strategy-contract). The vault and strategy contracts are kept separate to isolate any risks in the strategy from user deposits.
## View Functions
### want()
Returns the address of the underlying farm token (e.g. the LP token) used in both the Beefy Vault and Strategy contracts. Note that this is not the same as the underlying assets used for the farm.
```solidity
function want() public view returns (IERC20Upgradeable) {
return IERC20Upgradeable(strategy.want());
}
```
### balance()
Returns the amount of "want" (i.e. underlying farm token) stored in the vault and strategy and yield source as an integer.
```solidity
function balance() public view returns (uint) {
return want().balanceOf(address(this)) + IStrategyV7(strategy).balanceOf();
}
```
### available()
Returns the amount of "want" (i.e. underlying farm token) stored in the vault alone as an integer.
```solidity
function available() public view returns (uint256) {
return want().balanceOf(address(this));
}
```
### totalSupply()
Returns the total amount of mooTokens minted as an integer, which are always displayed as 18 decimal token. This is a standard method inherited from the ERC-20 standard. See[Vaults](/beefy-products/vaults#what-are-mootokens) for more details.
```solidity
function totalSupply() public view virtual override returns (uint256) {
return _totalSupply;
}
```
### getPricePerFullShare()
Returns the current price per share of the vault (i.e. per mooToken) as an integer denominated in the "want" (i.e. underlying farm token). This is calculated as *Price per Full Share =* [#balance](#balance "mention") */* [#totalsupply](#totalsupply "mention").
```solidity
function getPricePerFullShare() public view returns (uint256) {
return totalSupply() == 0 ? 1e18 : balance() * 1e18 / totalSupply();
}
```
### strategy()
Returns the address current underlying strategy contract that the vault is using to generate yield.
```solidity
function strategy() external view returns (address);
```
## Write Functions
### deposit()
Executes a transfer of a specified \_amount of "want" (i.e. underlying farm token) from the depositor to the vault, and then mints a proportional quantity of mooTokens to the depositor in return.
```solidity
function deposit(uint _amount) public nonReentrant {
strategy.beforeDeposit();
uint256 _pool = balance();
want().safeTransferFrom(msg.sender, address(this), _amount);
earn();
uint256 _after = balance();
_amount = _after - _pool; // Additional check for deflationary tokens
uint256 shares = 0;
if (totalSupply() == 0) {
shares = _amount;
} else {
shares = (_amount * totalSupply()) / _pool;
}
_mint(msg.sender, shares);
}
```
Additionally, there is a helper function *depositAll()* that deposits the entire balance of "want" in the user's wallet at the time of the transaction.
### withdraw()
Executes a burn of a specified \_amount of mooTokens from the depositor, and then transfers a proportional quantity of "want" (i.e. underlying farm token) to the depositor in return.
```solidity
function withdraw(uint256 _shares) public {
uint256 r = (balance() * _shares) / totalSupply();
_burn(msg.sender, _shares);
uint b = want().balanceOf(address(this));
if (b < r) {
uint _withdraw = r - b;
strategy.withdraw(_withdraw);
uint _after = want().balanceOf(address(this));
uint _diff = _after - b;
if (_diff < _withdraw) {
r = b + _diff;
}
}
want().safeTransfer(msg.sender, r);
}
```
Similarly to [#deposit](#deposit "mention")*,* there is a helper function *withdrawAll()* that withdraw the entire balance of mooTokens in the user's wallet at the time of the transaction.
### earn()
Executes a transfer of [#available](#available "mention") "want" (i.e. underlying farm token) from the Vault Contract to the strategy contract and triggers the strategy's *deposit()* function to deploy the funds and begin earning.
```solidity
function earn() public {
uint _bal = available();
want().safeTransfer(address(strategy), _bal);
strategy.deposit();
}
```
### proposeStrat()
Writes the address of an alternate strategy to the Vault Contract's memory, in anticipation of upgrade the current strategy to the alternate using [#upgradestrat](#upgradestrat "mention").
```solidity
function proposeStrat(address _implementation) public onlyOwner {
require(address(this) == IStrategyV7(_implementation).vault(), "Proposal not valid for this Vault");
require(want() == IStrategyV7(_implementation).want(), "Different want");
stratCandidate = StratCandidate({
implementation: _implementation,
proposedTime: block.timestamp
});
emit NewStratCandidate(_implementation);
}
```
### upgradeStrat()
Replaces the address of the current strategy with an alternate strategy specified by [#proposestrat](#proposestrat "mention").
```solidity
function upgradeStrat() public onlyOwner {
require(stratCandidate.implementation != address(0), "There is no candidate");
require(stratCandidate.proposedTime + approvalDelay < block.timestamp, "Delay has not passed");
emit UpgradeStrat(stratCandidate.implementation);
strategy.retireStrat();
strategy = IStrategyV7(stratCandidate.implementation);
stratCandidate.implementation = address(0);
stratCandidate.proposedTime = 5000000000;
earn();
}
```
## BeefyVaultV7.sol
The current release of our standard Beefy Vault Contract is [BeefyVaultV7.sol](https://github.com/beefyfinance/beefy-contracts/blob/master/contracts/BIFI/vaults/BeefyVaultV7.sol), which was [released](https://github.com/beefyfinance/beefy-contracts/pull/83) in August 2022. The V7 release improved on the previous version in a few keys ways:
* Introduced vault upgradeability through proxy patterns, to facilitate updates and changes to live Beefy vaults without needing to deprecate and re-deploy;
* Updated the strategy interface to allow for upgradeable strategies; and
* Amended all contracts to remove reliance on the SafeMath library, which has been generally retired following incorporation of its features into Solidity v0.8.
Separately, a ERC-4646-compliant wrapper contract was released for the V7 vault in November 2022, which allows developers to incorporate Beefy Vaults into their projects with standardised vault functionality and interfaces. See [BeefyWrapper Contract](/developer-documentation/other-beefy-contracts/beefywrapper-contract) for more information.
# Strategy Contract
Last Update: February 2023
[Strategy Contracts](https://github.com/beefyfinance/beefy-contracts/tree/master/contracts/BIFI/strategies) are the primary driver of Beefy's investment model, which facilitate the autocompounding of yield farm rewards. Beefy's process has three key steps: (1) staking deposited tokens in the relevant farms; (2) harvesting rewards; and (3) swapping rewards for more deposit tokens and reinvesting the proceeds
Each strategy contract is ultimately dependent on a [Vault Contract](/developer-documentation/vault-contract) for the capital they deploy, and do not have any direct interaction with ordinary users. The vault and strategy contracts are kept separate to isolate any risks in the strategy from user deposits.
## Dependencies
All Beefy strategies rely on a range of dependencies and interfaces which are imported into the strategy contract on deployment. The core dependencies, which allow the strategy to inherit a range of functionality are:
* the [StratFeeManager Contract](/developer-documentation/strategy-contract/stratfeemanager-contract); and
* the [GasFeeThrottler Contract](/developer-documentation/strategy-contract/gasfeethrottler-contract).
## Interfaces
The key interfaces which allow the strategy to interact with third party contracts are:
* **the router contract interface** - which allows for swaps between the different tokens involved in the autocompounding process (e.g. IUniswapRouterETH.sol);
* **the liquidity pool contract interface** - which is the underlying pool that our vaults provide liquidity to and that the farms are built on top of (e.g. IUniswapV2Pair.sol); and
* **the chef contract interface** - the farm which is issuing rewards for providing liquidity (e.g. IMiniChefV2.sol).
## View Functions
### balanceOf() / balanceOfWant()
Checks the amount of the underlying farm token (or "want") stored in the strategy. Returns the specific amount of tokens.
```solidity
function balanceOf() public view returns (uint256) {
return balanceOfWant() + balanceOfPool();
}
function balanceOfWant() public view returns (uint256) {
return IERC20(want).balanceOf(address(this));
}
```
### balanceOfPool()
Checks the amount of underlying farm token (or "want") stored in the chef contract. Returns the specific amount of tokens.
```solidity
function balanceOfPool() public view returns (uint256) {
(uint256 _amount, ) = IMiniChefV2(chef).userInfo(poolId, address(this));
return _amount;
}
```
### rewardsAvailable()
Checks the amount of pending rewards held by the chef contract capable of being claimed by the strategy contract. Returns the specific amount of tokens.
```solidity
function rewardsAvailable() public view returns (uint256) {
return IMiniChefV2(chef).pendingSushi(poolId, address(this));
}
```
### callReward()
Most strategies include a *callReward()* function, which is used to determine the amount of "native" token rewards available to the *harvest()* caller.
```solidity
function callReward() external view returns (uint256) {
uint256 pendingReward;
address rewarder = IMiniChefV2(chef).rewarder(poolId);
if (rewarder != address(0)) {
pendingReward = IRewarder(rewarder).pendingToken(poolId, address(this));
}
uint256 outputBal = rewardsAvailable();
uint256 nativeOut;
if (reward == native) {
nativeOut = pendingReward;
} else if (pendingReward > 0) {
uint256 poolLength = params.rewardToNative.path.length;
uint256 amount = pendingReward;
for (uint i; i < poolLength;) {
bytes memory data = abi.encode(routes.rewardToNative[i], amount);
amount = IBentoPool(params.rewardToNative.path[i].pool).getAmountOut(data);
unchecked { ++i; }
}
nativeOut = amount;
}
if (outputBal > 0) {
bytes memory data = abi.encode(output, outputBal);
nativeOut += IBentoPool(params.outputToNative.path[0].pool).getAmountOut(data);
}
IFeeConfig.FeeCategory memory fees = getFees();
return nativeOut * fees.total / DIVISOR * fees.call / DIVISOR;
}
```
## Write Functions
### deposit()
Deposits the underlying farm token (or "want") into in the farm by way of the connected chef contract. First checks that the strategy is holding some of the underlying farm token (or "want") before depositing the entire balance in the chef.
function deposit() public whenNotPaused {
uint256 wantBal = IERC20(want).balanceOf(address(this));
if (wantBal > 0) {
IMiniChefV2(chef).deposit(poolId, wantBal, address(this));
emit Deposit(balanceOf());
}
}
### withdraw()
External function called by the vault to facilitate user withdrawals. First checks that the balance of the underlying farm token (or "want") is sufficient to fulfil the request, and then withdraws that amount from the chef contract, before transferring back to the vault contract.
```solidity
function withdraw(uint256 _amount) external {
require(msg.sender == vault, "!vault");
uint256 wantBal = IERC20(want).balanceOf(address(this));
if (wantBal < _amount) {
IMiniChefV2(chef).withdraw(poolId, _amount.sub(wantBal), address(this));
wantBal = IERC20(want).balanceOf(address(this));
}
if (wantBal > _amount) {
wantBal = _amount;
}
if (tx.origin != owner() && !paused()) {
uint256 withdrawalFeeAmount = wantBal * withdrawalFee / WITHDRAWAL_MAX;
wantBal = wantBal - withdrawalFeeAmount;
}
IERC20(want).safeTransfer(vault, wantBal);
emit Withdraw(balanceOf());
}
```
### harvest()
Harvest invokes the compounding of the vault for all users. Specifically, this harvests from the chef contract, charges fees on the harvest and then deposits the harvested rewards back into the farm to achieve the autocompounding effect.
This function is completely decentralized, meaning that anyone is able to call the function, and can earn a reward between 0.05 - 0.5% of the total yield. This can be called by any one of three methods, detailed below.
```solidity
// @dev Default harvest() method.
function harvest() external virtual gasThrottle {
_harvest(tx.origin);
}
// @dev Alternative harvest() method, where caller receives a fee.
function harvest(address callFeeRecipient) external virtual {
_harvest(callFeeRecipient);
}
// @dev Alternative harvest() method, where manager calls without gas throttling.
function managerHarvest() external onlyManager {
_harvest(tx.origin);
}
// @dev Underlying internal _harvest() function, used by all 3 public methods.
function _harvest(address callFeeRecipient) internal whenNotPaused {
IMiniChefV2(chef).harvest(poolId, address(this));
uint256 outputBal = IERC20(output).balanceOf(address(this));
uint256 rewardBal = IERC20(reward).balanceOf(address(this));
if (outputBal > 0 || rewardBal > 0) {
chargeFees(callFeeRecipient);
addLiquidity();
uint256 wantHarvested = balanceOfWant();
deposit();
lastHarvest = block.timestamp;
emit StratHarvest(msg.sender, wantHarvested, balanceOf());
}
}
```
### chargeFees()
Internal method to charge fees on every [#harvest](#harvest "mention") call, by swapping the native token in the strategy to the output token via the router contract. The contract then calculates the output for the different fee recipient and transfers the output tokens according to the allocation. The recipients are the harvest caller, the strategist who deployed the contract and the Beefy treasury.
{% code overflow="wrap" %}
```solidity
function chargeFees(address callFeeRecipient) internal {
IFeeConfig.FeeCategory memory fees = getFees();
uint256 rewardBal = IERC20(reward).balanceOf(address(this));
if (rewardBal > 0 && reward != native) {
ITridentRouter.ExactInputParams memory _rewardToNative = params.rewardToNative;
_rewardToNative.amountIn = rewardBal;
ITridentRouter(unirouter).exactInputWithNativeToken(_rewardToNative);
}
uint256 outputBal = IERC20(output).balanceOf(address(this));
if (outputBal > 0) {
ITridentRouter.ExactInputParams memory _outputToNative = params.outputToNative;
_outputToNative.amountIn = outputBal;
ITridentRouter(unirouter).exactInputWithNativeToken(_outputToNative);
}
uint256 nativeBal = IERC20(native).balanceOf(address(this)) * fees.total / DIVISOR;
uint256 callFeeAmount = nativeBal * fees.call / DIVISOR;
IERC20(native).safeTransfer(callFeeRecipient, callFeeAmount);
uint256 beefyFeeAmount = nativeBal * fees.beefy / DIVISOR;
IERC20(native).safeTransfer(beefyFeeRecipient, beefyFeeAmount);
uint256 strategistFeeAmount = nativeBal * fees.strategist / DIVISOR;
IERC20(native).safeTransfer(strategist, strategistFeeAmount);
emit ChargedFees(callFeeAmount, beefyFeeAmount, strategistFeeAmount);
}
```
{% endcode %}
### addLiquidity()
Internal method to add liquidity to the underlying pool for the farm as part of the [#harvest](#harvest "mention") function. Swaps the output token to the underlying tokens of the farm, and then adds both to the liquidity pool to obtain the underlying farm deposit token (or "want"). The remainder of the *harvest()* call then deposits these tokens in the farm.
{% code overflow="wrap" %}
```solidity
function addLiquidity() internal {
uint256 nativeHalf = IERC20(native).balanceOf(address(this)) / 2;
if (lpToken0 != native) {
ITridentRouter.ExactInputParams memory _nativeToLp0 = params.nativeToLp0;
_nativeToLp0.amountIn = nativeHalf;
ITridentRouter(unirouter).exactInputWithNativeToken(_nativeToLp0);
}
if (lpToken1 != native) {
ITridentRouter.ExactInputParams memory _nativeToLp1 = params.nativeToLp1;
_nativeToLp1.amountIn = nativeHalf;
ITridentRouter(unirouter).exactInputWithNativeToken(_nativeToLp1);
}
ITridentRouter.TokenInput[] memory tokens = new ITridentRouter.TokenInput[](2);
uint256 lp0Bal = IERC20(lpToken0).balanceOf(address(this));
uint256 lp1Bal = IERC20(lpToken1).balanceOf(address(this));
tokens[0] = ITridentRouter.TokenInput(lpToken0, true, lp0Bal);
tokens[1] = ITridentRouter.TokenInput(lpToken1, true, lp1Bal);
bytes memory data = abi.encode(address(this));
ITridentRouter(unirouter).addLiquidity(tokens, want, 1, data);
}
```
{% endcode %}
### setHarvestOnDeposit()
Most Beefy vaults [harvest on deposit](/beefy-products/vaults#what-is-harvesting-on-deposit). This means that, before the user's funds enter the strategy, the yield on the entire vault is harvested and reinvested. This prevents new depositors from stealing the yield of existing depositors. As a result, any vault that is set to harvest on deposit is able to remove the withdrawal fee completely.
*harvestOnDeposit* is a boolean variable which is set to true when the vault is harvesting on deposit. This is toggled by the *setHarvestOnDeposit()* function, set out below:
bool public harvestOnDeposit;
function setHarvestOnDeposit(bool _harvestOnDeposit) external onlyManager {
harvestOnDeposit = _harvestOnDeposit;
if (harvestOnDeposit) {
setWithdrawalFee(0);
} else {
setWithdrawalFee(10);
}
}
### beforeDeposit()
External function used to facilitate harvests on deposit, if active. Checks first that harvest on deposit is active and that the caller is the vault, before harvesting.
```solidity
function beforeDeposit() external override {
if (harvestOnDeposit) {
require(msg.sender == vault, "!vault");
_harvest(tx.origin);
}
}
```
### panic()
Beefy does not directly touch any user funds held in the protocol. During times of uncertainty or upgrades to the underlying yield farm, Beefy can withdraw all funds out of third party contracts and hold them safely in the strategy using the *panic()* function. By "panicking" the strategy, users remain able to withdraw their funds from the vault without any delay or exposure to third party risks. This function also removes all allowances to both the UniRouter and the underlying yield farm contract, to ensure no funds can be withdrawn by those contracts.
```solidity
function panic() public onlyManager {
pause();
IMiniChefV2(chef).emergencyWithdraw(poolId, address(this));
}
```
### pause() / unpause()
All Beefy strategies are pausable, meaning that functionality can be halted during the strategy's ordinary operations by the strategy manager. This is inherited through [StratManager.sol](https://github.com/beefyfinance/beefy-contracts/blob/master/contracts/BIFI/strategies/Common/StratManager.sol), and relies on the standard [Pausable.sol](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/security/Pausable.sol) abstract contract. This function also removes all allowances to both the UniRouter and the underlying yield farm contract, to ensure no funds can be withdrawn by those contracts.
```solidity
function pause() public onlyManager {
_pause();
_removeAllowances();
}
```
In the reverse, strategies can also be unpaused, by reversing the actions in the pause function.
```solidity
function unpause() external onlyManager {
_unpause();
_giveAllowances();
deposit();
}
```
The functions affected by a pause in most strategy contracts are [#deposit](#deposit "mention"), [#withdraw](#withdraw "mention") and [#harvest](#harvest "mention").
### \_giveAllowances / \_removeAllowances()
Internal functions used to set and remove all allowances with third party contracts, to control whether third party contracts have the necessary permissions to withdraw funds from the strategy. The relevant contracts are the underlying farm token/*want()* (e.g. LP token), the strategy output token (often the same as the *want()*), the native chain token (used for gas) and the underlying tokens used for the farm.
```solidity
function _giveAllowances() internal {
IERC20(want).safeApprove(chef, type(uint).max);
IERC20(output).safeApprove(unirouter, type(uint).max);
IERC20(native).safeApprove(unirouter, type(uint).max);
IERC20(lpToken0).safeApprove(unirouter, 0);
IERC20(lpToken0).safeApprove(unirouter, type(uint).max);
IERC20(lpToken1).safeApprove(unirouter, 0);
IERC20(lpToken1).safeApprove(unirouter, type(uint).max);
}
function _removeAllowances() internal {
IERC20(want).safeApprove(chef, 0);
IERC20(output).safeApprove(unirouter, 0);
IERC20(native).safeApprove(unirouter, 0);
IERC20(lpToken0).safeApprove(unirouter, 0);
IERC20(lpToken1).safeApprove(unirouter, 0);
}
```
### retireStrat()
External function used as part of a migration from one strategy to another. This effectively closes down the strategy by withdrawing all funds and transferring them back to the vault. It can only be triggered by a call from the vault contract.
```solidity
function retireStrat() external {
require(msg.sender == vault, "!vault");
IMiniChefV2(chef).emergencyWithdraw(poolId, address(this));
uint256 wantBal = IERC20(want).balanceOf(address(this));
IERC20(want).transfer(vault, wantBal);
}
```
# StratFeeManager Contract
Last Update: February 2023
The [StratFeeManager Contract](https://github.com/beefyfinance/beefy-contracts/blob/master/contracts/BIFI/strategies/Common/StratFeeManagerInitializable.sol) is collection of important dependencies which are imported and used in every Beefy [Strategy Contract](/developer-documentation/strategy-contract).
Originally, these dependencies were split into two contracts - [StratManager.sol](https://github.com/beefyfinance/beefy-contracts/blob/master/contracts/BIFI/strategies/Common/StratManager.sol) and [FeeManager.sol](https://github.com/beefyfinance/beefy-contracts/blob/master/contracts/BIFI/strategies/Common/FeeManager.sol). After the move to Solidity V0.8, the two were combined into a single contract - [StratFeeManager.sol](https://github.com/beefyfinance/beefy-contracts/blob/master/contracts/BIFI/strategies/Common/StratFeeManager.sol). The current verison - [StratFeeManagerInitializable.sol](https://github.com/beefyfinance/beefy-contracts/blob/master/contracts/BIFI/strategies/Common/StratFeeManagerInitializable.sol) - facilitated a move to proxy clone strategies (which must be initialized with the relevant arguments for the strategy and its dependencies), to avoid the need to deploy every single strategy individually.
## Dependencies
The StratFeeManager contracts also introduce addition dependencies themselves, specifically [Ownable.sol](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/access/Ownable.sol) - which introduces functionality to set a contract's owner and restrict functionality to them alone - and [Pausable.sol](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/security/Pausable.sol) - which introduces functionality to freeze functionality in a contract by putting the contract on pause. Both dependencies are ultimately included in every Beefy Strategy Contract.
## Modifiers
Introduces an *onlyManager()* modifier to constrain functions to use by the strategy manager only.
```solidity
modifier onlyManager() {
require(msg.sender == owner() || msg.sender == keeper, "!manager");
_;
}
```
## View Functions
### getFees()
Returns the value of all fees from the fee configuration contract.
```solidity
function getFees() internal view returns (IFeeConfig.FeeCategory memory) {
return beefyFeeConfig.getFees(address(this));
}
```
### getAllFees()
Returns the value of all fees from the fee configuration contract, as well the dynamic deposit and withdrawal fees.
```solidity
function getAllFees() external view returns (IFeeConfig.AllFees memory) {
return IFeeConfig.AllFees(getFees(), depositFee(), withdrawFee());
}
```
### getStratFeeId()
Returns the integer value of the strategy fee ID from the fee configuration contract.
```solidity
function getStratFeeId() external view returns (uint256) {
return beefyFeeConfig.stratFeeId(address(this));
}
```
## Write Functions
### setStratFeeId()
Sets a new integer value for the strategy's fee ID, which indicates the relevant fee for the strategy.
```solidity
function setStratFeeId(uint256 _feeId) external onlyManager {
beefyFeeConfig.setStratFeeId(_feeId);
emit SetStratFeeId(_feeId);
}
```
### setWithdrawalFee()
Sets a new integer value for the contract's withdrawal fee which is charged on each harvest.
```solidity
function setWithdrawalFee(uint256 _fee) public onlyManager {
require(_fee <= WITHDRAWAL_FEE_CAP, "!cap");
withdrawalFee = _fee;
emit SetWithdrawalFee(_fee);
}
```
### setVault()
Sets a new address for the contract's vault, which manages user funds.
```solidity
function setVault(address _vault) external onlyOwner {
vault = _vault;
emit SetVault(_vault);
}
```
### setUnirouter()
Sets a new address for the contract's router which processes swaps within the contract.
```solidity
function setUnirouter(address _unirouter) external onlyOwner {
unirouter = _unirouter;
emit SetUnirouter(_unirouter);
}
```
### setKeeper()
Sets a new address for the contract's keeper, who can "panic" the strategy.
```solidity
function setKeeper(address _keeper) external onlyManager {
keeper = _keeper;
emit SetKeeper(_keeper);
}
```
### setStrategist()
Sets a new address for the contract's strategist who receives the strategist fee.
```solidity
function setStrategist(address _strategist) external {
require(msg.sender == strategist, "!strategist");
strategist = _strategist;
emit SetStrategist(_strategist);
}
```
### setBeefyFeeRecipient()
Sets a new address for the recipient of Beefy's fee on harvests, typically a Beefy treasury contract.
```solidity
function setBeefyFeeRecipient(address _beefyFeeRecipient) external onlyOwner {
beefyFeeRecipient = _beefyFeeRecipient;
emit SetBeefyFeeRecipient(_beefyFeeRecipient);
}
```
### setBeefyFeeConfig()
Sets a new address for the fee configuration contract used by the strategy to fetch fees.
```solidity
function setBeefyFeeConfig(address _beefyFeeConfig) external onlyOwner {
beefyFeeConfig = IFeeConfig(_beefyFeeConfig);
emit SetBeefyFeeConfig(_beefyFeeConfig);
}
```
# GasFeeThrottler Contract
Last Update: February 2023
The [GasFeeThrottler Contract](https://github.com/beefyfinance/beefy-contracts/blob/master/contracts/BIFI/utils/GasFeeThrottler.sol) (formerly GasThrottler) is a smart contract device used to ensure that gas prices for child contract transactions always fall below a fixed maximum, or otherwise causes the transaction to be reverted. To do so, it points to a specific [GasPrice Contract](https://github.com/beefyfinance/beefy-contracts/blob/master/contracts/BIFI/utils/GasPrice.sol), where the maximum gas price can be configured by the contract's owner. The GasFeeThrottler is incorporated into every [Strategy Contract](/developer-documentation/strategy-contract).
## GasFeeThrottler.sol
The throttler contract has three main elements which are inherited by its child contracts:
1. the **shouldGasThrottle variable** - which is boolean fixed to *"true"* to indicate that a child contract has inherited gas throttling;
2. the **gasPrice variable** - which connects the throttler to [#gasprice.sol](#gasprice.sol "mention") to identify the max gas price fixed by that contract; and
3. the **gasThrottle() modifier** - which requires that gas prices for transactions arising from the child contract's modified functions always are equal to or below the fixed max gas price.
```solidity
contract GasFeeThrottler {
bool public shouldGasThrottle = true;
address public gasprice = address(0xA43509661141F254F54D9A326E8Ec851A0b95307);
modifier gasThrottle() {
if (shouldGasThrottle && Address.isContract(gasprice)) {
require(tx.gasprice <= IGasPrice(gasprice).maxGasPrice(), "gas is too high!");
}
_;
}
}
```
## GasPrice.sol
The GasPrice contract provides three core elements to facilitate its purpose:
1. the **maxGasPrice variable** - which stores the current maximum gas price value set by the contract, and can be called externally using the [IGasPrice.sol](https://github.com/beefyfinance/beefy-contracts/blob/master/contracts/BIFI/utils/IGasPrice.sol) interface;
2. a **NewMaxGasPrice event** - which is triggered on changes to the maxGasPrice variable, and returns the old and new prices for external reference; and
3. the **setMaxGasPrice function** - which accepts an integer value for the new \_maxGasPrice as an argument, emits the NewMaxGasPrice event and updates the maxGasPrice variable.
contract GasPrice is Ownable {
uint public maxGasPrice = 10000000000;
event NewMaxGasPrice(uint oldPrice, uint newPrice);
function setMaxGasPrice(uint _maxGasPrice) external onlyOwner {
emit NewMaxGasPrice(maxGasPrice, _maxGasPrice);
maxGasPrice = _maxGasPrice;
}
}
# Zap Contracts
Last Update: April 2026
Zap contracts facilitate the delivery of Beefy's ease-of-access [zap tooling](/beefy-products/zap) and form a key part of the user experience for most users of the Beefy protocol and web application.
The vast majority of Beefy deposits and withdrawal interactions actually take place between the user and these zap contracts, with the [vault](/developer-documentation/vault-contract) and [strategy contracts](/developer-documentation/strategy-contract) being handled indirectly in the logic of the zap.
As described in the main [zap documentation](https://app.gitbook.com/o/-MJZ1VQaoU5elNanhqbV/s/-MJZ0tXJc-hdgL-YTlPk-887967055/~/edit/~/changes/346/beefy-products/zap#versions), Beefy has iterated across multiple generations of zap contracts. The below technical documentation deals exclusively with the most recent versions as at the date of the last update - that being Zap V4.
### Core Architecture
Zap V4 is designed to facilitate deposits and withdrawals from Beefy products on any supported chain from any supported token on any other supported chain using [Circle's Cross-Chain Transfer Protocol](https://www.circle.com/cross-chain-transfer-protocol) (**CCTP**).
V4 is a significant step forward from all previous generations, where zap services were constrained to the local chain only. This has necessitated a total redesign of the zap architecture:
Zap V4 Architecture - integrated crosschain deposits and withdrawals via Circle CCTP.
This architecture relies on three core zap smart contracts to deliver the services (shown in the middle line of the above diagram):
1. [**The Router**](#beefyzaprouter-contract) - a general-purpose contract that can receive and execute arbitrary logic in the form of a message, and therefore coordinates the various actions required to execute the zap;
2. [**The Receiver**](#circlebeefyzapreceiver-contract) - a destination-chain contract that receives the user's deposit and instructions after bridging, and triggers the Router using them.
3. [**The Relay**](#swappingrelay-contract) - a destination-chain contract controlled by the [Hook Executor](#hook-executor) to trigger the Receiver once a bridging message is initiated and an attestation is issued by CCTP.
Beyond the smart contracts, Beefy also relies on the [Hook Executor](#hook-executor) offchain service to prompt activity on the destination chain once an activity on the source chain is successfully submitted.
### BeefyZapRouter Contract
The BeefyZapRouter contract is the core router infrastructure through which all Beefy zap transactions pass. It was introduced for Zap V3 to facilitate the move to an aggregator-agnostic model that supports multiple external providers, and remains unchanged as part of V4.
The contract can process arbitrary logic, allowing for new products, assets and paths to be incorporated without changing the core contract logic. This enables Beefy to alter swapping and bridging providers, introduce new components to the zap workflow, and even change the types of assets that can be zapped on the go and without redeploying the router contracts.
The address of the BeefyZapRouter varies from chain to chain. An exhaustive list is maintained as part of the [`blockchain-addressbook` package](https://www.npmjs.com/package/blockchain-addressbook).
#### executeOrder()
The `executeOrder` function serves to receve and execute custom orders to meet the user's requested deposit or withdraw workflow. It receives calldata as to the required order (the input and output structure) and the required route (the steps needed to transform the input into the output), as well as a permit and signature for Permit2-style zaps:
{% code overflow="wrap" %}
```solidity
// BeefyZapRouter.sol
// Zap With Existing Approval
function executeOrder(Order calldata _order, Step[] calldata _route) external payable nonReentrant whenNotPaused {
if (msg.sender != _order.user) revert InvalidCaller(_order.user, msg.sender);
IBeefyTokenManager(tokenManager).pullTokens(_order.user, _order.inputs);
_executeOrder(_order, _route);
}
// Zap with Signed Permit from Permit2
function executeOrder(
IPermit2.PermitBatchTransferFrom calldata _permit,
Order calldata _order,
bytes calldata _signature,
Step[] calldata _route
) external nonReentrant whenNotPaused {
IPermit2(permit2).permitWitnessTransferFrom(
_permit,
_getTransferDetails(_order.inputs),
_order.user,
keccak256(abi.encode(ORDER_TYPEHASH, _order)),
ORDER_STRING,
_signature
);
_executeOrder(_order, _route);
}
```
{% endcode %}
### Hook Executor
Beefy maintains a private Hook Executor to support V4 crosschain zaps via Circle CCTP. Its purpose is to observe the passing of messages and trigger the necessary actions on the destination chain.
The Hook Executor's operations are divided into three services: (i) listening for `MessageSent` events on the source chain, then (ii) fetching the relevant attestation via [Circle's Iris API](https://developers.circle.com/cctp/v1/cctp-apis) offchain, and finally (iii) calling `relay` on the [`SwappingRelay.sol` contract](#swappingrelay-contract) on the destination chain.
Beefy's Hook Executor is the offchain system that identifies crosschain zaps, fetches attestations from CCTP and relays the zap message and attestation to the Receiver contract on the destination chain.
Though each step in the Hook Executor's workflow is fully public and visible, the Executor's code is closed source to maintain its security and upgradeability.
### SwappingRelay Contract
The SwappingRelay contract was added for Zap V4 to facilitate crosschain messaging via Circle CCTP, as the onchain extension of the [Hook Executor](#hook-executor).
Its purpose is two-fold: (i) to trigger the relay process in the [Receiver](#circlebeefyzapreceiver-contract) contract; and (ii) to acquire the chain's native token by swapping USDC to then pay the bridging fee to Circle CCTP.
Where the [Receiver](#circlebeefyzapreceiver-contract) is an independent piece of public infrastructure that users can interact with directly, the Relay contract is private, owned by an externally-owned account operated by the [Hook Executor](#hook-executor). This separation of concerns ensures the [Receiver](#circlebeefyzapreceiver-contract) is not hosting privileged functions or directly interfacing with the Hook Executor. It also allows multiple relayers to operate at once, meaning the relaying service can be decentralized whilst relying on Beefy's core Receiver and Router infrastructure.
Contract Name
Address
SwappingRelay
0xfA572f5563411BbF20fC40b0A6A0D5A9fA1aF00D
#### relay()
The `relay` function primarily serves to call the [Receiver](#circlebeefyzapreceiver-contract)'s own `relay` function, which triggers action on the destination chain. This only occurs when the [Hook Executor](#hook-executor) has identified a message onchain and fetches the associated attestation from CCTP.
As a secondary function, it also offers the ability to top up gas for the execution of relay calls through the `doSwap` function. This first swaps USDC for the wrapped native token and then unwraps the native
{% code overflow="wrap" %}
```solidity
// SwappingRelay.sol
function relay(bytes calldata message, bytes calldata attestation) external onlyOwner {
bool zapSuccess = receiver.relay(message, attestation);
(bool swapSuccess, uint256 nativeSent) = _doSwap();
emit Relayed(zapSuccess, swapSuccess, nativeSent);
}
```
{% endcode %}
### CircleBeefyZapReceiver Contract
The CircleBeefyZapReceiver contract was added for Zap V4 to deliver crosschain zaps on the destination chain. Its purpose is to take receipt of the bridged assets, conduct the zap deposit into the desired product and return the deposit token to the user.
Beefy's Receiver contract receives a relay call from the Hook Executor to trigger receiverMessage from a local Circle MessageTransmitter
Contract Name
Address
CircleBeefyZapReceiver
0xBeef940035C062bb8bEe892087aBa6Cde4F9BeEF
#### relay()
The `relay` function primarily serves to receive and process Circle CCTP messages, distribute any configured USDC fee to the caller, and attempt execution of a downstream zap workflow.
The Receiver accepts the raw message and attestation from the Relayer, verifies and mints funds via Circle’s MessageTransmitter, pays a relayer fee in USDC to the caller, and then invokes a hook to process the zap logic. The zap execution is wrapped in a try/catch so failures do not revert the relay; instead, failures trigger a recovery path and emit appropriate execution events reflecting success, refund, or recovery outcomes.
{% code overflow="wrap" %}
```solidity
// CircleBeefyZapReceiver.sol
function relay(
bytes calldata message,
bytes calldata attestation
) external nonReentrant returns (bool zapStatus) {
CircleBeefyReceiverStorage storage $ = getCircleBeefyReceiverStorage();
bytes32 nonce = _getNonce(message);
IReceiver($.messageTransmitter).receiveMessage(message, attestation);
uint256 _fee = $.fee;
if (_fee > 0) IERC20($.usdc).safeTransfer(msg.sender, _fee);
emit FeePaid(nonce, msg.sender, _fee);
uint256 amountIn = IERC20($.usdc).balanceOf(address(this));
try this.processHook(message) returns (address recipient, bool _zapSuccess) {
uint256 refundedAmount = _zapSuccess ? 0 : amountIn;
emit ZapExecuted(nonce, recipient, _zapSuccess, amountIn, refundedAmount, 0);
return _zapSuccess;
} catch {
uint256 recoveredAmount = _recoverUsdc();
emit ZapExecuted(nonce, $.recovery, false, amountIn, 0, recoveredAmount);
return false;
}
}
```
{% endcode %}
### CircleBeefyZapStorage Contract
The CircleBeefyZapStorage contract supported the [CircleBeefyZapReceiver contract](#circlebeefyzapreceiver-contract) by providing a global, unique storage slot that works across upgrades and will not collide with other contracts.
It contains a single function, which retrieves the stored data:
{% code overflow="wrap" %}
```solidity
// CircleBeefyZapStorage.sol
function getCircleBeefyReceiverStorage() internal pure returns (ICircleBeefyZapReceiver.CircleBeefyReceiverStorage storage $) {
assembly {
$.slot := CircleBeefyReceiverStorageLocation
}
}
```
{% endcode %}
The structure of the stored data is defined in the receiver's interface contract:
{% code overflow="wrap" %}
```solidity
// ICircleBeefyZapReceiver.sol
struct CircleBeefyReceiverStorage {
address usdc;
address messageTransmitter;
address zap;
address tokenManager;
address recovery;
uint256 fee;
}
```
{% endcode %}
# Other Beefy Contracts
# FeeConfigurator Contract
Last Update: February 2023
The [BeefyFeeConfigurator Contract](https://github.com/beefyfinance/beefy-contracts/blob/master/contracts/BIFI/infra/BeefyFeeConfigurator.sol) is an infrastructure contract hosted on each of the blockchains which Beefy has deployed on. The contract manages the configuration of fees for each strategy on the relevant chain, which the [StratFeeManager Contract](/developer-documentation/strategy-contract/stratfeemanager-contract) interfaces with through [IFeeConfig.sol](https://github.com/beefyfinance/beefy-contracts/blob/master/contracts/BIFI/interfaces/common/IFeeConfig.sol).
The relevant address for the FeeConfigurator Contract (*"beefyFeeConfig"*) on each chain is displayed in the Beefy API using the [Beefy API](/developer-documentation/beefy-api#get-config) endpoint.
## Modifier
Includes a standard *onlyManager()* modifier to control access to write functions.
```solidity
modifier onlyManager() {
require(msg.sender == owner() || msg.sender == keeper, "!manager");
_;
}
```
## View Functions
### getFees()
Returns a *FeeCategory* structure for a specific strategy address argument, displaying the total fees charged, the fees for Beefy, the harvest caller and the strategist, a string showing the description of the type of fee category, and *"active"* boolean variable, showing whether the fee category is switched on or not.
Includes an *"\_adjust"* boolean variable argument, which displays fees as a % of the total harvest if set to true, or as a % of the total fee if set to false.
{% code overflow="wrap" %}
```solidity
function getFees(address _strategy) external view returns (FeeCategory memory) {
return getFeeCategory(stratFeeId[_strategy], false);
}
function getFees(address _strategy, bool _adjust) external view returns (FeeCategory memory) {
return getFeeCategory(stratFeeId[_strategy], _adjust);
}
```
{% endcode %}
### getFeeCategory()
Returns a *FeeCategory* structure for a specific strategy ID integer, as described above. Also includes the *"\_adjust"* boolean variable option.
{% code overflow="wrap" %}
```solidity
function getFeeCategory(uint256 _id, bool _adjust) public view returns (FeeCategory memory fees) {
uint256 id = feeCategory[_id].active ? _id : 0;
fees = feeCategory[id];
if (_adjust) {
uint256 _totalFee = fees.total;
fees.beefy = fees.beefy * _totalFee / DIVISOR;
fees.call = fees.call * _totalFee / DIVISOR;
fees.strategist = fees.strategist * _totalFee / DIVISOR;
}
}
```
{% endcode %}
## Write Functions
### setStratFeeId()
Updates the *stratFeeId* mapping to show ultimately what *FeeCategory* structure is being used by a particular strategy, by way of an intermediate *feeCategory* mapping and *feeId* integer values.
This includes 3 options, including one for the strategy to update its own *feeId*, one to stipulate the strategy address and *feeId* as arguments, and one to set a range of strategies by giving both an array of strategy addresses and an array of *feeIds* as arguments. Each of the three then use the internal *\_setStratFeeId()* function to update each strategy.
function setStratFeeId(uint256 _feeId) external {
_setStratFeeId(msg.sender, _feeId);
}
function setStratFeeId(address _strategy, uint256 _feeId) external onlyManager {
_setStratFeeId(_strategy, _feeId);
}
function setStratFeeId(address[] memory _strategies, uint256[] memory _feeIds) external onlyManager {
uint256 stratLength = _strategies.length;
for (uint256 i = 0; i < stratLength; i++) {
_setStratFeeId(_strategies[i], _feeIds[i]);
}
}
function _setStratFeeId(address _strategy, uint256 _feeId) internal {
stratFeeId[_strategy] = _feeId;
emit SetStratFeeId(_strategy, _feeId);
}
### setFeeCategory()
Sets the parameters for a given *FeeCategory* structure (new or existing), including the split in fees between Beefy, the harvest caller and the strategist.
```solidity
function setFeeCategory(
uint256 _id,
uint256 _total,
uint256 _call,
uint256 _strategist,
string memory _label,
bool _active,
bool _adjust
) external onlyOwner {
require(_total <= totalLimit, ">totalLimit");
if (_adjust) {
_call = _call * DIVISOR / _total;
_strategist = _strategist * DIVISOR / _total;
}
uint256 beefy = DIVISOR - _call - _strategist;
FeeCategory memory category = FeeCategory(_total, beefy, _call, _strategist, _label, _active);
feeCategory[_id] = category;
emit SetFeeCategory(_id, _total, beefy, _call, _strategist, _label, _active);
}
```
### setKeeper()
Updates the named keeper in the FeeConfigurator contract.
```solidity
function setKeeper(address _keeper) external onlyManager {
keeper = _keeper;
emit SetKeeper(_keeper);
}
```
### pause() / unpause()
Sets a specific FeeCategory (using the category ID as an argument) to either active ("unpaused") - meaning a strategy set to that category will use that category - or inactive ("paused") - meaning the strategy will revert to the default fee configuration.
# BeefyWrapper Contract
Last Update: July 2024
The [BeefyWrapper contract](https://github.com/beefyfinance/beefy-contracts/blob/master/contracts/BIFI/vaults/BeefyWrapper.sol) is an ERC-4626 adapter interface that makes a Beefy [Vault Contract](/developer-documentation/vault-contract) compatible with the ERC-4626 [standard](https://eips.ethereum.org/EIPS/eip-4626). It unlocks the composability of the standard and enables smoother interfacing and interaction with Beefy Vaults by external protocols, without the need for additional adapters and plug-ins.
This page sets out some of the background to the ERC-4626 standard, and the functionality of the BeefyWrapper contract.
## Why ERC-4626?
The purpose of the ERC-4626 standard is to solve the problems caused by the diversity of vault designs found across DeFi. Many protocols have incorporated vault concepts into their architecture by reinventing the wheel to suit their own unique architecture and use cases. This means external projects hoping to implement a range of different vaults need to adapt and plug their code to reconcile it with the quirks of each protocol's unique vault design.
The new standard recognises some common functions across the majority of vaults, and suggests that harmonising this functionality into a single standard can help to mitigate the quantity of adaptations and plug-ins required to work with most vaults. For protocols like Beefy, adopting ERC-4626 for our Beefy Vaults helps to facilitate new product development building on our products, and as a result promises to increase the range of use cases available to our users.
## Contract Functions
The functionality of the BeefyWrapper contract facilitates the minting and burning of wrapped Beefy Vault tokens in exchange for the transfer of the caller's Beefy Vault tokens. It also overrides the standard deposit and withdraw functions to facilitate deposits to the main Beefy Vault, in exchange for minting and burning of the wrapped Beefy Vault tokens.
### wrap()
Transfers the specified amount of the caller's Beefy Vault tokens to the wrapper contract to mint the same quantity of wrapped Beefy Vault tokens to the caller.
{% code overflow="wrap" %}
```solidity
// Wraps an amount of vault share tokens.
/// "amount" parameter is the total amount of vault share tokens to be wrapped.
function wrap(uint256 amount) public {
// Transfers the specified amount of the caller's Beefy Vault tokens to the wrapper.
IERC20Upgradeable(vault).safeTransferFrom(msg.sender, address(this), amount);
// Mints the specified amount wrapped Beefy Vault tokens to the caller.
_mint(msg.sender, amount);
}
```
{% endcode %}
### wrapAll()
Utilises the wrap() function, but using the full balance of the caller as the "amount" parameter.
{% code overflow="wrap" %}
```solidity
// Wraps all vault share tokens owned by the caller.
function wrapAll() external {
wrap(IERC20Upgradeable(vault).balanceOf(msg.sender));
}
```
{% endcode %}
### unwrap()
Burns the specified amount of the caller's wrapped Beefy Vault tokens, to transfer the same quantity of unwrapped tokens from the wrapper contract back to the caller.
{% code overflow="wrap" %}
```solidity
// Unwraps an amount of vault share tokens.
/// "amount" parameter is the total amount of vault share tokens to be unwrapped.
function unwrap(uint256 amount) public {
// Burns the specified amount of the caller's wrapped Beefy Vault tokens.
_burn(msg.sender, amount);
// Transfers the specified amount of Beefy Vault tokens back to the caller.
IERC20Upgradeable(vault).safeTransfer(msg.sender, amount);
}
```
{% endcode %}
### unwrapAll()
Utilises the unwrap() function, but using the full balance of the caller as the "amount" parameter.
{% code overflow="wrap" %}
```solidity
// Unwraps all wrapped tokens owned by the caller.
function unwrapAll() external {
unwrap(balanceOf(msg.sender));
}
```
{% endcode %}
### \_deposit()
Overrides the standard \_deposit() function to interact with the wrapper contract and issued wrapped Beefy Vault tokens, in place of the unwrapped version. Otherwise facilitates an ordinary transfer into the Beefy Vault.
{% code overflow="wrap" %}
```solidity
// Deposit assets to the vault and mint an equal number of wrapped tokens to vault shares.
/// "caller" parameter is the address of the sender of the assets.
/// "receiver" parameter is the address of the receiver of the wrapped tokens.
/// "assets" parameter is the amount of assets being deposited.
/// "shares parameter is the amount of shares being minted.
function _deposit(address caller, address receiver, uint256 assets, uint256 shares) internal virtual override {
// Transfers the caller's tokens to the wrapper.
IERC20Upgradeable(asset()).safeTransferFrom(caller, address(this), assets);
uint balance = IERC20Upgradeable(vault).balanceOf(address(this));
// Deposits the caller's tokens into the Beefy Vault.
IVault(vault).deposit(assets);
// Mints wrapped tokens to the receiver.
shares = IERC20Upgradeable(vault).balanceOf(address(this)) - balance;
_mint(receiver, shares);
// Emits the Deposit event to signify a successful deposit.
emit Deposit(caller, receiver, assets, shares);
}
```
{% endcode %}
### \_withdraw()
Overrides the standard \_withdraw() function to interact with the wrapped Beefy Vault tokens, in place of the unwrapped version. Otherwise facilitates an ordinary withdrawal from the Beefy Vault and returns the underlying tokens to the receiver.
// Burn wrapped tokens and withdraw assets from the vault.
/// "caller" parameter is the address of the caller of the withdraw.
/// "receiver" parameter is the address of the receiver of the assets.
/// "owner" parameter is the address of the owner of the burnt shares.
/// "assets" parameter is the amount of assets being withdrawn.
/// "shares parameter is the amount of shares being burnt.
function _withdraw(address caller, address receiver, address owner, uint256 assets, uint256 shares) internal virtual override {
// Checks caller is not the contract's owner, and that the caller's spend allowance is sufficient for the call.
if (caller != owner) {
_spendAllowance(owner, caller, shares);
}
// Burns the caller's wrapped tokens.
_burn(owner, shares);
// Withdraws the caller's assets from the Beefy Vault.
IVault(vault).withdraw(shares);
uint balance = IERC20Upgradeable(asset()).balanceOf(address(this));
if (assets > balance) {
assets = balance;
}
// Transfers the caller's assets back to the receiver.
IERC20Upgradeable(asset()).safeTransfer(receiver, assets);
// Emits the Withdraw event to signify a successful withdrawal.
emit Withdraw(caller, receiver, owner, assets, shares);
}
### totalAssets()
Overrides the standard totalAssets() function to fetch the total assets held by the vault.
{% code overflow="wrap" %}
```solidity
// Fetches and returns the total assets as a uint256 value.
function totalAssets() public view virtual override returns (uint256) {
return IVault(vault).balance();
}
```
{% endcode %}
### totalSupply()
Overrides the standard totalSupply() function to fetch the total shares issues by the vault.
{% code overflow="wrap" %}
```solidity
// Fetches and returns the total vault shares as a uint256 value.
function totalSupply() public view virtual override(ERC20Upgradeable, IERC20Upgradeable) returns (uint256) {
return IERC20Upgradeable(vault).totalSupply();
}
```
{% endcode %}
## BeefyWrapperFactory Contract
The [BeefyWrapperFactory contract](https://github.com/beefyfinance/beefy-contracts/blob/master/contracts/BIFI/vaults/BeefyWrapperFactory.sol) is a factory contract which provides a minimal proxy pattern for use in creating new Beefy Vault wrappers. A factory contract allows users to generate and deploy their own proxy contracts that all point to the same implementation contract, where the logic resides.
Through the BeefyWrapperFactory, BeefyWrapper contracts can be deployed for any vaults. The factory contract has only one key function - clone().
### clone()
Uses the OpenZeppelin standard proxy template [ClonesUpgradeable.sol](https://github.com/OpenZeppelin/openzeppelin-contracts-upgradeable/blob/master/contracts/proxy/ClonesUpgradeable.sol) to create a proxy contract which is a clone of the BeefyWrapper contract.
{% code overflow="wrap" %}
```solidity
// Creates a new Beefy Vault wrapper as a proxy of the template instance.
/// "_vault" parameter is the cloned Beefy Vault.
/// "proxy" return is the new proxied Beefy Vault wrapper.
function clone(address _vault) external returns (address proxy) {
// Proxy is set as a clone of the instance of the BeefyWrapper contract.
proxy = implementation.clone();
// Initializes the wrapper proxy set above.
IWrapper(proxy).initialize(
_vault,
string.concat("W", IVault(_vault).name()),
string.concat("w", IVault(_vault).symbol())
);
// Emits the ProxyCreated event to signify a successful deployment.
emit ProxyCreated(proxy);
}
```
{% endcode %}
## Contracts
The template Beefy Vault wrapper contracts are publicly maintained in Beefy's GitHub repositories. See [BeefyWrapper.sol](https://github.com/beefyfinance/beefy-contracts/blob/master/contracts/BIFI/vaults/BeefyWrapper.sol) and [BeefyWrapperFactory.sol](https://github.com/beefyfinance/beefy-contracts/blob/master/contracts/BIFI/vaults/BeefyWrapperFactory.sol).
BeefyWrapperFactory.sol contracts for each Beefy Vault have been deployed separately on the relevant chains at the following addresses:
Chain
Arbitrum
0x48bF3a071098a09C7D00379b4DBC69Ab6Da83a36
Aurora
Not yet deployed
Avalanche
0x1Fa046d28FF749b9D7CF7E9a41BEecd1260F11eD
Base
0x917447f8f52E7Db26cE7f52BE2F3fcb4d4D00832
BSC
0x85B792C67cEe281064eb7A3AF0Fe2A76E9a7849e
Canto
Not yet deployed
Celo
Not yet deployed
Cronos
Not yet deployed
Emerald
Not yet deployed
Ethereum
0x62fcbc7c3235950eD6dE4168fbd373aF9e8ee0fc
Fantom
0x985CA8C1B4Ff5a15E1162BaE1669A928e5a6bD49
Fraxtal
Not yet deployed
Fuse
Not yet deployed
Gnosis
Not yet deployed
Harmony
Not yet deployed
Heco
Not yet deployed
Kava
Not yet deployed
Linea
0xDBad28672fD60c4609EE6B26dF2b8cB93DE12afe
Manta
Not yet deployed
Mantle
Not yet deployed
Metis
0xDf29382141059afD25Deb624E6c8f13A051012Be
Mode
Not yet deployed
Moonbeam
Not yet deployed
Moonriver
Not yet deployed
Optimism
0x182be93E1C0C4d305fe43bD093292F21fd679797
Polygon PoS
0x7e778f4cF8c7C43FB2F3C9C0b4Ce7CB7c2bad978
Polygon zkEVM
Not yet deployed
zkSync
Not yet deployed
# GaugeStaker Contract
Last Update: June 2022
## What is the GaugeStaker?
The [GaugeStaker contract](https://github.com/beefyfinance/beefy-contracts/blob/master/contracts/BIFI/strategies/Gauge/GaugeStaker.sol) is the central smart contract for the [binSPIRIT](/beefy-products/beefy-escrowed-tokens/deprecated-products/binspirit) token, which manages both the collection of SpiritSwap protocol revenue for inSPIRIT holders and the delivery of inSPIRIT farm boosts to other Beefy SpiritSwap vaults.
## How does the GaugeStaker work?
The GaugeStaker has three notable roles: (1) managing user SPIRIT deposits to accumulate inSPIRIT rewards; (2) managing voting for SpiritSwap boosted farms; and (3) passing tokens between other Beefy SpiritSwap strategies and boosted farming gauges.
When users deposit SPIRIT, the GaugeStaker will automatically stake the SPIRIT with SpiritSwap to receive non-transferrable inSPIRIT. All staked SPIRIT must also be locked (so cannot be withdrawn), so the GaugeStaker locks all deposits for the longest possible period of time (currently 4 years) to receive the maximum amount of inSPIRIT. Protocol revenue rewards accrue constantly on the locked SPIRIT, and the GaugeStaker automatically claims these rewards and returns them to the [Beefy binSPIRIT vault](https://app.beefy.finance/#/vault/beefy-binspirit) on a regular basis, where they are automatically compounded.
Holders of inSPIRIT are also entitled to [vote](/beefy-products/beefy-escrowed-tokens/deprecated-products/binspirit#can-i-vote-with-binspirit) in SpiritSwap governance and for the distribution of boosted farm rewards, so the GaugeStaker manages the allocation of these votes.
Finally, inSPIRIT holders also received boosted rewards on selected SpiritSwap farms. All boosted Beefy SpiritSwap vaults are configured to pass all of their deposits, withdrawals and harvesting of rewards through the GaugeStaker, to receive the benefits of the boost. This provides the highest possible boost across each of the farms, as the GaugeStaker holds the full concentration of Beefy's accumulated inSPIRIT.
## GaugeStaker Functionality
The GaugeStaker contract incorporates a range of different functionality and methods to execute its two roles. These include:
### Deposit SPIRIT to mint binSPIRIT
A user can deposit SPIRIT (`want`) and the contract will confirm the amount that is received by checking balances before and after the transfer. If the received amount is non-zero then check if an existing lock for SPIRIT exists, which it likely will unless the lock has not been initiated before or has been left to expire. If the lock exists then it will extended out to the full 4 years if the current lock time is less than the full amount, and the received balance of SPIRIT is locked to get a 1:1 amount of inSPIRIT. If no lock currently exists then create a new one and lock the balance of SPIRIT on the contract. Finally mint an equal amount of binSPIRIT as the received balance of SPIRIT from the user.
```solidity
// deposit 'want' and lock
function _deposit(address _user, uint256 _amount) internal nonReentrant whenNotPaused {
uint256 _pool = balanceOfWant();
want.safeTransferFrom(msg.sender, address(this), _amount);
uint256 _after = balanceOfWant();
_amount = _after.sub(_pool); // Additional check for deflationary tokens
if (_amount > 0) {
if (balanceOfVe() > 0) {
increaseUnlockTime();
veWant.increase_amount(_amount);
} else {
_createLock();
}
_mint(_user, _amount);
emit DepositWant(balanceOfVe());
}
}
```
### Vote on which gauges to boost
The Beefy Keeper can vote on gauge incentives using the inSPIRIT balance on the GaugeStaker as voting power. It will be mainly used to vote for Beefy and strategic partner's gauges, and can be governed by Beefy DAO to vote for various incentives on gauges. The voting function is a simple call to SpiritSwap's Gauge Proxy contract which records the votes and decides the distribution of gauge incentives. The Beefy keeper can split the voting power between multiple gauges in a single call using the parameter arrays.
```solidity
// vote on boosted farms
function vote(address[] calldata _tokenVote, uint256[] calldata _weights) external onlyManager {
gaugeProxy.vote(_tokenVote, _weights);
emit Vote(_tokenVote, _weights);
}
```
### Pass through tokens between strategies and gauges
Strategies for Beefy's SpiritSwap vaults must pass through their deposits, withdrawals and harvests to and from the GaugeStaker. Only a whitelisted strategy can interact with the GaugeStaker, and each gauge is assigned at most one strategy.
Deposits and withdrawals pass through the exact amount that is requested (`_amount`) in the token that is assigned to the gauge (`_underlying`). Harvests (`claimGaugeReward()`) pass through only the SPIRIT (`want`) reward that's received by the GaugeStaker when claiming the reward, ignoring the existing balance on the GaugeStaker. None of the funds are kept on the GaugeStaker, they are always passed across in the same transaction.
```solidity
// pass through a deposit to a gauge
function deposit(address _gauge, uint256 _amount) external onlyWhitelist(_gauge) {
address _underlying = IGauge(_gauge).TOKEN();
IERC20Upgradeable(_underlying).safeTransferFrom(msg.sender, address(this), _amount);
IGauge(_gauge).deposit(_amount);
}
// pass through a withdrawal from a gauge
function withdraw(address _gauge, uint256 _amount) external onlyWhitelist(_gauge) {
address _underlying = IGauge(_gauge).TOKEN();
IGauge(_gauge).withdraw(_amount);
IERC20Upgradeable(_underlying).safeTransfer(msg.sender, _amount);
}
// pass through rewards from a gauge
function claimGaugeReward(address _gauge) external onlyWhitelist(_gauge) {
uint256 _before = balanceOfWant();
IGauge(_gauge).getReward();
uint256 _balance = balanceOfWant().sub(_before);
want.safeTransfer(msg.sender, _balance);
}
```
### Claim SpiritSwap protocol fees
Holding inSPIRIT gives the GaugeStaker the right to claim a portion of SpiritSwap's protocol fees, which will be distributed to binSPIRIT stakers in a reward pool. The protocol fees are distributed once a week in the form of SPIRIT and need to be claimed from the Fee Distributor contract. The Reward Pool contract will call the claim function via `claimVeWantReward()`. Only the SPIRIT (`want`) reward is immediately passed back to the Reward Pool, if there is anything available to claim.
```solidity
// pass through rewards from the fee distributor
function claimVeWantReward() external onlyRewardPool {
uint256 _before = balanceOfWant();
feeDistributor.claim();
uint256 _balance = balanceOfWant().sub(_before);
want.safeTransfer(msg.sender, _balance);
}
```
### Whitelisting strategies
The Beefy Keeper can whitelist a strategy address as long as there isn't an active strategy that has funds deployed in the same gauge as the new strategy. An old strategy must be panicked before a new strategy for the same gauge can be tested, so user funds are always protected. The approval for the token (`_want`) assigned to the gauge is reset and increased to the max limit for spending by the gauge. The gauge is mapped to the whitelisted strategy and the strategy is allowed access to the GaugeStaker for the specified gauge.
```solidity
// whitelists a strategy address to interact with the Gauge Staker and gives approvals
function whitelistStrategy(address _strategy) external onlyManager {
IERC20Upgradeable _want = IGaugeStrategy(_strategy).want();
address _gauge = IGaugeStrategy(_strategy).gauge();
require(IGauge(_gauge).balanceOf(address(this)) == 0, '!inactive');
_want.safeApprove(_gauge, 0);
_want.safeApprove(_gauge, type(uint256).max);
whitelistedStrategy[_gauge] = _strategy;
}
```
### Upgrading strategies
A new strategy for a gauge with an existing strategy can be proposed once it has been fully tested. `proposeStrategy()` should be called on the GaugeStaker before `upgradeStrat()` on the vault so the switch will succeed. The new strategy must have the same gauge as the previous strategy. `upgradeStrategy()` is only called in `retireStrat()` on the previous strategy, so is controlled indirectly by the vault owner through upgrading the strategy address on the vault.
```solidity
// prepare a strategy to be retired and replaced with another
function proposeStrategy(address _oldStrategy, address _newStrategy) external onlyManager {
require(IGaugeStrategy(_oldStrategy).gauge() == IGaugeStrategy(_newStrategy).gauge(), '!gauge');
replacementStrategy[_oldStrategy] = _newStrategy;
}
// switch over whitelist from one strategy to another for a gauge
function upgradeStrategy(address _gauge) external onlyWhitelist(_gauge) {
whitelistedStrategy[_gauge] = replacementStrategy[msg.sender];
}
```
## Contracts
* binSPIRIT/GaugeStaker: [0x44e314190D9E4cE6d4C0903459204F8E21ff940A](https://ftmscan.com/address/0x44e314190D9E4cE6d4C0903459204F8E21ff940A)
* Reward Pool: [0xFAE44b30F6F9BbD44E6B7687471dd73D71FaBDC6](https://ftmscan.com/address/0xFAE44b30F6F9BbD44E6B7687471dd73D71FaBDC6)
Critical functions are always managed via multi-sig transactions and timelocks. No funds are stored directly on the GaugeStaker and only the active whitelisted strategy can interact with funds stored in a gauge.
# Third Party Contracts
# DelegateRegistry Contract
Last Update: February 2023
The [DelegateRegistry contract](https://github.com/gnosis/delegate-registry/blob/main/contracts/DelegateRegistry.sol) is a governance smart contract developed by Gnosis and used by Snapshot Labs to facilitate vote delegation in Snapshot-based governance spaces. Users can authorise another user to vote on their behalf using their voting power, by delegating to them on Ethereum. Users can also remove their delegations at any time.
Through this mechanism, trusted voices in the community can leverage their support with a small amount of effort on the part of their supporters. It also allows those short on time to ensure that their voting power is participating in governance, without requiring them to engage with every proposal that arises.
## Contract Mapping
The DelegateRegistry contract is first and foremost a repository of information on existing delegations, which are stored in the "delegation" mapping in the contract:
{% code overflow="wrap" %}
```solidity
// The first key is the delegator and the second key a id.
// The value is the address of the delegate
mapping (address => mapping (bytes32 => address)) public delegation;
```
{% endcode %}
Effectively, each delegation is stored by reference to the delegator's address (i.e. the user that is delegated their voting power), which is then mapped to the relevant Snapshot space ID (stored as a bytes32 value) and the delegate's address (i.e. the user that voting power is delegated to).
For full details of all delegations managed by Snapshot Labs' DelegateRegistry contract, you can explore the Snapshot Subgraph [here](https://thegraph.com/hosted-service/subgraph/snapshot-labs/snapshot).
## Contract Events
The DelegateRegistry contract emits two possible events in its ordinary operations.
### SetDelegate
Signifies that the contract's [#setdelegate-1](#setdelegate-1 "mention") function has successfully been called, and consequently the caller has selected a new delegate.
{% code overflow="wrap" %}
```solidity
// Using these events it is possible to process the events to build up reverse lookups.
// The indeces allow it to be very partial about how to build this lookup (e.g. only for a specific delegate).
event SetDelegate(address indexed delegator, bytes32 indexed id, address indexed delegate);
```
{% endcode %}
### ClearDelegate
Signifies that one of the below [#contract-functions](#contract-functions "mention") has successfully been called, and consequently the former delegate has been cleared for the caller.
{% code overflow="wrap" %}
```solidity
// Using these events it is possible to process the events to build up reverse lookups.
// The indeces allow it to be very partial about how to build this lookup (e.g. only for a specific delegate).
event ClearDelegate(address indexed delegator, bytes32 indexed id, address indexed delegate);
```
{% endcode %}
## Contract Functions
The functionality behind the DelegateRegistry contract is very straightforward, and consists of just two functions to set and remove delegates.
### setDelegate()
To set a delegate, the contract requires two inputs: the relevant Snapshot space ID (stored as a bytes32 value); and the delegate's address (i.e. the user that voting power is delegated to). It then tests the inputs against a few requirements (e.g. the user is not delegating to itself, to a null address or to its current delegate) before executing the call.
{% code overflow="wrap" %}
```solidity
/// @dev Sets a delegate for the msg.sender and a specific id.
/// The combination of msg.sender and the id can be seen as a unique key.
/// @param id Id for which the delegate should be set
/// @param delegate Address of the delegate
function setDelegate(bytes32 id, address delegate) public {
require (delegate != msg.sender, "Can't delegate to self");
require (delegate != address(0), "Can't delegate to 0x0");
address currentDelegate = delegation[msg.sender][id];
require (delegate != currentDelegate, "Already delegated to this address");
// Update delegation mapping
delegation[msg.sender][id] = delegate;
if (currentDelegate != address(0)) {
emit ClearDelegate(msg.sender, id, currentDelegate);
}
emit SetDelegate(msg.sender, id, delegate);
}
```
{% endcode %}
Where the call is successful, the function will update the delegation mapping to the new delegate address. It then tests whether the user had previously delegated to another user, and if so it will then emit the [#cleardelegate](#cleardelegate "mention") event to signify that the old delegate has been removed. Finally it will emit the [#setdelegate](#setdelegate "mention")event to signify that the new delegate has been added.
Please note that the function does not also require the contract to use the [#cleardelegate-1](#cleardelegate-1 "mention") function, which is only used to remove an existing delegate.
### clearDelegate()
To clear the current delegate, the contract requires one input, which is the relevant Snapshot space ID (stored as a bytes32 value). It then tests to ensure that a delegate has in fact been set before executing the call.
/// @dev Clears a delegate for the msg.sender and a specific id.
/// The combination of msg.sender and the id can be seen as a unique key.
/// @param id Id for which the delegate should be set
function clearDelegate(bytes32 id) public {
address currentDelegate = delegation[msg.sender][id];
require (currentDelegate != address(0), "No delegate set");
// update delegation mapping
delegation[msg.sender][id] = address(0);
emit ClearDelegate(msg.sender, id, currentDelegate);
}
Where the call is successful, the function will update the delegation mapping to the null address (i.e. singifying that the user has not delegated their voting power), and then emits the [#cleardelegate](#cleardelegate "mention") event to signify that the old delegate has been removed.
## Delegation Walkthrough
There are two main methods that users can adopt to interact with the DelegateRegistry contract: either interacting through the Snapshot interface or by interacting directly with the contract (e.g. through a relevant block explorer). Below are brief walkthroughs for each methods.
### Through the Snapshot Interface
1. Go to the [Snapshot interface delegation page](https://vote.beefy.finance/#/delegate/beefydao.eth).
2. Connect your wallet the site, so that it can detect your address and so you can call the [#setdelegate-1](#setdelegate-1 "mention") function.
3. Make sure you're connected to Ethereum with your wallet. **No other chain will work.**
4. Input the address or ENS name of the user you want to delegate your voting power to.
5. If you want to, you can select "limit delegation to a specific space" to confine your delegation to only the Beefy Snapshot space. To do so, input the following space: beefydao.eth.
6. Click "Confirm" to initiate the transaction in your wallet. As this is a write transaction (i.e. submitting information for storage on the blockchain), you will have to pay a small amount of gas to facilitate the transaction.
The Snapshot interface's delegation page provides a clean and simple way to delegate your voting power.
7. Once the transaction goes through, you will have successfully delegated to the user address that you provided across all chains that our BIFI token is deployed to.
### Through a Block Explorer
1. Go to the DelegateRegistry contract address on [Etherscan](https://etherscan.io/address/0x469788fE6E9E9681C6ebF3bF78e7Fd26Fc015446).
2. Navigate to the "Write Contract" subtab on the "Contract" tab on the contract page (as below).
3. Select the "Connect to Web3" button to connect your wallet and interact with the contract.
4. Make sure your wallet is set to Ethereum. **No other chain will work.**
The Etherscan interface will provide you with full access to all delegation methods, events and transactions, though they are clearly less user friendly for most users.
1. Scroll down to the [#setdelegate-1](#setdelegate-1 "mention") function, and input the required details, those being:
1. id (bytes32) - the address of the Snapshot space for which you are delegating (i.e. the Beefy Space ID: 0x626565667964616f2e657468).
2. delegate (address) - the address of the user you want to delegate your voting power to.
2. Click "Write" to initiate the transaction in your wallet. As this is a write transaction (i.e. submitting information for storage on the blockchain), you will have to pay a small amount of gas to facilitate the transaction.
The functions on each block explorer reflect those detailed in the #contract-functions section above.
3. Once the transaction goes through, you will have successfully delegated to the user address that you provided across all chains that our BIFI token is deployed to.
## Contracts
The DelegateRegistry contract and Beefy snapshot space are deployed at the following addresses:
* DelegateRegistry - [0x469788fE6E9E9681C6ebF3bF78e7Fd26Fc015446](https://etherscan.io/address/0x469788fE6E9E9681C6ebF3bF78e7Fd26Fc015446).
* Beefy Space ID - 0x626565667964616f2e657468 or beefydao.eth.
## More Information
For more details of how vote delegation works for Beefy's governance, see the [Governance](/dao/governance) page (specifically [Governance](/dao/governance#how-do-i-delegate-my-vote) and [Governance](/dao/governance#how-do-i-become-a-delegate)). You can also find the current maintained list of vote delegates in this [Google sheet](https://docs.google.com/spreadsheets/d/1sJH4jg3eEEJDpbws55qUmzPeLDiDuL_5OAQobSn7m2Y/edit?usp=sharing).
For full details of all delegations managed by Snapshot Labs' DelegateRegistry contract, you can explore the Snapshot Subgraph [here](https://thegraph.com/hosted-service/subgraph/snapshot-labs/snapshot). Further information in available in Snapshot's [documentation](https://docs.snapshot.org/guides/delegation).
# Oracle Contracts
Last Update: April 2025
Oracles are services which feed external data into blockchain ecosystems, for use by smart contracts across various functionalities. By far the largest use of oracles in Web 3.0 is price feed oracles, which help to provide a source of truth for the price of assets that do not have a local or reliable pricing mechanism that can be used.
Beefy's core products do not fundamentally rely on oracles for their ordinary operations. Unlike lending markets, which need rely fully on accurate pricing for protocol health (i.e. to enforce liquidations), ordinary deviations in the price of assets managed by Beefy smart contracts do not expose those assets to material risks in the ordinary course of our operations. As such, Beefy's reliance on oracles is safely constrained.
That notwithstanding, oracles provide a convenient means of optimising functionality across our systems for actions like swaps and pricing for our app.
### Chainlink Oracles
Chainlink provides a range of oracles to support Beefy's products across a number of chains:
**mooBIFI**
* Sonic: 0xc9541134848f525f8eaEA262599a1668A3a9b6eD
* Base: 0x721F1B4dc604AEA0661Aa9982AB624e5756B31f2
* Op: 0x4244c9aE5B97269B7301B622E22932FA49fBb763
**beS**
* Sonic: 0x15643d909F07e4083fCE3e3204F7e1A0A37D52f4
These oracles provide accurate and tamper-resistant prices, allowing Beefy's various tokens to be used in different applications across DeFi.
# Beefy API
Last Update: August 2023
This page provides further details about the functionality and operation of Beefy's REST API, which powers our web application, dashboard and pages on third party sites.
You can access the API at , and the public repository is available on [the Beefy GitHub](https://github.com/beefyfinance/beefy-api). The API is maintained under the MIT license, with further details available on the [GitHub repo](https://github.com/beefyfinance/beefy-api/blob/master/LICENSE).
## Endpoints
Our API offers a range of public endpoints covering the full selection of data required for our web app, backend and dashboard, as well as some third party services.
### Beefy Vault Endpoints
Endpoints developed for use by [the Beefy Application](https://app.beefy.finance/) to display vaults' live characteristics and performance to our users.
GET /vaults
Provides live information about each Beefy vault, including retired (eol) vaults.
The information includes fields for the relevant vault's name/ID, chain, token, underlying assets, related contracts and current status. It also includes the "risks" field, which lists the vault's features taken from the matrix of risk factors used to calculate a vault's safety score.
{% code overflow="wrap" %}
```json
// Sample response for the /vaults endpoint (e.g. Polygon aTriCrypto3 vault)
{
"id": "curve-poly-atricrypto3",
"name": "aTriCrypto3",
"token": "crvUSDBTCETH3",
"tokenAddress": "0xdAD97F7713Ae9437fa9249920eC8507e5FbB23d3",
"tokenDecimals": 18,
"tokenProviderId": "curve",
"earnedToken": "mooCurveATriCrypto3",
"earnedTokenAddress": "0x5A0801BAd20B6c62d86C566ca90688A6b9ea1d3f",
"earnContractAddress": "0x5A0801BAd20B6c62d86C566ca90688A6b9ea1d3f",
"oracle": "lps",
"oracleId": "curve-poly-atricrypto3",
"status": "active",
"platformId": "curve",
"assets": [
"DAI",
"USDC",
"USDT",
"WBTC",
"ETH"
],
"strategyTypeId": "multi-lp",
"risks": [
"COMPLEXITY_LOW",
"BATTLE_TESTED",
"IL_LOW",
"MCAP_LARGE",
"PLATFORM_ESTABLISHED",
"AUDIT",
"CONTRACTS_VERIFIED",
"OVER_COLLAT_ALGO_STABLECOIN"
],
"addLiquidityUrl": "https://polygon.curve.fi/atricrypto3/deposit",
"network": "polygon",
"createdAt": 1652662923,
"chain": "polygon",
"strategy": "0x41D7529b4C9245a50ca6A169d39719DFF117f6CA",
"lastHarvest": 1664612723,
"pricePerFullShare": "1178961451902175914"
},
```
{% endcode %}
#### Field Notes:
* **id** - the unique identifying string assigned to each vault, including separate versions of the same vault.
* **tokenAddress** - the contract address for the main deposit asset, typically an LP token.
* **earnedTokenAddress** - the contract of the token which is earned by the strategy used by the vault. For most Beefy vaults, this is the same as the vault contract, because the strategy is autocompounding. For earnings pool vaults (which don't autocompound), this will be the native token of the chain or protocol that the vault relates to.
* **earnContractAddress** - the address of the Beefy vault contract which handles deposits and withdrawals and issues the mooVault token to users.
* **status** - shows whether a vault is live ("active") or retired ("eol").
* **assets** - the underlying assets at the base of the relevant vault's stack (typically the assets included in the LP that the vault is built on).
* **strategyTypeID** - indicates what type of strategy is being utilised by the vault (e.g. "single" asset, "lp", "multi-lp", etc).
* **risks** - a list of the vault's applicable features taken from the matrix of factors used to calculate a vault's safety score.
* **network** - the relevant blockchain that the vault resides on.
* **createdAt** - the block of the relevant blockchain where the vault was created.
* **strategy** - the address of the strategy contract currently in use by the vault.
* **lastHarvest** - the block of the relevant blockchain where the vault was last harvested - i.e. where profits were collected from the strategy (and autocompounded, if applicable).
* **pricePerFullShare** - the current average price (denominated in the deposit asset, e.g. the underlying LP token) for each whole share of the vault's total issued share capital, reflecting the total value invested into the vault over its life divided by the number of shares of the vault issued.
GET /apy
Provides the current and live annual percentage yield of each Beefy vault.
{% code overflow="wrap" %}
```json
// Sample response for the /apy endpoint
{
...
"balancer-usdc-link-eth-bal-aave": 0.03705509745347668,
"balancer-matic-usdc-eth-bal": 0.052770609595836904,
"baby-wbnb-busd": 0.1612595689122669,
"baby-usdc-wbnb": 0.16031283171896837,
"balancer-vst-dai-usdt-usdc": 0.029489187277781825,
"balancer-bal-eth": 0.024578537703132453,
"curve-matic-stmatic": 0.08866966650936048,
"sushi-poly-weth-sx": 0.7135292677781775,
"sushi-poly-bct-klima": 0.0007036903322936716,
}
```
{% endcode %}
**Field Notes:**
* **Vault APY** - Each field reflects the unique id string of a vault, and returns a value which represents the live APY as a decimal. For instance, "0.037" represents 3.7% APY.
GET /apy/breakdown
Provides more detailed information relating to the yield of each Beefy vault, which is required to assess the expected APY based on factors like the APR, rate of compounding and applicable fees.
{% code overflow="wrap" %}
```json
// Sample response from the /apy/breakdown endpoint (e.g. Polygon Cometh UST-ETH LP)
{
"bifi-maxi": {
"totalApy": 0.07598675804818633
},
"cometh-must-eth": {
"vaultApr": 1.186973388240745,
"compoundingsPerYear": 2190,
"beefyPerformanceFee": 0.045,
"vaultApy": 2.1057844292858614,
"lpFee": 0.005,
"tradingApr": 0.22324214039526927,
"totalApy": 2.8825691266420788
}
}
```
{% endcode %}
#### Field Notes
* **vaultApr** - the annual percentage return of the vault, calculated from the expected yearly rewards of the vault, denominated in $USD, divided by the total amount invested in the vault, also in $USD.
* **compoundingsPerYear** - the estimated current number of compounding events ("harvest" calls) per year.
* **beefyPerformanceFee** - the flat Beefy performance fee included in the calculation.
* **vaultApy** - the annual percentage yield (APY) of the vault, calculated by compounding the vaultApr detailed above, using the compoundingsPerYear figure, and adjusting for the beefyPerformanceFee.
* **lpFee** - the Liquidity Provider (LP) fee charged for each trade.
* **tradingApr** - the annual interest received from trading fees, without applying or account for any compounding effect.
* **totalApy** - the known total APY, calculated as totalApy = (1 + vaultApy) \* (1 + tradingApr) - 1.
GET /tvl
Provides the current and live total value locked of each Beefy vault, which is the sum of the current market capitalisation of all of the assets currently held by the relevant vault, denominated in $USD.
```json
// Sample response from the /tvl endpoint
{
...
"optimism-bifi-maxi": 37679.65,
"velodrome-wsteth-weth": 295597.74,
"beets-lido-shuffle": 101185.39,
"beets-yellow-submarine": 5828.15,
"beets-its-mai-life": 178994.42,
"velodrome-usdc-mim": 488943.72,
"velodrome-weth-bifi": 133635.5,
...
}
```
GET /fees
Provides a detailed breakdown of the current fee structure for each Beefy vault.
```json
// Sample response from the /fees endpoint (e.g. Celo BIFI Maxi vault)
{
"celo-bifi-maxi": {
"performance": {
"total": 0.0005,
"strategist": 0,
"call": 0.0005,
"treasury": 0,
"stakers": 0
},
"withdraw": 0,
"lastUpdated": 1665603844026
},
...
}
```
**Field Notes:**
* **performance** - a list of the fee settings which together constitute the performance fee charged on every compounding event ("harvest") for each vault.
* **total** - the total performance fee charged, being the sum of the other facts in the "performance" list.
* **strategist** - the fee payable to the strategist that deploys the vault, as a form of incentive to encourage community contributions.
* **call** - the fee payable to the caller of the harvest function which gives rise to the compounding of the vault.
* **treasury** - the fee payable to the Beefy treasury to support the protocol.
* **stakers** - the fee payable to holders and stakers of the BIFI token, which is pay out to our BIFI Earnings Pool vaults or to buy back BIFI tokens for our BIFI Maxi vaults.
* **withdraw** - the fee charged on the value of your deposit upon withdrawal from the vault, to protect against attacks against and abuse of our vaults.
* **lastUpdated** - the block of the relevant blockchain for the vault from which the data in the API was last updated.
### External Asset Endpoints
Endpoints developed for use by [the Beefy Application](https://app.beefy.finance/) to display information about the assets underlying our Beefy vaults to our users.
GET /lps
Provides the current live prices of underlying liquidity pools used by each Beefy vaults.
{% code overflow="wrap" %}
```json
// Sample respones from the /lps endpoint
{
...
"crow-crow-bnb": 17.913780228255288,
"crow-crow-busd": 1.1650429579716788,
"czf-czf-bnb": 0.0025782563297118174,
"czf-czf-busd": 0.00013385738163789002,
"dark-dark-cro": 0.07756021296662909,
"dark-sky-cro": 1.6261613868777973,
"dfx-nzds-usdc": 0.5422606115320028,
"dfyn-aave-dfyn": 2.878265077862883,
"dfyn-bifi-dfyn": 6.083434553784047,
...
}
```
{% endcode %}
**Field Notes:**
* **LP Price** - each field reflects the unique oracleId string of an LP vault, and returns a value which represents the live price in USD. For instance, "1.165" represents a price of $1.17.
GET /lps/breakdown
Provides more detailed information relating to the liquidity pool used by each Beefy vault.
{% code overflow="wrap" %}
```json
// Sample response from the /lps/breakdown endpoint (eg. 2omb 2omb-2share LP)
{
"2omb-2omb-2share": {
"price": 0.29050984564246707,
"tokens": [
"0x7a6e4E3CC2ac9924605DCa4bA31d1831c84b44aE",
"0xc54A1684fD1bef1f077a336E6be4Bd9a3096a6Ca"
],
"balances": [
"114463.728388652710537014",
"391.331589320557497638"
],
"totalSupply": "5873.360029904692639438"
},
```
{% endcode %}
**Field Notes:**
* **price** - the current and live price per full share of the LP token, denominated in $USD.
* **tokens** - a list of the contract addresses of each of the underlying assets/tokens included in the LP.
* **balances** - a list of the current balances of each of the tokens in the vault, as listed in the previous field, denominated in the underlying token.
* **totalSupply** - the current and live number of LP tokens issued.
GET /tokens
Provides information on all of the tokens utilised by Beefy, including individual assets and currencies, staked assets and LPs, sorted by the blockchain each is deployed on.
```
// Sample response for /tokens endpoint (e.g. polygon spUSDC LP token)
{
"polygon": {
"spUSDC": {
"name": "Stargate USD Coin LP",
"symbol": "spUSDC",
"address": "0x1205f31718499dBf1fCa446663B532Ef87481fe1",
"decimals": 6
},
...
}
```
**Field Notes:**
* **name** - a string showing the full name of the token associated with the relevant ID.
* **symbol** - a string showing the symbol assigned to the token by the issuer.
* **address** - the contract address for the relevant token.
* **decimals** - the number of decimal permitted for the token by the issuer, representing how divisible it is on chain.
**GET /tokens/{blockchain}**
For further specificity, you can add a {blockchain} parameter to the /tokens endpoint to return only tokens on a given blockchain (e.g. /tokens/polygon returns only tokens issued on the Polygon blockchain).
### Other Beefy App Endpoints
Endpoints developed for use by [the Beefy Application](https://app.beefy.finance/) to display other information not relating to individual vaults.
GET /config
Provides information on the addresses of the current configuration of wallets used to operate each blockchain used by the [the Beefy Application](https://app.beefy.finance/).
**Field Notes:**
* **devMultisig** - the address of the Beefy developer multisignature wallet used to manage development updates on the chain.
* **treasuryMultisig** - the address of the Beefy treasury multisignature wallet used to manage Beefy's core treasury of funds on the chain.
* **strategyOwner** - the address of the standard Beefy wallet that acts as owner of strategy contracts on the chain.
* **vaultOwner** - the address of the standard Beefy wallet that acts as owner of vault contracts on the chain.
* **keeper** - the address of the standard Beefy wallet that acts as keeper of vault contracts on the chain. This includes managing the whitelist of strategies used by the vault, and pausing or panicking the vault if required.
* **treasurer** - the address of the standard Beefy wallet that acts as the treasurer on the chain. This includes managing payments from the treasury for various reasons, and is often the same wallet as the treasuryMultisig.
* **launchpoolOwner** - the address of the standard Beefy wallet that acts as owner of the launchpool/boost contracts deployed on the chain. This is often the same wallet as the devMultisig.
* **rewardPool** - the address of the standard Beefy wallet that holds the rewards allocated for boosts on the chain.
* **treasury** - the address of the standard Beefy wallet that acts as the treasury on the chain, and is managed by the treasurer and treasuryMultisig.
* **beefyFeeRecipient** - the address of the standard Beefy wallet that acts receives performance fees charged on harvests from all Beefy vaults on the chain.
* **bifiMaxiStrategy** - the address of the strategy attached to the native $BIFI Maxi vault on the chain.
* **voter** - the address of the standard Beefy wallet that is used to direct Beefy's voting power on various third party protocols.
* **beefyFeeConfig** - address of the upgradeable proxy contract used to set the configuration of performance fees charged for vaults on the chain.
**GET /config/{blockchain}**
For further specificity, you can add a {blockchain} parameter to the /config endpoint to return the configuration details of a given blockchain (e.g. /config/polygon returns only the details for the Polygon blockchain).
GET /boosts
Provides information on all [Launchpool Boosts](/beefy-products/boost) hosted by Beefy on the application, including live and historic boosts.
```
// Sample response from /boosts endpoint (e.g. Optimism BIFI-WETH LP token)
{
"id": "moo_velodrome-weth-bifi-beefy",
"poolId": "velodrome-weth-bifi",
"name": "Beefy",
"assets": [
"BIFI",
"ETH"
],
"tokenAddress": "0x3532b6f723948eF39d5DCf44C16855239aF81082",
"earnedToken": "OP",
"earnedTokenDecimals": 18,
"earnedTokenAddress": "0x4200000000000000000000000000000000000042",
"earnContractAddress": "0x8F755873546F4D0EDf7d41fF8604C8A632113eB7",
"earnedOracle": "tokens",
"earnedOracleId": "OP",
"partnership": true,
"status": "active",
"isMooStaked": true,
"partners": [
"beefy"
],
"chain": "optimism",
"periodFinish": 1667843632
},
...
```
**Field Notes:**
* **id** - the unique identifying string assigned to each vault, including separate versions of the same vault.
* **poolId** - the unique identifying string assigned to each LP that Beefy has vaulted, including separate versions of the same LP.
* **name** - the full name of the partner(s) which have funded the boost.
* **assets** - a list of the underlying assets used for the vault or any underlying LP.
* **tokenAddress** - the address of the Beefy vault contract which handles deposits and withdrawals and issues the mooVault token to users.
* **earnedToken** - the name of the boost reward token earned by boost participants.
* **earnedTokenDecimals** - the number of decimal places assigned and used for the earnedToken from its creation.
* **earnTokenAddress** - the contract address of the earnedToken.
* **earnContractAddress** - the contract address of the boost contract, which holds the assigned boost rewards and distributes them to boost participants.
* **isMooStaked** - whether the boost requires users to stake their mooTokens in a further contract with Beefy to receive the boost.
* **partners** - shorthand label for the partner(s) which have funded the boost.
* **periodFinish** - the block of the hosted blockchain where the boost ends.
**GET /boosts/{blockchain}**
For further specificity, you can add a {blockchain} parameter to the /boosts endpoint to return only boosts on a given blockchain (e.g. /boosts/polygon returns only boosts hosted on the Polygon blockchain).
GET /bifibuyback
Provides details of the daily amount of BIFI buyback carried out on each blockchain.
{% code overflow="wrap" %}
```json
// Sample response from the /bifibuyback endpoint (e.g. BSC data)
{
"bsc": {
"buybackTokenAmount": "0.377849674473987141",
"buybackUsdAmount": "121.1485184178464957989921757592912"
},
...
}
```
{% endcode %}
**Field Notes:**
* **buybackTokenAmount** - shows the current daily amount of $BIFI tokens bought back by the protocol on the relevant chain.
* **buybackUsdAmount** - shows the current value of the above in USD.
### Dashboard Endpoints
Endpoints developed for [the Beefy Dashboard](https://dashboard.beefy.finance/) to display overarching information about the protocol.
{% hint style="info" %}
Please note that the Dashboard site and the /earnings endpoint are both no longer actively maintained by Beefy. Though the Dashboard site remains live, it does not reflect every vault that has been implemented and every chain that Beefy has deployed to.
{% endhint %}
### Databarn Endpoints
Endpoints related to databarn, our historical data indexer. These endpoints are rate limited to maximum 5 requests per seconds. You may also want to try the [interactive swagger ui](https://databarn.beefy.com/api/v1/documentation) for these endpoints.
{% openapi src="/files/lvHZHcXp2EaAwLSxXdhK" path="/api/v1/beefy/timeline" method="get" %}
[json.json](https://3342042426-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MJZ0tXJc-hdgL-YTlPk-887967055%2Fuploads%2FSgsuKaXYsbsXid0j2up6%2Fjson.json?alt=media\&token=e443b5f1-b6c0-4b7b-a5fd-326f6a476abe)
{% endopenapi %}
{% openapi src="/files/lvHZHcXp2EaAwLSxXdhK" path="/api/v1/beefy/product/{chain}" method="get" %}
[json.json](https://3342042426-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MJZ0tXJc-hdgL-YTlPk-887967055%2Fuploads%2FSgsuKaXYsbsXid0j2up6%2Fjson.json?alt=media\&token=e443b5f1-b6c0-4b7b-a5fd-326f6a476abe)
{% endopenapi %}
{% openapi src="/files/lvHZHcXp2EaAwLSxXdhK" path="/api/v1/beefy/product/{chain}/{contract\_address}" method="get" %}
[json.json](https://3342042426-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MJZ0tXJc-hdgL-YTlPk-887967055%2Fuploads%2FSgsuKaXYsbsXid0j2up6%2Fjson.json?alt=media\&token=e443b5f1-b6c0-4b7b-a5fd-326f6a476abe)
{% endopenapi %}
{% openapi src="/files/lvHZHcXp2EaAwLSxXdhK" path="/api/v1/beefy/product/{chain}/{contract\_address}/tvl" method="get" %}
[json.json](https://3342042426-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MJZ0tXJc-hdgL-YTlPk-887967055%2Fuploads%2FSgsuKaXYsbsXid0j2up6%2Fjson.json?alt=media\&token=e443b5f1-b6c0-4b7b-a5fd-326f6a476abe)
{% endopenapi %}
{% openapi src="/files/lvHZHcXp2EaAwLSxXdhK" path="/api/v1/price/" method="get" %}
[json.json](https://3342042426-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MJZ0tXJc-hdgL-YTlPk-887967055%2Fuploads%2FSgsuKaXYsbsXid0j2up6%2Fjson.json?alt=media\&token=e443b5f1-b6c0-4b7b-a5fd-326f6a476abe)
{% endopenapi %}
{% openapi src="/files/lvHZHcXp2EaAwLSxXdhK" path="/api/v1/price/raw" method="get" %}
[json.json](https://3342042426-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MJZ0tXJc-hdgL-YTlPk-887967055%2Fuploads%2FSgsuKaXYsbsXid0j2up6%2Fjson.json?alt=media\&token=e443b5f1-b6c0-4b7b-a5fd-326f6a476abe)
{% endopenapi %}
### Third Party Endpoints
Endpoints required or utilised by third party platforms to display information about Beefy or its products on their sites.
GET /cmc
Provides information required by [CoinMarketCap](https://coinmarketcap.com/) in order to display Beefy vaults in their yield farming section.
{% code overflow="wrap" %}
```json
// Sample response for the /cmc endpoint
{
"provider": "Beefy",
"provider_logo": "https://beefy.finance/img/beefy.svg",
"links": [
{
"title": "Twitter",
"link": "https://twitter.com/beefyfinance"
},
{
"title": "Telegram",
"link": "https://t.me/beefyfinance"
},
{
"title": "Discord",
"link": "https://discord.gg/yq8wfHd"
},
{
"title": "Medium",
"link": "https://medium.com/beefyfinance"
},
{
"title": "Github",
"link": "https://github.com/beefyfinance"
}
],
"pools": [
{
"name": "BIFI Maxi",
"pair": "BIFI",
"pairLink": "https://app.beefy.finance/",
"logo": "https://beefy.finance/vaults/bifi/BIFI.png",
"poolRewards": [
"BIFI"
],
"apyId": "bifi-maxi",
"contract": "0xf7069e41C57EcC5F122093811d8c75bdB5f7c14e",
"oracle": "tokens",
"oracleId": "BIFI"
},
...
]
}
```
{% endcode %}
GET /supply
Provides information required by [Coingecko](https://coingecko.com/) in order to display BIFI's total supply and circulating supply on its site.
{% code overflow="wrap" %}
```json
// Sample response for the /supply endpoint
{
"total": 80000,
"circulating": 80000
}
```
{% endcode %}
## Subgraph
Please note that Beefy does not currently operate or maintain any subgraphs for our protocol.
Our friends at Messari have developed a subgraph for our presence on BSC chain, which is available at , and on The Graph's [website](https://thegraph.com/hosted-service/subgraph/messari/beefy-finance-bsc) (ID: QmfEtMEgjik9FSZdqAmp2DkNFG4M9TK4Go8uyCUj8EVxY6). Beefy has had no role in the development or maintenance of this subgraph. Please direct any questions or requests for assistance in relation to this subgraph directly to Messari.
## Other Data
For any readers seeking further information about Beefy and our protocol's performance, please head to the #📊-beefy-data channel in our [Discord server](https://discord.gg/yq8wfHd). We'll be happy to answer any questions you may have there and you're welcome to inspect the history of our discussions in that channel for further background into our data work.
You'll also find in that channel a collection of weekly reports on the breakdown of our $BIFI token across our different chains and vaults, which are lovingly prepared by core contributor EPETE.
# Contract Addresses
Last Update: September 2023
## $BIFI Token
Name
Chain
Address
Native $BIFI Token
Ethereum
0xb1f1ee126e9c96231cc3d3fad7c08b4cf873b1f1
## Beefy DAO Treasury
Name
Chain
Address
Arbitrum Treasury
Arbitrum
0x3f5eddad52C665A4AA011cd11A21E1d5107d7862
Aurora Treasury
Aurora
0x088C70Ddff3a3774825dd5e5EaDB356404248d83
Avalanche Treasury
Avalanche
0x26dE4EBffBE8d3d632A292c972E3594eFc2eCeEd
Base Treasury
Base
0x1A07DceEfeEbBA3D1873e2B92BeF190d2f11C3cB
BSC Treasury
BSC
0x7C780b8A63eE9B7d0F985E8a922Be38a1F7B2141
Canto Treasury
Canto
0xF09d213EE8a8B159C884b276b86E08E26B3bfF75
Celo Treasury
Celo
0xCA807D809f9639CEfb3d31a7951Cec3ab405a2fd
Cronos Treasury
Cronos
0xa9721Ae5042482D7a884A2138f580459B680920f
Ethereum Treasury
Ethereum
0xc9C61194682a3A5f56BF9Cd5B59EE63028aB6041
Emerald Treasury
Emerald
0x8FD0869271d26E6653f5d5650685630F75b6AEDf
Fantom Treasury
Fantom
0xdFf234670038dEfB2115Cf103F86dA5fB7CfD2D2
Fuse Treasury
Fuse
0x1C124c2CaB83b3C3B5D0f0899CeeA5e06964599F
Harmony Treasury
Harmony
0x523154a03180FD1CB26F39087441c9F91BcD0389
HECO Treasury
HECO
0xdbB72c8B7eBdD52A4813B9D262386dfDAB69c9bA
Kava Treasury
Kava
0x07F29FE11FbC17876D9376E3CD6F2112e81feA6F
Metis Treasury
Metis
0x0f9602B7E7146a9BaE16dB948281BebDb7C2D095
Moonbeam Treasury
Moonbeam
0x3E7F60B442CEAE0FE5e48e07EB85Cfb1Ed60e81A
Moonriver Treasury
Moonriver
0x617f12E04097F16e73934e84f35175a1B8196551
Optimism Treasury
Optimism
0x4ABa01FB8E1f6BFE80c56Deb367f19F35Df0f4aE
Polygon PoS Treasury
Polygon
0xe37dD9A535c1D3c9fC33e3295B7e08bD1C42218D
Polygon zkEVM Treasury
zkEVM
0x6fdfb18D09d5fa9a76ac76cb6Cdc53c8F23C3B29
zkSync Treasury
zkSync
0x9F9FE15FDa14eAA2d878Ed667C805A7CC13c2560
Beef Nugget Treasury
All
0xD38d0DD50D03cEA499Df2b4C8D4B47458bEE9358
ChiliConCarne Treasury
All
0x6fCE222540015290FB572C82622dc73a431CdF3F
DefiDebauchery Treasury
All
0x037465bF6a4A8D7F552AE18046478C6A727178F3
Moodini Treasury
All
0xDae7624267E4515F40266a38505F4f7e13dBf6c4
Red Bull Treasury
All
0x03e7302e3EcBA4C1bd0e1841B55BF2C939E03fd3
Ser Loin Treasury
All
0xa2894cec4A49014b00E84e71861344fc794b8C27
TBC Treasury
All
0x428b2F01Bfb0917FE6FF463f37B0c47F1782B9Cd
YR Treasury
All
0xF24f555d6765D559BFF4C5557dD9024CBA10d30e
# Code Repositories
Last Update: September 2023
## Frontends
* Beefy Vaults
* Site:
* Repo:
* Beefy Landing
* Site:
* Repo:
* Beefy Governance
* Repo:
* Beefy Vote
* Site:
* Repo:
* Beefy Dashboard
* Site:
* Repo:
## Backend
* Beefy API
* Site: [https://api.beefy.finance/](https://api.beefy.finance/apy)
* Repo:
* Further details available on the [Beefy API](/developer-documentation/beefy-api) page.
## Smart Contracts
* [BIFI Token](https://etherscan.io/address/0xb1f1ee126e9c96231cc3d3fad7c08b4cf873b1f1)