Badger Finance
Base Structure


Core functionality common to all Strategies.


There are a number of permissioned roles within the system:
  • Governance has the right to modify most parameters of the strategy, such as fees.
  • Strategist can execute core strategy functions and pause / unpause the strategy.
  • Controller refers to the corresponding Controller contract.
  • Keeper can deposit, tend, and harvest, to optimize the strategy yield.
  • Guardian can pause the strategy. Intended to be a trusted party that can act fast in emergency situations.


Strategies come with these standard fees, which are all optional. Setting a fee to 0 disables it. Fees can be set at any point by Governance. Fees are stored as basis point values.
  • Strategy Performance Fee
  • Governance Performance Fee
  • Withdrawal Fee
Performance fees should be handled on harvest(). It's up to each strategy to implement this.
Withdrawal fees are handled in the default withdraw() method scaffolding.


Takes any 'want' token present in the Strategy ('want' refers to the underlying asset for the Strategy) and deposits it into strategies chosen positions to generate yield.


Harvest is used to realize gains from positions into the underlying. Performance fees are taken at this point. Harvesting is a permissioned function, relegated to Governance, Strategist, and Keepers.


Withdraw a specified amount of underlying from positions. If there is any underlying sitting in the Strategy, it is withdrawn first. If more is required, it is up to the Strategy to determine how best to do this with minimal disruption, and how to withdraw the correct amount.


The strategy should exit all positions and send all tokens to the controller. This is typically used when migrating strategies. It is not specified how to handle gains in tokens that are not the underlying. They could be converted to underlying, or sent to governance to manage.The strategy-specific logic should override the _withdrawAll() internal function.

Extending the Base Strategy

All strategies must implement the following logic to be compliant with the architecture.


Inner logic for deposits. The Strategy should deposit the want specified into positions.


A hook that runs after the core deposit logic. Used for interacting with tokens that are acquired during the deposit process (e.g. depositing wrapped tokens from another vault into staking rewards)


The controller can withdraw unexpected tokens from the strategy. Unexpected tokens could arrive from direct transfers to the strategy, or from other contracts such as a new LP rewards program.
This function must define which tokens are NOT withdraw-able, which should include the want and any other tokens involved in the normal operation of the strategy.


Inner logic for withdrawals. Should exit positions in the minimal and most efficient way possible up to the specified amount desired. Returns the actual amount withdrawn.


Inner logic for Strategy migrations. Should exit positions completely in the most efficient way possible. Any un-realized rewards should be send directly to the controller rewards contract for manual distribution by governance.


Return the name of the strategy. This is useful for UI elements.


Return the balance of assets within the Strategy's positions.