Skip to main content

Deploying a Vault and Strategy V2

Note: This repo is encouraged to create multiple scripts for governance and dev multisig execution of complex transactions.


Make sure you have the brownie environment setup before trying to deploy a vault. Check out the Readme MD in Yearn Vaults Repo for instructions.

The below instructions show some python commands that assume you are using the brownie console or a brownie script setup is in place.

Deploying a new Experimental Vault#

  1. Clone the Yearn Vaults Repo and run brownie run scripts/ --network <network-to-deploy-vault>

  2. Choose the brownie account for deploying your vault. This account needs to have balance to pay for the deploy transaction.

  3. Confirm the script is using the latest version of registry v2.registry.ychad.eth against the planned new release vault to be sure its an updated version. (Can validate on Etherscan for latest address)

  4. Select the version of vault to deploy or press enter to use latest release.

  5. Enter Y when prompt to deploy Proxy Vault

  6. Enter the checksummed address of the ERC20 token the vault will use.

  7. Enter the vault Parameters (Below are some suggested values):

    • Set your address or an address you control as governance.
    • Set Treasury (treasury.ychad.eth) as the rewards address.
    • Set Core Dev multisig (dev.ychad.eth) as guardian.
    • Set Strategist multisig (brain.ychad.eth) as management.
    • Set description and symbol for vault or use suggested as default (can be changed on chain later)
  8. Confirm the Parameters are set correctly and press yand ENTER to deploy vault.

  9. Check new vault has ABI setup on Etherscan (Some vault versions from older releases may have verification issues with Vyper and proxy detection on Etherscan, consider using latest releases >0.3.5 to ensure verification works).

  10. Set up the vault with correct deposit limit:

  11. Set management fee to 0:

  12. (Optional) Set governance to ychad.eth (0xFEB4acf3df3cDEA7399794D0869ef76A6EfAff52) if vault is planned to be endorsed soon:

  • Note you can still make changes to the vault after setting governance up until governance is accepted

Deploying a new Strategy#

  1. Create a new issue in the strategies' repo using the template Strategy Review. Complete all the fields.
  2. If the strategy is targeting a new protocol/new chain, not currently approved by yearn (used in production), a due diligence and path to production plan documents may also be required for the strategy to be considered for endorsing. Examples SNX, VESPER
  3. Coordinate with Core Dev strategist for getting a review on board.
  4. Complete peer review by at least 2 strategists.
  5. Check if want token has a deployed vault already (>=v0.3.0) and coordinate to use that first if possible.
  6. Coordinate with core developer to set proper deposit limit and other settings for new vault. See the table below: Limits per Stage.
  7. Deploy strategy and upload code to Etherscan for verification.
  8. Tag GitHub review issue with deployed version and add mainnet address(es) to the board.

Make the Vault and Strategy work together#

  1. Add strategy to vault (for vault code v0.3.3+):

    strategy = ''                     # Your strategy addressdebt_ratio = 9800                 # 98%minDebtPerHarvest = 0             # Lower limit on debt addmaxDebtPerHarvest = 2 ** 256 - 1  # Upper limit on debt addperformance_fee = 1000            # Strategist perf fee: 10%
    vault.addStrategy(  strategy,  debt_ratio,  minDebtPerHarvest,  maxDebtPerHarvest,  performance_fee)
    • debt_ratio should be 9800 if first strategy on vault.
    • rate_limit is 0 unless there is reason for it to be different.
  2. Set keeper:

    • keep3r_manager = 0x736D7e3c5a6CB2CE3B764300140ABF476F6CFCCF
  3. Set health check:

    • health_check = 0xddcea799ff1699e98edf118e0629a974df7df012

NOTE: see section on health check for more details.

  1. Set rewards:

    • Read below if you want to use the sharer contract.
  2. Run tests against "live" vault and strategy in mainnet-fork:

    • Harvest.

    • Profitable harvest.

    • Revoke strategy and check that funds return to the vault.

    • Increase/decrease debt + harvest, and check that the strategy is working well.

    • Migration.

    • Check that tokens in the strategy cannot be sweeped by dust collection.

    • Example: Hegic strat repo.

Test harvesting manually#

If you need a UI to test, you can coordinate with the strategists.

  1. Deposit some want tokens into the vault.

  2. Do first harvest and make sure it worked correctly.

  3. Monitor harvest and tend triggers for first few days. Call harvest/tend manually.

Scaling up / Moving to Endorse#

In addition to the 2 strategists, a Core Developer has to review the strategy before going into production.

  1. Increase deposit limit according to the table below

  2. Set management fee to production level:

  3. Set parameters for vault correctly before endorse:

    • Set Governance to (ychad.eth)
    • Set Treasury (treasury.ychad.eth) as the rewards address.
    • Set Core Dev multisig (dev.ychad.eth) as guardian.
    • Set Strategist multisig (brain.ychad.eth) as management.
    • Set description and symbol for vault or use suggested as default (can be changed on chain later)
  4. Yearn governance now must accept governance and endorse the vault:

  1. Update the Ledger Plugin for users to be able to use the vault from Ledger Live. See more.

Endorsing a vault from a previous release#

  1. Check for latest release number in the registry contract

  2. Check the apiVersion of the vault you want to endorse to identify target release

  3. Calculate the releaseDelta from your target release. (see registry endorseVault param details) E.g: latestRelease = 0.3.3 and numReleases = 5. New vault apiVersion is 0.3.2 releaseDelta = numReleases - 1 - releaseTarget

  4. Confirm using registry.releases(uint256) that your targetRelease has the same apiVersion as your vault.

    releaseTarget = 3 # e.g vault api version 0.3.2releaseDelta = registry.numReleases() - 1 - releaseTarget # (5-1-3) = 1strategy.acceptGovernance() # from ychad.ethregistry.endorseVault(vault, releaseDelta) # from ychad.eth.

Publishing Your Strategy Description#

These steps are required for all strategies. These descriptions will be pulled into the new v3 website and used to generate strategy diagrams.

  1. Create a pull request at this link to add a new .json file with your strategy description and details.
  2. Using other strategy files as a reference, create a 1-2 sentence description for your strategy.
  3. The author field is optional.

Setting up Keep3r#

  1. Adjust trigger variables until they are correct:

  2. Set strategy's Keep3r role to v2-keeper-contract

  3. Create an add-strategy PR in Keep3r repo (TBD)


Limits per Stage#

These are the standard deposit limits per stage. They can be adjusted on a case by case basis.


Sharer contract#

"Sharer" is a contract for distributing/splitting strategist rewards. For boarding school graduates suggested split is 34% to strategist multisig and 66% to strategist – Sharer Contract.

  • Setup rewards for your strategy by calling sharer.addContributors.
  • Include devs if you forked someone else's strategy.
  • Be sure to reward people who helped you.
  • You can find the sharer here: 0x2c641e14afecb16b4aa6601a40ee60c3cc792f7d

Health Checks#

Since the v0.4.3 release, we introduce the concept of Health Checks contracts to vaults and strategies. These are helper contracts that can validate the end state of a harvest, or critical transaction, to ensure the accounting stays within established safe parameters.

You can think of these contracts as on-chain unit tests, or "self asserts" that ensure that the end state of a critical transaction matches an expected condition. The design allows for health checks to be configured per individual vault or strategy. In case the "assert" doesn't match expectations the entire transaction will revert and will require manual intervention by strategists, or core devs.

Vaults from release v0.4.3 and onward, support attaching an on-chain health check contract to be called after every harvest report.

Note on Health Checks Backward Compatibility#

The health checks are designed to be backward compatible. To target already deployed vaults, we released a patch for each tagged release of BaseStrategy. e.g:

v0.3.5 -> v0.3.5-1 (compatible version)

Adding Health Checks to your strategy#

  1. Before deploying a strategy with brownie-strategy-mix make sure your brownie-config.yml points to the correct patched vault version, to get a Health Check enabled BaseStrategy imported to your strategy.

  2. No change should be necessary on your extended Strategy logic to interact with the health check contract. IMPORTANT: Check your contract size to see if refactoring is needed for compilation.

  3. Update your unit tests to set to the common Health Check contract health.ychad.eth

commonHealthCheck = Contract(web3.ens.resolve(“health.ychad.eth”))strategy.setHealthCheck(commonHealthCheck)
  1. Test your normal harvest operations using mainnet-fork and unit tests to validate that the integration is working correctly.

Health Check Operations#

A global setting is used to check against deviations in reported profit and losses that are within a safe interval. Any report/harvest that falls outside this global safe interval will report.

In case there is a harvest/report revert transaction detected on-chain manual intervention is required to debug and accept the transaction into the vaults accounting. This should be done after proper validation by the strategist's multi-sig and Core Devs group.

Disabling health checks is meant to be a one-time special event using the following steps:

# disables next health check on harveststrategy.setDoHealthCheck(false, { account: brain.ychad.eth })
# do harvest with profit/loss deviationstrategy.harvest()

After this manual harvest, the health check will be automatically enabled back for further harvests.

NOT RECOMMENDED: Health checks can be disabled permanently by setting the health check contract to address 0x0 in the Strategy Contract. This should be done only in extreme circumstances and if you know what you are doing.

Customizing Health Checks#

The Common Health Check Contract health.ychad.eth uses a global default setting for profit and loss.

It also supports setting specific profit/loss limit checks per strategy via the following operation:

strategy = ''; # strategy addressprofitLimit = 100 # in bpslossLimit = 100 # in bpshealthcheck.setStrategyLimits(strategy, profitLimit, lossLimit)

Finally, if needed, a custom Health Check contract can be deployed and attached to the common Health Check contract, which works as a registry. You can attach a custom Health Check to a strategy using the following operation:

strategy = ''; # strategy addresscustomHealthCheck = '' # custom health check address
healthcheck.setCheck(strategy, customHealthCheck)

Custom Health Check must follow the interface for custom health checks


V2 Registryv2.registry.ychad.eth0x50c1a2eA0a861A967D9d0FFE2AE4012c2E053804
Yearn multisig (daddy)ychad.eth0xFEB4acf3df3cDEA7399794D0869ef76A6EfAff52
Strategist multisigbrain.ychad.eth0x16388463d60FFE0661Cf7F1f31a7D658aC790ff7
Core Dev multisigdev.ychad.eth0x846e211e8ba920B353FB717631C015cf04061Cc9
Health Checkhealth.ychad.eth0xDDCea799fF1699e98EDF118e0629A974Df7DF012