Vault.vy

Vault.vy

Functions

initialize

Parameters:

initialize

Parameters:

initialize

Parameters:

apiVersion

Return Values:

setName

Parameters:

setSymbol

Parameters:

setGovernance

Parameters:

acceptGovernance

setManagement

Parameters:

setRewards

Parameters:

setLockedProfitDegradation

Parameters:

setDepositLimit

Parameters:

setPerformanceFee

Parameters:

setManagementFee

Parameters:

setGuardian

Parameters:

setEmergencyShutdown

Parameters:

setWithdrawalQueue

Parameters:

transfer

Parameters:

Return Values:

transferFrom

Parameters:

Return Values:

approve

Parameters:

increaseAllowance

Parameters:

decreaseAllowance

Parameters:

permit

Parameters:

Return Values:

totalAssets

Return Values:

deposit

Parameters:

Return Values:

deposit

Parameters:

Return Values:

deposit

Parameters:

Return Values:

maxAvailableShares

Return Values:

withdraw

Parameters:

Return Values:

withdraw

Parameters:

Return Values:

withdraw

Parameters:

Return Values:

withdraw

Parameters:

Return Values:

pricePerShare

Return Values:

addStrategy

Parameters:

updateStrategyDebtRatio

Parameters:

updateStrategyMinDebtPerHarvest

Parameters:

updateStrategyMaxDebtPerHarvest

Parameters:

updateStrategyPerformanceFee

Parameters:

migrateStrategy

Parameters:

revokeStrategy

Parameters:

revokeStrategy

Parameters:

addStrategyToQueue

Parameters:

removeStrategyFromQueue

Parameters:

debtOutstanding

Parameters:

Return Values:

debtOutstanding

Parameters:

Return Values:

creditAvailable

Parameters:

Return Values:

creditAvailable

Parameters:

Return Values:

expectedReturn

Parameters:

Return Values:

expectedReturn

Parameters:

Return Values:

report

Parameters:

Return Values:

sweep

Parameters:

sweep

Parameters:

Events

# Vault.vy

Yearn Token Vault

Yearn Token Vault. Holds an underlying token, and allows users to interact with the Yearn ecosystem through Strategies connected to the Vault. Vaults are not limited to a single Strategy, they can have as many Strategies as can be designed (however the withdrawal queue is capped at 20.) Deposited funds are moved into the most impactful strategy that has not already reached its limit for assets under management, regardless of which Strategy a user's funds end up in, they receive their portion of yields generated across all Strategies. When a user withdraws, if there are no funds sitting undeployed in the Vault, the Vault withdraws funds from Strategies in the order of least impact. (Funds are taken from the Strategy that will disturb everyone's gains the least, then the next least, etc.) In order to achieve this, the withdrawal queue's order must be properly set and managed by the community (through governance). Vault Strategies are parameterized to pursue the highest risk-adjusted yield. There is an "Emergency Shutdown" mode. When the Vault is put into emergency shutdown, assets will be recalled from the Strategies as quickly as is practical (given on-chain conditions), minimizing loss. Deposits are halted, new Strategies may not be added, and each Strategy exits with the minimum possible damage to position, while opening up deposits to be withdrawn by users. There are no restrictions on withdrawals above what is expected under Normal Operation. For further details, please refer to the specification: https://github.com/iearn-finance/yearn-vaults/blob/master/SPECIFICATION.md

## Functions

### initialize

```
function initialize(address,address,address,string,string)
```

Initializes the Vault, this is called only once, when the contract is deployed. The performance fee is set to 10% of yield, per Strategy. The management fee is set to 2%, per year. The initial deposit limit is set to 0 (deposits disabled); it must be updated after initialization.

If `nameOverride` is not specified, the name will be 'yearn' combined with the name of `token`. If `symbolOverride` is not specified, the symbol will be 'yv' combined with the symbol of `token`. The token used by the vault should not change balances outside transfers and it must transfer the exact amount requested. Fee on transfer and rebasing are not supported.

#### Parameters:

NameTypeDescription* token ** ** The token that may be deposited into this Vault. ** governance ** ** The address authorized for governance interactions. ** rewards ** ** The address to distribute rewards to. ** management ** ** The address of the vault manager. ** nameOverride ** ** Specify a custom Vault name. Leave empty for default choice. ** symbolOverride ** ** Specify a custom Vault symbol name. Leave empty for default choice. ** guardian ** ** The address authorized for guardian interactions. Defaults to caller. *

### initialize

```
function initialize(address,address,address,string,string,address)
```

If `nameOverride` is not specified, the name will be 'yearn' combined with the name of `token`. If `symbolOverride` is not specified, the symbol will be 'yv' combined with the symbol of `token`. The token used by the vault should not change balances outside transfers and it must transfer the exact amount requested. Fee on transfer and rebasing are not supported.

#### Parameters:

NameTypeDescription* token ** ** The token that may be deposited into this Vault. ** governance ** ** The address authorized for governance interactions. ** rewards ** ** The address to distribute rewards to. ** management ** ** The address of the vault manager. ** nameOverride ** ** Specify a custom Vault name. Leave empty for default choice. ** symbolOverride ** ** Specify a custom Vault symbol name. Leave empty for default choice. ** guardian ** ** The address authorized for guardian interactions. Defaults to caller. *

### initialize

```
function initialize(address,address,address,string,string,address,address)
```

If `nameOverride` is not specified, the name will be 'yearn' combined with the name of `token`. If `symbolOverride` is not specified, the symbol will be 'yv' combined with the symbol of `token`. The token used by the vault should not change balances outside transfers and it must transfer the exact amount requested. Fee on transfer and rebasing are not supported.

#### Parameters:

NameTypeDescription* token ** ** The token that may be deposited into this Vault. ** governance ** ** The address authorized for governance interactions. ** rewards ** ** The address to distribute rewards to. ** management ** ** The address of the vault manager. ** nameOverride ** ** Specify a custom Vault name. Leave empty for default choice. ** symbolOverride ** ** Specify a custom Vault symbol name. Leave empty for default choice. ** guardian ** ** The address authorized for guardian interactions. Defaults to caller. *

### apiVersion

```
function apiVersion()
```

Used to track the deployed version of this contract. In practice you can use this version number to compare with Yearn's GitHub and determine which version of the source matches this deployed contract.

All strategies must have an `apiVersion()` that matches the Vault's `API_VERSION`.

#### Return Values:

Description* API_VERSION which holds the current version of this contract. *

### setName

```
function setName(string)
```

Used to change the value of `name`. This may only be called by governance.

#### Parameters:

NameTypeDescription* name ** ** The new name to use. *

### setSymbol

```
function setSymbol(string)
```

Used to change the value of `symbol`. This may only be called by governance.

#### Parameters:

NameTypeDescription* symbol ** ** The new symbol to use. *

### setGovernance

```
function setGovernance(address)
```

Nominate a new address to use as governance. The change does not go into effect immediately. This function sets a pending change, and the governance address is not updated until the proposed governance address has accepted the responsibility. This may only be called by the current governance address.

#### Parameters:

NameTypeDescription* governance ** ** The address requested to take over Vault governance. *

### acceptGovernance

```
function acceptGovernance()
```

Once a new governance address has been proposed using setGovernance(), this function may be called by the proposed address to accept the responsibility of taking over governance for this contract. This may only be called by the proposed governance address.

setGovernance() should be called by the existing governance address, prior to calling this function.

### setManagement

```
function setManagement(address)
```

Changes the management address. Management is able to make some investment decisions adjusting parameters. This may only be called by governance.

#### Parameters:

NameTypeDescription* management ** ** The address to use for managing. *

### setRewards

```
function setRewards(address)
```

Changes the rewards address. Any distributed rewards will cease flowing to the old address and begin flowing to this address once the change is in effect. This will not change any Strategy reports in progress, only new reports made after this change goes into effect. This may only be called by governance.

#### Parameters:

NameTypeDescription* rewards ** ** The address to use for collecting rewards. *

### setLockedProfitDegradation

```
function setLockedProfitDegradation(uint256)
```

Changes the locked profit degradation.

#### Parameters:

NameTypeDescription* degradation ** ** The rate of degradation in percent per second scaled to 1e18. *

### setDepositLimit

```
function setDepositLimit(uint256)
```

Changes the maximum amount of tokens that can be deposited in this Vault. Note, this is not how much may be deposited by a single depositor, but the maximum amount that may be deposited across all depositors. This may only be called by governance.

#### Parameters:

NameTypeDescription* limit ** ** The new deposit limit to use. *

### setPerformanceFee

```
function setPerformanceFee(uint256)
```

Used to change the value of `performanceFee`. Should set this value below the maximum strategist performance fee. This may only be called by governance.

#### Parameters:

NameTypeDescription* fee ** ** The new performance fee to use. *

### setManagementFee

```
function setManagementFee(uint256)
```

Used to change the value of `managementFee`. This may only be called by governance.

#### Parameters:

NameTypeDescription* fee ** ** The new management fee to use. *

### setGuardian

```
function setGuardian(address)
```

Used to change the address of `guardian`. This may only be called by governance or the existing guardian.

#### Parameters:

NameTypeDescription* guardian ** ** The new guardian address to use. *

### setEmergencyShutdown

```
function setEmergencyShutdown(bool)
```

Activates or deactivates Vault mode where all Strategies go into full withdrawal. During Emergency Shutdown: 1. No Users may deposit into the Vault (but may withdraw as usual.) 2. Governance may not add new Strategies. 3. Each Strategy must pay back their debt as quickly as reasonable to minimally affect their position. 4. Only Governance may undo Emergency Shutdown. See contract level note for further details. This may only be called by governance or the guardian.

#### Parameters:

NameTypeDescription* active ** ** If true, the Vault goes into Emergency Shutdown. If false, the Vault goes back into Normal Operation. *

### setWithdrawalQueue

```
function setWithdrawalQueue(address[20])
```

Updates the withdrawalQueue to match the addresses and order specified by `queue`. There can be fewer strategies than the maximum, as well as fewer than the total number of strategies active in the vault. `withdrawalQueue` will be updated in a gas-efficient manner, assuming the input is well- ordered with 0x0 only at the end. This may only be called by governance or management.

This is order sensitive, specify the addresses in the order in which funds should be withdrawn (so `queue`[0] is the first Strategy withdrawn from, `queue`[1] is the second, etc.) This means that the least impactful Strategy (the Strategy that will have its core positions impacted the least by having funds removed) should be at `queue`[0], then the next least impactful at `queue`[1], and so on.

#### Parameters:

NameTypeDescription* queue ** ** The array of addresses to use as the new withdrawal queue. This is order sensitive. *

### transfer

```
function transfer(address,uint256)
```

Transfers shares from the caller's address to `receiver`. This function will always return true, unless the user is attempting to transfer shares to this contract's address, or to 0x0.

#### Parameters:

NameTypeDescription* receiver ** ** The address shares are being transferred to. Must not be this contract's address, must not be 0x0. ** amount ** ** The quantity of shares to transfer. *

#### Return Values:

Description* True if transfer is sent to an address other than this contract's or 0x0, otherwise the transaction will fail. *

### transferFrom

```
function transferFrom(address,address,uint256)
```

Transfers `amount` shares from `sender` to `receiver`. This operation will always return true, unless the user is attempting to transfer shares to this contract's address, or to 0x0. Unless the caller has given this contract unlimited approval, transfering shares will decrement the caller's `allowance` by `amount`.

#### Parameters:

NameTypeDescription* sender ** ** The address shares are being transferred from. ** receiver ** ** The address shares are being transferred to. Must not be this contract's address, must not be 0x0. ** amount ** ** The quantity of shares to transfer. *

#### Return Values:

Description* True if transfer is sent to an address other than this contract's or 0x0, otherwise the transaction will fail. *

### approve

```
function approve(address,uint256)
```

Approve the passed address to spend the specified amount of tokens on behalf of `msg.sender`. Beware that changing an allowance with this method brings the risk that someone may use both the old and the new allowance by unfortunate transaction ordering. See https://github.com/ethereum/EIPs/issues/20#issuecomment-263524729

#### Parameters:

NameTypeDescription* spender ** ** The address which will spend the funds. ** amount ** ** The amount of tokens to be spent. *

### increaseAllowance

```
function increaseAllowance(address,uint256)
```

Increase the allowance of the passed address to spend the total amount of tokens on behalf of msg.sender. This method mitigates the risk that someone may use both the old and the new allowance by unfortunate transaction ordering. See https://github.com/ethereum/EIPs/issues/20#issuecomment-263524729

#### Parameters:

NameTypeDescription* spender ** ** The address which will spend the funds. ** amount ** ** The amount of tokens to increase the allowance by. *

### decreaseAllowance

```
function decreaseAllowance(address,uint256)
```

Decrease the allowance of the passed address to spend the total amount of tokens on behalf of msg.sender. This method mitigates the risk that someone may use both the old and the new allowance by unfortunate transaction ordering. See https://github.com/ethereum/EIPs/issues/20#issuecomment-263524729

#### Parameters:

NameTypeDescription* spender ** ** The address which will spend the funds. ** amount ** ** The amount of tokens to decrease the allowance by. *

### permit

```
function permit(address,address,uint256,uint256,bytes)
```

Approves spender by owner's signature to expend owner's tokens. See https://eips.ethereum.org/EIPS/eip-2612.

#### Parameters:

NameTypeDescription* owner ** ** The address which is a source of funds and has signed the Permit. ** spender ** ** The address which is allowed to spend the funds. ** amount ** ** The amount of tokens to be spent. ** expiry ** ** The timestamp after which the Permit is no longer valid. ** signature ** ** A valid secp256k1 signature of Permit by owner encoded as r, s, v. *

#### Return Values:

Description* True, if transaction completes successfully *

### totalAssets

```
function totalAssets()
```

Returns the total quantity of all assets under control of this Vault, whether they're loaned out to a Strategy, or currently held in the Vault.

#### Return Values:

Description* The total assets under control of this Vault. *

### deposit

```
function deposit()
```

Deposits `_amount` `token`, issuing shares to `recipient`. If the Vault is in Emergency Shutdown, deposits will not be accepted and this call will fail.

Measuring quantity of shares to issues is based on the total outstanding debt that this contract has ("expected value") instead of the total balance sheet it has ("estimated value") has important security considerations, and is done intentionally. If this value were measured against external systems, it could be purposely manipulated by an attacker to withdraw more assets than they otherwise should be able to claim by redeeming their shares. On deposit, this means that shares are issued against the total amount that the deposited capital can be given in service of the debt that Strategies assume. If that number were to be lower than the "expected value" at some future point, depositing shares via this method could entitle the depositor to less than the deposited value once the "realized value" is updated from further reports by the Strategies to the Vaults. Care should be taken by integrators to account for this discrepancy, by using the view-only methods of this contract (both off-chain and on-chain) to determine if depositing into the Vault is a "good idea".

#### Parameters:

NameTypeDescription* _amount ** ** The quantity of tokens to deposit, defaults to all. ** recipient ** ** The address to issue the shares in this Vault to. Defaults to the caller's address. *

#### Return Values:

Description* The issued Vault shares. *

### deposit

```
function deposit(uint256)
```

Measuring quantity of shares to issues is based on the total outstanding debt that this contract has ("expected value") instead of the total balance sheet it has ("estimated value") has important security considerations, and is done intentionally. If this value were measured against external systems, it could be purposely manipulated by an attacker to withdraw more assets than they otherwise should be able to claim by redeeming their shares. On deposit, this means that shares are issued against the total amount that the deposited capital can be given in service of the debt that Strategies assume. If that number were to be lower than the "expected value" at some future point, depositing shares via this method could entitle the depositor to less than the deposited value once the "realized value" is updated from further reports by the Strategies to the Vaults. Care should be taken by integrators to account for this discrepancy, by using the view-only methods of this contract (both off-chain and on-chain) to determine if depositing into the Vault is a "good idea".

#### Parameters:

NameTypeDescription* _amount ** ** The quantity of tokens to deposit, defaults to all. ** recipient ** ** The address to issue the shares in this Vault to. Defaults to the caller's address. *

#### Return Values:

Description* The issued Vault shares. *

### deposit

```
function deposit(uint256,address)
```

Measuring quantity of shares to issues is based on the total outstanding debt that this contract has ("expected value") instead of the total balance sheet it has ("estimated value") has important security considerations, and is done intentionally. If this value were measured against external systems, it could be purposely manipulated by an attacker to withdraw more assets than they otherwise should be able to claim by redeeming their shares. On deposit, this means that shares are issued against the total amount that the deposited capital can be given in service of the debt that Strategies assume. If that number were to be lower than the "expected value" at some future point, depositing shares via this method could entitle the depositor to less than the deposited value once the "realized value" is updated from further reports by the Strategies to the Vaults. Care should be taken by integrators to account for this discrepancy, by using the view-only methods of this contract (both off-chain and on-chain) to determine if depositing into the Vault is a "good idea".

#### Parameters:

NameTypeDescription* _amount ** ** The quantity of tokens to deposit, defaults to all. ** recipient ** ** The address to issue the shares in this Vault to. Defaults to the caller's address. *

#### Return Values:

Description* The issued Vault shares. *

### maxAvailableShares

```
function maxAvailableShares()
```

Determines the maximum quantity of shares this Vault can facilitate a withdrawal for, factoring in assets currently residing in the Vault, as well as those deployed to strategies on the Vault's balance sheet.

Regarding how shares are calculated, see dev note on `deposit`. If you want to calculated the maximum a user could withdraw up to, you want to use this function. Note that the amount provided by this function is the theoretical maximum possible from withdrawing, the real amount depends on the realized losses incurred during withdrawal.

#### Return Values:

Description* The total quantity of shares this Vault can provide. *

### withdraw

```
function withdraw()
```

Withdraws the calling account's tokens from this Vault, redeeming amount `_shares` for an appropriate amount of tokens. See note on `setWithdrawalQueue` for further details of withdrawal ordering and behavior.

Measuring the value of shares is based on the total outstanding debt that this contract has ("expected value") instead of the total balance sheet it has ("estimated value") has important security considerations, and is done intentionally. If this value were measured against external systems, it could be purposely manipulated by an attacker to withdraw more assets than they otherwise should be able to claim by redeeming their shares. On withdrawal, this means that shares are redeemed against the total amount that the deposited capital had "realized" since the point it was deposited, up until the point it was withdrawn. If that number were to be higher than the "expected value" at some future point, withdrawing shares via this method could entitle the depositor to more than the expected value once the "realized value" is updated from further reports by the Strategies to the Vaults. Under exceptional scenarios, this could cause earlier withdrawals to earn "more" of the underlying assets than Users might otherwise be entitled to, if the Vault's estimated value were otherwise measured through external means, accounting for whatever exceptional scenarios exist for the Vault (that aren't covered by the Vault's own design.) In the situation where a large withdrawal happens, it can empty the vault balance and the strategies in the withdrawal queue. Strategies not in the withdrawal queue will have to be harvested to rebalance the funds and make the funds available again to withdraw.

#### Parameters:

NameTypeDescription* maxShares ** ** How many shares to try and redeem for tokens, defaults to all. ** recipient ** ** The address to issue the shares in this Vault to. Defaults to the caller's address. ** maxLoss ** ** The maximum acceptable loss to sustain on withdrawal. Defaults to 0.01%. *

#### Return Values:

Description* The quantity of tokens redeemed for `_shares`. *

### withdraw

```
function withdraw(uint256)
```

Measuring the value of shares is based on the total outstanding debt that this contract has ("expected value") instead of the total balance sheet it has ("estimated value") has important security considerations, and is done intentionally. If this value were measured against external systems, it could be purposely manipulated by an attacker to withdraw more assets than they otherwise should be able to claim by redeeming their shares. On withdrawal, this means that shares are redeemed against the total amount that the deposited capital had "realized" since the point it was deposited, up until the point it was withdrawn. If that number were to be higher than the "expected value" at some future point, withdrawing shares via this method could entitle the depositor to more than the expected value once the "realized value" is updated from further reports by the Strategies to the Vaults. Under exceptional scenarios, this could cause earlier withdrawals to earn "more" of the underlying assets than Users might otherwise be entitled to, if the Vault's estimated value were otherwise measured through external means, accounting for whatever exceptional scenarios exist for the Vault (that aren't covered by the Vault's own design.) In the situation where a large withdrawal happens, it can empty the vault balance and the strategies in the withdrawal queue. Strategies not in the withdrawal queue will have to be harvested to rebalance the funds and make the funds available again to withdraw.

#### Parameters:

NameTypeDescription* maxShares ** ** How many shares to try and redeem for tokens, defaults to all. ** recipient ** ** The address to issue the shares in this Vault to. Defaults to the caller's address. ** maxLoss ** ** The maximum acceptable loss to sustain on withdrawal. Defaults to 0.01%. *

#### Return Values:

Description* The quantity of tokens redeemed for `_shares`. *

### withdraw

```
function withdraw(uint256,address)
```

Measuring the value of shares is based on the total outstanding debt that this contract has ("expected value") instead of the total balance sheet it has ("estimated value") has important security considerations, and is done intentionally. If this value were measured against external systems, it could be purposely manipulated by an attacker to withdraw more assets than they otherwise should be able to claim by redeeming their shares. On withdrawal, this means that shares are redeemed against the total amount that the deposited capital had "realized" since the point it was deposited, up until the point it was withdrawn. If that number were to be higher than the "expected value" at some future point, withdrawing shares via this method could entitle the depositor to more than the expected value once the "realized value" is updated from further reports by the Strategies to the Vaults. Under exceptional scenarios, this could cause earlier withdrawals to earn "more" of the underlying assets than Users might otherwise be entitled to, if the Vault's estimated value were otherwise measured through external means, accounting for whatever exceptional scenarios exist for the Vault (that aren't covered by the Vault's own design.) In the situation where a large withdrawal happens, it can empty the vault balance and the strategies in the withdrawal queue. Strategies not in the withdrawal queue will have to be harvested to rebalance the funds and make the funds available again to withdraw.

#### Parameters:

NameTypeDescription* maxShares ** ** How many shares to try and redeem for tokens, defaults to all. ** recipient ** ** The address to issue the shares in this Vault to. Defaults to the caller's address. ** maxLoss ** ** The maximum acceptable loss to sustain on withdrawal. Defaults to 0.01%. *

#### Return Values:

Description* The quantity of tokens redeemed for `_shares`. *

### withdraw

```
function withdraw(uint256,address,uint256)
```

Measuring the value of shares is based on the total outstanding debt that this contract has ("expected value") instead of the total balance sheet it has ("estimated value") has important security considerations, and is done intentionally. If this value were measured against external systems, it could be purposely manipulated by an attacker to withdraw more assets than they otherwise should be able to claim by redeeming their shares. On withdrawal, this means that shares are redeemed against the total amount that the deposited capital had "realized" since the point it was deposited, up until the point it was withdrawn. If that number were to be higher than the "expected value" at some future point, withdrawing shares via this method could entitle the depositor to more than the expected value once the "realized value" is updated from further reports by the Strategies to the Vaults. Under exceptional scenarios, this could cause earlier withdrawals to earn "more" of the underlying assets than Users might otherwise be entitled to, if the Vault's estimated value were otherwise measured through external means, accounting for whatever exceptional scenarios exist for the Vault (that aren't covered by the Vault's own design.) In the situation where a large withdrawal happens, it can empty the vault balance and the strategies in the withdrawal queue. Strategies not in the withdrawal queue will have to be harvested to rebalance the funds and make the funds available again to withdraw.

#### Parameters:

NameTypeDescription* maxShares ** ** How many shares to try and redeem for tokens, defaults to all. ** recipient ** ** The address to issue the shares in this Vault to. Defaults to the caller's address. ** maxLoss ** ** The maximum acceptable loss to sustain on withdrawal. Defaults to 0.01%. *

#### Return Values:

Description* The quantity of tokens redeemed for `_shares`. *

### pricePerShare

```
function pricePerShare()
```

Gives the price for a single Vault share.

See dev note on `withdraw`.

#### Return Values:

Description* The value of a single share. *

### addStrategy

```
function addStrategy(address,uint256,uint256,uint256,uint256)
```

Add a Strategy to the Vault. This may only be called by governance.

The Strategy will be appended to `withdrawalQueue`, call `setWithdrawalQueue` to change the order.

#### Parameters:

NameTypeDescription* strategy ** ** The address of the Strategy to add. ** debtRatio ** ** The share of the total assets in the `vault that the`strategy` has access to. ** minDebtPerHarvest ** ** Lower limit on the increase of debt since last harvest ** maxDebtPerHarvest ** ** Upper limit on the increase of debt since last harvest ** performanceFee ** ** The fee the strategist will receive based on this Vault's performance. *

### updateStrategyDebtRatio

```
function updateStrategyDebtRatio(address,uint256)
```

Change the quantity of assets `strategy` may manage. This may be called by governance or management.

#### Parameters:

NameTypeDescription* strategy ** ** The Strategy to update. ** debtRatio ** ** The quantity of assets `strategy` may now manage. *

### updateStrategyMinDebtPerHarvest

```
function updateStrategyMinDebtPerHarvest(address,uint256)
```

Change the quantity assets per block this Vault may deposit to or withdraw from `strategy`. This may only be called by governance or management.

#### Parameters:

NameTypeDescription* strategy ** ** The Strategy to update. ** minDebtPerHarvest ** ** Lower limit on the increase of debt since last harvest *

### updateStrategyMaxDebtPerHarvest

```
function updateStrategyMaxDebtPerHarvest(address,uint256)
```

Change the quantity assets per block this Vault may deposit to or withdraw from `strategy`. This may only be called by governance or management.

#### Parameters:

NameTypeDescription* strategy ** ** The Strategy to update. ** maxDebtPerHarvest ** ** Upper limit on the increase of debt since last harvest *

### updateStrategyPerformanceFee

```
function updateStrategyPerformanceFee(address,uint256)
```

Change the fee the strategist will receive based on this Vault's performance. This may only be called by governance.

#### Parameters:

NameTypeDescription* strategy ** ** The Strategy to update. ** performanceFee ** ** The new fee the strategist will receive. *

### migrateStrategy

```
function migrateStrategy(address,address)
```

Migrates a Strategy, including all assets from `oldVersion` to `newVersion`. This may only be called by governance.

Strategy must successfully migrate all capital and positions to new Strategy, or else this will upset the balance of the Vault. The new Strategy should be "empty" e.g. have no prior commitments to this Vault, otherwise it could have issues.

#### Parameters:

NameTypeDescription* oldVersion ** ** The existing Strategy to migrate from. ** newVersion ** ** The new Strategy to migrate to. *

### revokeStrategy

```
function revokeStrategy()
```

Revoke a Strategy, setting its debt limit to 0 and preventing any future deposits. This function should only be used in the scenario where the Strategy is being retired but no migration of the positions are possible, or in the extreme scenario that the Strategy needs to be put into "Emergency Exit" mode in order for it to exit as quickly as possible. The latter scenario could be for any reason that is considered "critical" that the Strategy exits its position as fast as possible, such as a sudden change in market conditions leading to losses, or an imminent failure in an external dependency. This may only be called by governance, the guardian, or the Strategy itself. Note that a Strategy will only revoke itself during emergency shutdown.

#### Parameters:

NameTypeDescription* strategy ** ** The Strategy to revoke. *

### revokeStrategy

```
function revokeStrategy(address)
```

#### Parameters:

NameTypeDescription* strategy ** ** The Strategy to revoke. *

### addStrategyToQueue

```
function addStrategyToQueue(address)
```

Adds `strategy` to `withdrawalQueue`. This may only be called by governance or management.

The Strategy will be appended to `withdrawalQueue`, call `setWithdrawalQueue` to change the order.

#### Parameters:

NameTypeDescription* strategy ** ** The Strategy to add. *

### removeStrategyFromQueue

```
function removeStrategyFromQueue(address)
```

Remove `strategy` from `withdrawalQueue`. This may only be called by governance or management.

We don't do this with revokeStrategy because it should still be possible to withdraw from the Strategy if it's unwinding.

#### Parameters:

NameTypeDescription* strategy ** ** The Strategy to remove. *

### debtOutstanding

```
function debtOutstanding()
```

Determines if `strategy` is past its debt limit and if any tokens should be withdrawn to the Vault.

#### Parameters:

NameTypeDescription* strategy ** ** The Strategy to check. Defaults to the caller. *

#### Return Values:

Description* The quantity of tokens to withdraw. *

### debtOutstanding

```
function debtOutstanding(address)
```

#### Parameters:

NameTypeDescription* strategy ** ** The Strategy to check. Defaults to the caller. *

#### Return Values:

Description* The quantity of tokens to withdraw. *

### creditAvailable

```
function creditAvailable()
```

Amount of tokens in Vault a Strategy has access to as a credit line. This will check the Strategy's debt limit, as well as the tokens available in the Vault, and determine the maximum amount of tokens (if any) the Strategy may draw on. In the rare case the Vault is in emergency shutdown this will return 0.

#### Parameters:

NameTypeDescription* strategy ** ** The Strategy to check. Defaults to caller. *

#### Return Values:

Description* The quantity of tokens available for the Strategy to draw on. *

### creditAvailable

```
function creditAvailable(address)
```

#### Parameters:

NameTypeDescription* strategy ** ** The Strategy to check. Defaults to caller. *

#### Return Values:

Description* The quantity of tokens available for the Strategy to draw on. *

### expectedReturn

```
function expectedReturn()
```

Provide an accurate expected value for the return this `strategy` would provide to the Vault the next time `report()` is called (since the last time it was called).

#### Parameters:

NameTypeDescription* strategy ** ** The Strategy to determine the expected return for. Defaults to caller. *

#### Return Values:

Description* The anticipated amount `strategy` should make on its investment since its last report. *

### expectedReturn

```
function expectedReturn(address)
```

#### Parameters:

NameTypeDescription* strategy ** ** The Strategy to determine the expected return for. Defaults to caller. *

#### Return Values:

Description* The anticipated amount `strategy` should make on its investment since its last report. *

### report

```
function report(uint256,uint256,uint256)
```

Reports the amount of assets the calling Strategy has free (usually in terms of ROI). The performance fee is determined here, off of the strategy's profits (if any), and sent to governance. The strategist's fee is also determined here (off of profits), to be handled according to the strategist on the next harvest. This may only be called by a Strategy managed by this Vault.

For approved strategies, this is the most efficient behavior. The Strategy reports back what it has free, then Vault "decides" whether to take some back or give it more. Note that the most it can take is `gain + _debtPayment`, and the most it can give is all of the remaining reserves. Anything outside of those bounds is abnormal behavior. All approved strategies must have increased diligence around calling this function, as abnormal behavior could become catastrophic.

#### Parameters:

NameTypeDescription* gain ** ** Amount Strategy has realized as a gain on it's investment since its last report, and is free to be given back to Vault as earnings ** loss ** ** Amount Strategy has realized as a loss on it's investment since its last report, and should be accounted for on the Vault's balance sheet. The loss will reduce the debtRatio. The next time the strategy will harvest, it will pay back the debt in an attempt to adjust to the new debt limit. ** _debtPayment ** ** Amount Strategy has made available to cover outstanding debt *

#### Return Values:

Description* Amount of debt outstanding (if totalDebt > debtLimit or emergency shutdown). *

### sweep

```
function sweep(address)
```

Removes tokens from this Vault that are not the type of token managed by this Vault. This may be used in case of accidentally sending the wrong kind of token to this Vault. Tokens will be sent to `governance`. This will fail if an attempt is made to sweep the tokens that this Vault manages. This may only be called by governance.

#### Parameters:

NameTypeDescription* token ** ** The token to transfer out of this vault. ** amount ** ** The quantity or tokenId to transfer out. *

### sweep

```
function sweep(address,uint256)
```

#### Parameters:

NameTypeDescription* token ** ** The token to transfer out of this vault. ** amount ** ** The quantity or tokenId to transfer out. *

## Events

Transfer

- `sender` : address, indexed

- `receiver` : address, indexed

- `value` : uint256, notIndexed

Approval

- `owner` : address, indexed

- `spender` : address, indexed

- `value` : uint256, notIndexed

StrategyAdded

- `strategy` : address, indexed

- `debtRatio` : uint256, notIndexed

- `minDebtPerHarvest` : uint256, notIndexed

- `maxDebtPerHarvest` : uint256, notIndexed

- `performanceFee` : uint256, notIndexed

StrategyReported

- `strategy` : address, indexed

- `gain` : uint256, notIndexed

- `loss` : uint256, notIndexed

- `debtPaid` : uint256, notIndexed

- `totalGain` : uint256, notIndexed

- `totalLoss` : uint256, notIndexed

- `totalDebt` : uint256, notIndexed

- `debtAdded` : uint256, notIndexed

- `debtRatio` : uint256, notIndexed

UpdateGovernance

- `governance` : address, notIndexed

UpdateManagement

- `management` : address, notIndexed

UpdateRewards

- `rewards` : address, notIndexed

UpdateDepositLimit

- `depositLimit` : uint256, notIndexed

UpdatePerformanceFee

- `performanceFee` : uint256, notIndexed

UpdateManagementFee

- `managementFee` : uint256, notIndexed

UpdateGuardian

- `guardian` : address, notIndexed

EmergencyShutdown

- `active` : bool, notIndexed

UpdateWithdrawalQueue

- `queue` : address[20], notIndexed

StrategyUpdateDebtRatio

- `strategy` : address, indexed

- `debtRatio` : uint256, notIndexed

StrategyUpdateMinDebtPerHarvest

- `strategy` : address, indexed

- `minDebtPerHarvest` : uint256, notIndexed

StrategyUpdateMaxDebtPerHarvest

- `strategy` : address, indexed

- `maxDebtPerHarvest` : uint256, notIndexed

StrategyUpdatePerformanceFee

- `strategy` : address, indexed

- `performanceFee` : uint256, notIndexed

StrategyMigrated

- `oldVersion` : address, indexed

- `newVersion` : address, indexed

StrategyRevoked

- `strategy` : address, indexed

StrategyRemovedFromQueue

- `strategy` : address, indexed

StrategyAddedToQueue

- `strategy` : address, indexed


StrategyAPI

StrategyAPI

Functions

name

vault

want

apiVersion

keeper

isActive

delegatedAssets

estimatedTotalAssets

tendTrigger

tend

harvestTrigger

harvest

Events

Harvested

# StrategyAPI

This interface is here for the keeper bot to use.

## Functions

### name

```
function name( ) external returns (string)
```

### vault

```
function vault( ) external returns (address)
```

### want

```
function want( ) external returns (address)
```

### apiVersion

```
function apiVersion( ) external returns (string)
```

### keeper

```
function keeper( ) external returns (address)
```

### isActive

```
function isActive( ) external returns (bool)
```

### delegatedAssets

```
function delegatedAssets( ) external returns (uint256)
```

### estimatedTotalAssets

```
function estimatedTotalAssets( ) external returns (uint256)
```

### tendTrigger

```
function tendTrigger( ) external returns (bool)
```

### tend

```
function tend( ) external
```

### harvestTrigger

```
function harvestTrigger( ) external returns (bool)
```

### harvest

```
function harvest( ) external
```

## Events

### Harvested

```
event Harvested( )
```


RegistryAPI

RegistryAPI

Functions

governance

latestVault

numVaults

vaults

# RegistryAPI

## Functions

### governance

```
function governance( ) external returns (address)
```

### latestVault

```
function latestVault( ) external returns (address)
```

### numVaults

```
function numVaults( ) external returns (uint256)
```

### vaults

```
function vaults( ) external returns (address)
```


Registry.vy

Registry.vy

Functions

setGovernance

Parameters:

acceptGovernance

latestRelease

Return Values:

latestVault

Parameters:

Return Values:

newRelease

Parameters:

newVault

Parameters:

Return Values:

newVault

Parameters:

Return Values:

newExperimentalVault

Parameters:

Return Values:

newExperimentalVault

Parameters:

Return Values:

endorseVault

Parameters:

endorseVault

Parameters:

setBanksy

Parameters:

setBanksy

Parameters:

tagVault

Parameters:

Events

# Registry.vy

## Functions

### setGovernance

```
function setGovernance(address)
```

Starts the 1st phase of the governance transfer.

Throws if the caller is not current governance.

#### Parameters:

NameTypeDescription* governance ** ** The next governance address *

### acceptGovernance

```
function acceptGovernance()
```

Completes the 2nd phase of the governance transfer.

Throws if the caller is not the pending caller. Emits a `NewGovernance` event.

### latestRelease

```
function latestRelease()
```

Returns the api version of the latest release.

Throws if no releases are registered yet.

#### Return Values:

Description* The api version of the latest release. *

### latestVault

```
function latestVault(address)
```

Returns the latest deployed vault for the given token.

Throws if no vaults are endorsed yet for the given token.

#### Parameters:

NameTypeDescription* token ** ** The token address to find the latest vault for. *

#### Return Values:

Description* The address of the latest vault for the given token. *

### newRelease

```
function newRelease(address)
```

Add a previously deployed Vault as the template contract for the latest release, to be used by further "forwarder-style" delegatecall proxy contracts that can be deployed from the registry throw other methods (to save gas).

Throws if caller isn't `self.governance`. Throws if `vault`'s governance isn't `self.governance`. Throws if the api version is the same as the previous release. Emits a `NewVault` event.

#### Parameters:

NameTypeDescription* vault ** ** The vault that will be used as the template contract for the next release. *

### newVault

```
function newVault(address,address,address,string,string)
```

Create a new vault for the given token using the latest release in the registry, as a simple "forwarder-style" delegatecall proxy to the latest release. Also adds the new vault to the list of "endorsed" vaults for that token.

`governance` is set in the new vault as `self.governance`, with no ability to override. Throws if caller isn't `self.governance`. Throws if no releases are registered yet. Throws if there already is a registered vault for the given token with the latest api version. Emits a `NewVault` event.

#### Parameters:

NameTypeDescription* token ** ** The token that may be deposited into the new Vault. ** guardian ** ** The address authorized for guardian interactions in the new Vault. ** rewards ** ** The address to use for collecting rewards in the new Vault ** name ** ** Specify a custom Vault name. Set to empty string for default choice. ** symbol ** ** Specify a custom Vault symbol name. Set to empty string for default choice. ** releaseDelta ** ** Specify the number of releases prior to the latest to use as a target. Default is latest. *

#### Return Values:

Description* The address of the newly-deployed vault *

### newVault

```
function newVault(address,address,address,string,string,uint256)
```

`governance` is set in the new vault as `self.governance`, with no ability to override. Throws if caller isn't `self.governance`. Throws if no releases are registered yet. Throws if there already is a registered vault for the given token with the latest api version. Emits a `NewVault` event.

#### Parameters:

NameTypeDescription* token ** ** The token that may be deposited into the new Vault. ** guardian ** ** The address authorized for guardian interactions in the new Vault. ** rewards ** ** The address to use for collecting rewards in the new Vault ** name ** ** Specify a custom Vault name. Set to empty string for default choice. ** symbol ** ** Specify a custom Vault symbol name. Set to empty string for default choice. ** releaseDelta ** ** Specify the number of releases prior to the latest to use as a target. Default is latest. *

#### Return Values:

Description* The address of the newly-deployed vault *

### newExperimentalVault

```
function newExperimentalVault(address,address,address,address,string,string)
```

Create a new vault for the given token using the latest release in the registry, as a simple "forwarder-style" delegatecall proxy to the latest release. Does not add the new vault to the list of "endorsed" vaults for that token.

Throws if no releases are registered yet. Emits a `NewExperimentalVault` event.

#### Parameters:

NameTypeDescription* token ** ** The token that may be deposited into the new Vault. ** governance ** ** The address authorized for governance interactions in the new Vault. ** guardian ** ** The address authorized for guardian interactions in the new Vault. ** rewards ** ** The address to use for collecting rewards in the new Vault ** name ** ** Specify a custom Vault name. Set to empty string for default choice. ** symbol ** ** Specify a custom Vault symbol name. Set to empty string for default choice. ** releaseDelta ** ** Specify the number of releases prior to the latest to use as a target. Default is latest. *

#### Return Values:

Description* The address of the newly-deployed vault *

### newExperimentalVault

```
function newExperimentalVault(address,address,address,address,string,string,uint256)
```

Throws if no releases are registered yet. Emits a `NewExperimentalVault` event.

#### Parameters:

NameTypeDescription* token ** ** The token that may be deposited into the new Vault. ** governance ** ** The address authorized for governance interactions in the new Vault. ** guardian ** ** The address authorized for guardian interactions in the new Vault. ** rewards ** ** The address to use for collecting rewards in the new Vault ** name ** ** Specify a custom Vault name. Set to empty string for default choice. ** symbol ** ** Specify a custom Vault symbol name. Set to empty string for default choice. ** releaseDelta ** ** Specify the number of releases prior to the latest to use as a target. Default is latest. *

#### Return Values:

Description* The address of the newly-deployed vault *

### endorseVault

```
function endorseVault(address)
```

Adds an existing vault to the list of "endorsed" vaults for that token.

`governance` is set in the new vault as `self.governance`, with no ability to override. Throws if caller isn't `self.governance`. Throws if `vault`'s governance isn't `self.governance`. Throws if no releases are registered yet. Throws if `vault`'s api version does not match latest release. Throws if there already is a deployment for the vault's token with the latest api version. Emits a `NewVault` event.

#### Parameters:

NameTypeDescription* vault ** ** The vault that will be endorsed by the Registry. ** releaseDelta ** ** Specify the number of releases prior to the latest to use as a target. Default is latest. *

### endorseVault

```
function endorseVault(address,uint256)
```

`governance` is set in the new vault as `self.governance`, with no ability to override. Throws if caller isn't `self.governance`. Throws if `vault`'s governance isn't `self.governance`. Throws if no releases are registered yet. Throws if `vault`'s api version does not match latest release. Throws if there already is a deployment for the vault's token with the latest api version. Emits a `NewVault` event.

#### Parameters:

NameTypeDescription* vault ** ** The vault that will be endorsed by the Registry. ** releaseDelta ** ** Specify the number of releases prior to the latest to use as a target. Default is latest. *

### setBanksy

```
function setBanksy(address)
```

Set the ability of a particular tagger to tag current vaults.

Throws if caller is not `self.governance`.

#### Parameters:

NameTypeDescription* tagger ** ** The address to approve or deny access to tagging. ** allowed ** ** Whether to approve or deny `tagger`. Defaults to approve. *

### setBanksy

```
function setBanksy(address,bool)
```

Throws if caller is not `self.governance`.

#### Parameters:

NameTypeDescription* tagger ** ** The address to approve or deny access to tagging. ** allowed ** ** Whether to approve or deny `tagger`. Defaults to approve. *

### tagVault

```
function tagVault(address,string)
```

Tag a Vault with a message.

Throws if caller is not `self.governance` or an approved tagger. Emits a `VaultTagged` event.

#### Parameters:

NameTypeDescription* vault ** ** The address to tag with the given `tag` message. ** tag ** ** The message to tag `vault` with. *

## Events

NewRelease

- `release_id` : uint256, indexed

- `template` : address, notIndexed

- `api_version` : string, notIndexed

NewVault

- `token` : address, indexed

- `vault_id` : uint256, indexed

- `vault` : address, notIndexed

- `api_version` : string, notIndexed

NewExperimentalVault

- `token` : address, indexed

- `deployer` : address, indexed

- `vault` : address, notIndexed

- `api_version` : string, notIndexed

NewGovernance

- `governance` : address, notIndexed

VaultTagged

- `vault` : address, notIndexed

- `tag` : string, notIndexed


IWETH

IWETH

Functions

deposit

withdraw

# IWETH

## Functions

### deposit

```
function deposit( ) external
```

### withdraw

```
function withdraw( ) external
```


IERC20Metadata

Functions

name

symbol

decimals

# IERC20Metadata

## Functions

### name

```
function name( ) external returns (string)
```

Returns the name of the token.

### symbol

```
function symbol( ) external returns (string)
```

Returns the symbol of the token.

### decimals

```
function decimals( ) external returns (uint8)
```

Returns the decimals places of the token.


BaseWrapper

BaseWrapper

Functions

constructor

setRegistry

Parameters:

bestVault

Return Values:

allVaults

Return Values:

totalVaultBalance

totalAssets

# BaseWrapper

## Functions

### constructor

```
function constructor( ) public
```

### setRegistry

```
function setRegistry( address _registry ) external
```

Used to update the yearn registry.

#### Parameters:

NameTypeDescription`_registry`addressThe new _registry address.

### bestVault

```
function bestVault( ) public returns (contract VaultAPI)
```

Used to get the most revent vault for the token using the registry.

#### Return Values:

NameTypeDescription`An`instance of a VaultAPI

### allVaults

```
function allVaults( ) public returns (contract VaultAPI[])
```

Used to get all vaults from the registery for the token

#### Return Values:

NameTypeDescription`An`array containing instances of VaultAPI

### _updateVaultCache

```
function _updateVaultCache( ) internal
```

### totalVaultBalance

```
function totalVaultBalance( ) public returns (uint256 balance)
```

Used to get the balance of an account accross all the vaults for a token.
@dev will be used to get the wrapper balance using totalVaultBalance(address(this)).
@param account The address of the account.
@return balance of token for the account accross all the vaults.

### totalAssets

```
function totalAssets( ) public returns (uint256 assets)
```

Used to get the TVL on the underlying vaults.
@return assets the sum of all the assets managed by the underlying vaults.

### _deposit

```
function _deposit( ) internal returns (uint256 deposited)
```

### _withdraw

```
function _withdraw( ) internal returns (uint256 withdrawn)
```

### _migrate

```
function _migrate( ) internal returns (uint256)
```

### _migrate

```
function _migrate( ) internal returns (uint256)
```

### _migrate

```
function _migrate( ) internal returns (uint256 migrated)
```


BaseStrategyInitializable

BaseStrategyInitializable

Functions

constructor

initialize

clone

clone

Events

Cloned

# BaseStrategyInitializable

## Functions

### constructor

```
function constructor( ) public
```

### initialize

```
function initialize( ) external
```

### clone

```
function clone( ) external returns (address)
```

### clone

```
function clone( ) external returns (address newStrategy)
```

## Events

### Cloned

```
event Cloned( )
```


BaseStrategy

BaseStrategy

Functions

apiVersion

Return Values:

name

Return Values:

delegatedAssets

constructor

Parameters:

setStrategist

Parameters:

setKeeper

Parameters:

setRewards

Parameters:

setMinReportDelay

Parameters:

setMaxReportDelay

Parameters:

setProfitFactor

Parameters:

setDebtThreshold

Parameters:

setMetadataURI

Parameters:

governance

ethToWant

Parameters:

Return Values:

estimatedTotalAssets

Return Values:

isActive

prepareReturn

adjustPosition

liquidatePosition

liquidateAllPositions

tendTrigger

Parameters:

Return Values:

tend

harvestTrigger

Parameters:

Return Values:

harvest

withdraw

Parameters:

Return Values:

prepareMigration

migrate

Parameters:

setEmergencyExit

protectedTokens

sweep

Parameters:

Events

Harvested

UpdatedStrategist

UpdatedKeeper

UpdatedRewards

UpdatedMinReportDelay

UpdatedMaxReportDelay

UpdatedProfitFactor

UpdatedDebtThreshold

EmergencyExitEnabled

UpdatedMetadataURI

# BaseStrategy

## Functions

### apiVersion

```
function apiVersion( ) public returns (string)
```

Used to track which version of `StrategyAPI` this Strategy
implements.

The Strategy's version must match the Vault's `API_VERSION`.

#### Return Values:

NameTypeDescription`A`string which holds the current API version of this contract.

### name

```
function name( ) external returns (string)
```

This Strategy's name.
@dev
You can use this field to manage the "version" of this Strategy, e.g.
`StrategySomethingOrOtherV1`. However, "API Version" is managed by
`apiVersion()` function above.

#### Return Values:

NameTypeDescription`This`Strategy's name.

### delegatedAssets

```
function delegatedAssets( ) external returns (uint256)
```

The amount (priced in want) of the total assets managed by this strategy should not count
towards Yearn's TVL calculations.
@dev
You can override this field to set it to a non-zero value if some of the assets of this
Strategy is somehow delegated inside another part of Yearn's ecosystem e.g. another Vault.
Note that this value must be strictly less than or equal to the amount provided by
`estimatedTotalAssets()` below, as the TVL calc will be total assets minus delegated assets.
Also note that this value is used to determine the total assets under management by this
strategy, for the purposes of computing the management fee in `Vault`
@return
The amount of assets this strategy manages that should not be included in Yearn's Total Value
Locked (TVL) calculation across it's ecosystem.

### constructor

```
function constructor( ) public
```

### _initialize

```
function _initialize( address _vault, address _strategist, address _rewards, address _keeper ) internal
```

Initializes the Strategy, this is called only once, when the
contract is deployed.

`_vault` should implement `VaultAPI`.

#### Parameters:

NameTypeDescription`_vault`addressThe address of the Vault responsible for this Strategy.`_strategist`addressThe address to assign as `strategist`.The strategist is able to change the reward address`_rewards`addressThe address to use for pulling rewards.`_keeper`addressThe address of the _keeper. _keepercan harvest and tend a strategy.

### setStrategist

```
function setStrategist( address _strategist ) external
```

Used to change `strategist`.

This may only be called by governance or the existing strategist.

#### Parameters:

NameTypeDescription`_strategist`addressThe new address to assign as `strategist`.

### setKeeper

```
function setKeeper( address _keeper ) external
```

Used to change `keeper`.

`keeper` is the only address that may call `tend()` or `harvest()`,
other than `governance()` or `strategist`. However, unlike
`governance()` or `strategist`, `keeper` may only call `tend()`
and `harvest()`, and no other authorized functions, following the
principle of least privilege.

This may only be called by governance or the strategist.

#### Parameters:

NameTypeDescription`_keeper`addressThe new address to assign as `keeper`.

### setRewards

```
function setRewards( address _rewards ) external
```

Used to change `rewards`. EOA or smart contract which has the permission
to pull rewards from the vault.

This may only be called by the strategist.

#### Parameters:

NameTypeDescription`_rewards`addressThe address to use for pulling rewards.

### setMinReportDelay

```
function setMinReportDelay( uint256 _delay ) external
```

Used to change `minReportDelay`. `minReportDelay` is the minimum number
of blocks that should pass for `harvest()` to be called.

For external keepers (such as the Keep3r network), this is the minimum
time between jobs to wait. (see `harvestTrigger()`
for more details.)

This may only be called by governance or the strategist.

#### Parameters:

NameTypeDescription`_delay`uint256The minimum number of seconds to wait between harvests.

### setMaxReportDelay

```
function setMaxReportDelay( uint256 _delay ) external
```

Used to change `maxReportDelay`. `maxReportDelay` is the maximum number
of blocks that should pass for `harvest()` to be called.

For external keepers (such as the Keep3r network), this is the maximum
time between jobs to wait. (see `harvestTrigger()`
for more details.)

This may only be called by governance or the strategist.

#### Parameters:

NameTypeDescription`_delay`uint256The maximum number of seconds to wait between harvests.

### setProfitFactor

```
function setProfitFactor( uint256 _profitFactor ) external
```

Used to change `profitFactor`. `profitFactor` is used to determine
if it's worthwhile to harvest, given gas costs. (See `harvestTrigger()`
for more details.)

This may only be called by governance or the strategist.

#### Parameters:

NameTypeDescription`_profitFactor`uint256A ratio to multiply anticipated`harvest()` gas cost against.

### setDebtThreshold

```
function setDebtThreshold( uint256 _debtThreshold ) external
```

Sets how far the Strategy can go into loss without a harvest and report
being required.

By default this is 0, meaning any losses would cause a harvest which
will subsequently report the loss to the Vault for tracking. (See
`harvestTrigger()` for more details.)

This may only be called by governance or the strategist.

#### Parameters:

NameTypeDescription`_debtThreshold`uint256How big of a loss this Strategy may carry withoutbeing required to report to the Vault.

### setMetadataURI

```
function setMetadataURI( string _metadataURI ) external
```

Used to change `metadataURI`. `metadataURI` is used to store the URI
of the file describing the strategy.

This may only be called by governance or the strategist.

#### Parameters:

NameTypeDescription`_metadataURI`stringThe URI that describe the strategy.

### governance

```
function governance( ) internal returns (address)
```

Resolve governance address from Vault contract, used to make assertions
on protected functions in the Strategy.

### ethToWant

```
function ethToWant( uint256 _amtInWei ) public returns (uint256)
```

Provide an accurate conversion from `_amtInWei` (denominated in wei)
to `want` (using the native decimal characteristics of `want`).
@dev
Care must be taken when working with decimals to assure that the conversion
is compatible. As an example:

given 1e17 wei (0.1 ETH) as input, and want is USDC (6 decimals),
with USDC/ETH = 1800, this should give back 1800000000 (180 USDC)

#### Parameters:

NameTypeDescription`_amtInWei`uint256The amount (in wei/1e-18 ETH) to convert to `want`

#### Return Values:

NameTypeDescription`The`uint256amount in `want` of `_amtInEth` converted to `want`

### estimatedTotalAssets

```
function estimatedTotalAssets( ) public returns (uint256)
```

Provide an accurate estimate for the total amount of assets
(principle + return) that this Strategy is currently managing,
denominated in terms of `want` tokens.

This total should be "realizable" e.g. the total value that could
actually be obtained from this Strategy if it were to divest its
entire position based on current on-chain conditions.
@dev
Care must be taken in using this function, since it relies on external
systems, which could be manipulated by the attacker to give an inflated
(or reduced) value produced by this function, based on current on-chain
conditions (e.g. this function is possible to influence through
flashloan attacks, oracle manipulations, or other DeFi attack
mechanisms).

It is up to governance to use this function to correctly order this
Strategy relative to its peers in the withdrawal queue to minimize
losses for the Vault based on sudden withdrawals. This value should be
higher than the total debt of the Strategy and higher than its expected
value to be "safe".

#### Return Values:

NameTypeDescription`The`estimated total assets in this Strategy.

### isActive

```
function isActive( ) public returns (bool)
```

### prepareReturn

```
function prepareReturn( ) internal returns (uint256 _profit, uint256 _loss, uint256 _debtPayment)
```

Perform any Strategy unwinding or other calls necessary to capture the
"free return" this Strategy has generated since the last time its core
position(s) were adjusted. Examples include unwrapping extra rewards.
This call is only used during "normal operation" of a Strategy, and
should be optimized to minimize losses as much as possible.

This method returns any realized profits and/or realized losses
incurred, and should return the total amounts of profits/losses/debt
payments (in `want` tokens) for the Vault's accounting (e.g.
`want.balanceOf(this) >= _debtPayment + _profit`).

`_debtOutstanding` will be 0 if the Strategy is not past the configured
debt limit, otherwise its value will be how far past the debt limit
the Strategy is. The Strategy's debt limit is configured in the Vault.

NOTE: `_debtPayment` should be less than or equal to `_debtOutstanding`.
It is okay for it to be less than `_debtOutstanding`, as that
should only used as a guide for how much is left to pay back.
Payments should be made to minimize loss from slippage, debt,
withdrawal fees, etc.

See `vault.debtOutstanding()`.

### adjustPosition

```
function adjustPosition( ) internal
```

Perform any adjustments to the core position(s) of this Strategy given
what change the Vault made in the "investable capital" available to the
Strategy. Note that all "free capital" in the Strategy after the report
was made is available for reinvestment. Also note that this number
could be 0, and you should handle that scenario accordingly.

See comments regarding `_debtOutstanding` on `prepareReturn()`.

### liquidatePosition

```
function liquidatePosition( ) internal returns (uint256 _liquidatedAmount, uint256 _loss)
```

Liquidate up to `_amountNeeded` of `want` of this strategy's positions,
irregardless of slippage. Any excess will be re-invested with `adjustPosition()`.
This function should return the amount of `want` tokens made available by the
liquidation. If there is a difference between them, `_loss` indicates whether the
difference is due to a realized loss, or if there is some other sitution at play
(e.g. locked funds) where the amount made available is less than what is needed.

NOTE: The invariant `_liquidatedAmount + _loss NameTypeDescription`callCostInWei`uint256The keeper's estimated gas cost to call `tend()` (in wei).

#### Return Values:

NameTypeDescription`if`uint256`tend()` should be called, `false` otherwise.

### tend

```
function tend( ) external
```

Adjust the Strategy's position. The purpose of tending isn't to
realize gains, but to maximize yield by reinvesting any returns.

See comments on `adjustPosition()`.

This may only be called by governance, the strategist, or the keeper.

### harvestTrigger

```
function harvestTrigger( uint256 callCostInWei ) public returns (bool)
```

Provide a signal to the keeper that `harvest()` should be called. The
keeper will provide the estimated gas cost that they would pay to call
`harvest()`, and this function should use that estimate to make a
determination if calling it is "worth it" for the keeper. This is not
the only consideration into issuing this trigger, for example if the
position would be negatively affected if `harvest()` is not called
shortly, then this can return `true` even if the keeper might be "at a
loss" (keepers are always reimbursed by Yearn).
@dev
`callCostInWei` must be priced in terms of `wei` (1e-18 ETH).

This call and `tendTrigger` should never return `true` at the
same time.

See `min/maxReportDelay`, `profitFactor`, `debtThreshold` to adjust the
strategist-controlled parameters that will influence whether this call
returns `true` or not. These parameters will be used in conjunction
with the parameters reported to the Vault (see `params`) to determine
if calling `harvest()` is merited.

It is expected that an external system will check `harvestTrigger()`.
This could be a script run off a desktop or cloud bot (e.g.
https://github.com/iearn-finance/yearn-vaults/blob/master/scripts/keep.py),
or via an integration with the Keep3r network (e.g.
https://github.com/Macarse/GenericKeep3rV2/blob/master/contracts/keep3r/GenericKeep3rV2.sol).

#### Parameters:

NameTypeDescription`callCostInWei`uint256The keeper's estimated gas cost to call `harvest()` (in wei).

#### Return Values:

NameTypeDescription`if`uint256`harvest()` should be called, `false` otherwise.

### harvest

```
function harvest( ) external
```

Harvests the Strategy, recognizing any profits or losses and adjusting
the Strategy's position.

In the rare case the Strategy is in emergency shutdown, this will exit
the Strategy's position.

This may only be called by governance, the strategist, or the keeper.
@dev
When `harvest()` is called, the Strategy reports to the Vault (via
`vault.report()`), so in some cases `harvest()` must be called in order
to take in profits, to borrow newly available funds from the Vault, or
otherwise adjust its position. In other cases `harvest()` must be
called to report to the Vault on the Strategy's position, especially if
any losses have occurred.

### withdraw

```
function withdraw( uint256 _amountNeeded ) external returns (uint256 _loss)
```

Withdraws `_amountNeeded` to `vault`.

This may only be called by the Vault.

#### Parameters:

NameTypeDescription`_amountNeeded`uint256How much `want` to withdraw.

#### Return Values:

NameTypeDescription`_loss`uint256Any realized losses

### prepareMigration

```
function prepareMigration( ) internal
```

Do anything necessary to prepare this Strategy for migration, such as
transferring any reserve or LP tokens, CDPs, or other tokens or stores of
value.

### migrate

```
function migrate( address _newStrategy ) external
```

Transfers all `want` from this Strategy to `_newStrategy`.

This may only be called by the Vault.
@dev
The new Strategy's Vault must be the same as this Strategy's Vault.
The migration process should be carefully performed to make sure all
the assets are migrated to the new address, which should have never
interacted with the vault before.

#### Parameters:

NameTypeDescription`_newStrategy`addressThe Strategy to migrate to.

### setEmergencyExit

```
function setEmergencyExit( ) external
```

Activates emergency exit. Once activated, the Strategy will exit its
position upon the next harvest, depositing all funds into the Vault as
quickly as is reasonable given on-chain conditions.

This may only be called by governance or the strategist.
@dev
See `vault.setEmergencyShutdown()` and `harvest()` for further details.

### protectedTokens

```
function protectedTokens( ) internal returns (address[])
```

Override this to add all tokens/tokenized positions this contract
manages on a persistent basis (e.g. not just for swapping back to
want ephemerally).

NOTE: Do not include `want`, already included in `sweep` below.

Example:

```
function protectedTokens() internal override view returns (address[] memory) { address[] memory protected = new address[](3); protected[0] = tokenA; protected[1] = tokenB; protected[2] = tokenC; return protected; }
```

### sweep

```
function sweep( address _token ) external
```

Removes tokens from this Strategy that are not the type of tokens
managed by this Strategy. This may be used in case of accidentally
sending the wrong kind of token to this Strategy.

Tokens will be sent to `governance()`.

This will fail if an attempt is made to sweep `want`, or any tokens
that are protected by this Strategy.

This may only be called by governance.
@dev
Implement `protectedTokens()` to specify any additional tokens that
should be protected from sweeping in addition to `want`.

#### Parameters:

NameTypeDescription`_token`addressThe token to transfer out of this vault.

## Events

### Harvested

```
event Harvested( )
```

### UpdatedStrategist

```
event UpdatedStrategist( )
```

### UpdatedKeeper

```
event UpdatedKeeper( )
```

### UpdatedRewards

```
event UpdatedRewards( )
```

### UpdatedMinReportDelay

```
event UpdatedMinReportDelay( )
```

### UpdatedMaxReportDelay

```
event UpdatedMaxReportDelay( )
```

### UpdatedProfitFactor

```
event UpdatedProfitFactor( )
```

### UpdatedDebtThreshold

```
event UpdatedDebtThreshold( )
```

### EmergencyExitEnabled

```
event EmergencyExitEnabled( )
```

### UpdatedMetadataURI

```
event UpdatedMetadataURI( )
```


Getting Started with Vaults

Getting Started with Vaults

Introduction

Start coding

Other reading material

# Getting Started with Vaults

This is a collection of resources that aim to be an introduction to how yVaults V2 work.

## Introduction

The best introduction to V2 is the workshop did by Storming0x (https://github.com/storming0x/). It's security focused but nevertheless a great introduction to yVaults V2.

- Video (https://www.youtube.com/watch?v=C0fsYiCI54g)

- Slides (https://docs.google.com/presentation/d/1NsePa_hXV1vsbMixTSRsPKYBHYvmVQf7IvpI_8k4p_k/edit#slide=id.p)

- Yearn State of the Vaults (https://vaults.yearn.fi/)

## Start coding

When you decide to start, this reading material is going to come handy:

- Template for Strategies (https://github.com/yearn/brownie-strategy-mix)

- Vaults V2 Repository (https://github.com/yearn/yearn-vaults)

- How to set up coding environment for Yearn Strategies (https://sambacha.github.io/yearn-vaults/index.html)

- Mint your own DAI (https://medium.com/ethereum-grid/forking-ethereum-mainnet-mint-your-own-dai-d8b62a82b3f7)

Once you have the strategy ready. This will guide you further down the road.

- Vault naming standard (https://github.com/yearn/yearn-assets/blob/master/naming-standard.md)

- Release process (https://github.com/yearn/yearn-devdocs/blob/master/docs/developers/v2/OPERATIONS.md)

- Security check (https://docs.google.com/document/d/1hBKB73kJPQM71enrG8xoSFj7wxYmczUlgigyq2KkcTE/edit#heading=h.4ieoeyetfrxm)

## Other reading material

This is complement to the others but it's not directly related to creating strategies.

- The Keep3r Network (https://macarse.medium.com/the-keep3r-network-experiment-bb1c5182bda3)

- Andre intro to Yearn Vaults (https://medium.com/iearn/yearn-finance-v2-af2c6a6a3613)

- Delegated vaults explanation (https://medium.com/iearn/delegated-vaults-explained-fa81f1c3fce2)


Operations procedures

Operations procedures

From the vault

From the strategy

Emergency Procedures

# Operations procedures

These operations might be needed at any point in time.

## Revoking a strategy with normal migration

Let's say we found a problem in one of the strategies and we want to return all funds. There are two ways of doing it.

The scripts below use the HEGIC vault as an example.

### From the vault

```
# Grab the gov accountgov = accounts.at(vault.governance(), force=True)# The cream strategy is the first in the withdrawal queues1 = Contract(vault.withdrawalQueue(0))# Revoke msg should be sent from gov or guardianvault.revokeStrategy(s1, {"from": gov})
```

After running the command you will notice:

```
vault.strategies(s1).dict()['debtRatio'] == 0
```

Last step is running a `harvest` to return funds to vault:

```
s1.harvest({"from": gov})>>> hegic.balanceOf(s1)0>>> hegic.balanceOf(vault)/1e18291731.2666932462
```

### From the strategy

From the strategy itself we can turn on emergency mode.
To do it we need to run:

```
# Grab the strategist accountstrategist = accounts.at(s1.strategist(), force=True)# Turn on the emergency exits1.setEmergencyExit({'from': strategist})# Harvest to move funds to the vaults1.harvest({'from': strategist})
```

We should also see the strategy's `debtRatio` going to `0` and funds returning to the vault.

## Emergency Procedures

We can also shutdown the vault to return assets as soon as possible. To do that we will need a guardian or governance account:

```
# Sound the alarmvault.setEmergencyShutdown(true, {'from': gov})# Harvest all strategiess1.harvest({'from': gov})s2.harvest({'from': gov})s3.harvest({'from': gov})# Check all the tokens are back in the vault>>> hegic.balanceOf(vault) == vault.totalAssets()True
```

You will notice that this procedure doesn't change the debt ratio:

```
>>> vault.strategies(s1).dict()['debtRatio']1600
```

It drops the credit to `0`:

```
>>> vault.creditAvailable(s1)0
```


Naming Conventions

Naming Conventions

yVaults

Dev Cheat Sheet (Examples)

Overview and Explanation

yVault Want Token

yUSD

yEarn

Test Products

Future Products

# Naming Conventions

## yVaults

### Dev Cheat Sheet (Examples)

- Vanilla ERC20 tokens

- Name: `${token.symbol()} or override yVault`

- Symbol: `yv${token.symbol()} or override`

- Examples: `USDC yVault`, `yvUSDC`, `aLINK yVault`, `yvaLINK`

- LP positions

- Curve

- Name: `Curve + pool + Pool yVault`

- Examples: `Curve sBTC Pool yVault`, `Curve 3pool yVault`, `Curve Y Pool yVault`

- Symbol: `yvCurve-pool`

- Examples: `yvCurve-sBTC`, `yvCurve-3pool`, `yvCurve-Y`. We make an exception for the last one and call it `yUSD`.

- Uniswap

- Name: `Uniswap + v${self.version()} + TOKEN-TOKEN + LP yVault`

- Examples: `Uniswap v2 USDT-WETH LP yVault`, `Uniswap v2 WBTC-WETH LP yVault`

- Symbol: `yvUni-TOKEN-TOKEN`

- Examples: `yvUni-USDT-WETH`, `yvUni-WBTC-WETH`

- Note: Version was included for Uniswap LP tokens to help limit confusion between UNI-v2 LP tokens and upcoming UNI-v3 LP tokens.

- Balancer

- Name: `Balancer + TOKEN-TOKEN + Pool yVault`

- Examples: `Balancer USDT-WETH Pool yVault`, `Balancer WBTC-WETH Pool yVault`

- Symbol: `yvBal-TOKEN-TOKEN`

- Examples: `yvBal-USDT-WETH`, `yvBal-WBTC-WETH`

- SushiSwap

- Name: `SushiSwap + TOKEN-TOKEN + LP yVault`

- Examples: `SushiSwap USDT-WETH LP yVault`, `Uniswap v2 WBTC-WETH LP yVault`

- Symbol: `yvSushi-TOKEN-TOKEN`

- Examples: `yvSushi-USDT-WETH`, `yvSushi-WBTC-WETH`

- Experimental

- No hard rules for `name` or `symbol`, just be sure to end `name` with "yVault".

- Examples: `yveCRV-DAO yVault`, `yveCRV-DAO`, `St. Banteg of Yearn Patron of Plebs Lido St. Ether yVault`, `sboypoplyvstETH`

### Overview and Explanation

- Acceptable alternative names include Yearn Vaults, or informally referring to the product as vaults.

- When referring to a specific yVault, the preferred name is generally `TOKEN + yVault`; this matches the `name` field on the yVault contract. However, it is also acceptable to use `yvTOKEN + Vault`, `Yearn + TOKEN + Vault` or `yvTOKEN`; the latter matches `symbol` in the contract.

- Examples: `DAI yVault`, `yvDAI Vault`, `Yearn DAI Vault`, or simply `yvDAI`

- For each yVault, name and symbol conventions are as follows:

- Name: `${token.symbol()} or override yVault`

- Symbol: `yv${token.symbol()} or override`

- A `version` field is included in the token contract to correspond to the major yVault release version.

- Additionally, developers may find it useful to denote `version` within the `name` field itself to help clarify the token to be deposited. Useful examples include Uniswap LPs (below), and also v1 vs v2 Aave aTokens.

- The predominant use case for name and symbol override is for LP tokens. The use of the term `Pool` or `LP` is interchangeable, and will be selected based on colloquial use for each protocol.

- For instance, Curve and Balancer LP positions are typically referred to as pools since they can contain more than two tokens, while Uniswap and SushiSwap positions are typically referred to as LPs.

- Curve

- Name: `Curve + pool + Pool yVault`

- Examples: `Curve sBTC Pool yVault`, `Curve 3pool yVault`, `Curve Y Pool yVault`

- In this case, `pool` is taken directly from curve.finance's UI, and we can adjust for capitalization as needed. In the case of the `3pool`, the redundant "Pool" is removed.

- Symbol: `yvCurve-pool`

- Examples: `yvCurve-sBTC`, `yvCurve-3pool`, `yvCurve-Y`

- Note: In this methodology, `yvCurve-Y` refers to the vault previously known as `yUSD`. Please see below for a more detailed discussion on proper use of `yUSD`.

- Uniswap

- Name: `Uniswap + v${self.version()} + TOKEN-TOKEN + LP yVault`

- Examples: `Uniswap v2 USDT-WETH LP yVault`, `Uniswap v2 WBTC-WETH LP yVault`

- Symbol: `yvUni-TOKEN-TOKEN`

- Examples: `yvUni-USDT-WETH`, `yvUni-WBTC-WETH`

- Note: Version was included for Uniswap LP tokens to help limit confusion between UNI-v2 LP tokens and upcoming UNI-v3 LP tokens.

- Balancer

- Name: `Balancer + TOKEN-TOKEN + Pool yVault`

- Examples: `Balancer USDT-WETH Pool yVault`, `Balancer WBTC-WETH Pool yVault`

- Symbol: `yvBal-TOKEN-TOKEN`

- Examples: `yvBal-USDT-WETH`, `yvBal-WBTC-WETH`

- Note: Since Balancer allows more than two tokens per pool, append as many `TOKEN` as needed for the pool in question.

- SushiSwap

- Name: `SushiSwap + TOKEN-TOKEN + LP yVault`

- Examples: `SushiSwap USDT-WETH LP yVault`, `Uniswap v2 WBTC-WETH LP yVault`

- Symbol: `yvSushi-TOKEN-TOKEN`

- Examples: `yvSushi-USDT-WETH`, `yvSushi-WBTC-WETH`

## yVault Want Token

- In Yearn's UI, it may be useful to denote the desired token to deposit into a specific yVault. For basic ERC20 `want` tokens, `name` and `symbol` can be pulled directly from the token contract and utilized as-is.

- Examples: `USD Coin`, `USDC`, `ChainLink Token`, `LINK`

- However, for LP positions, naming needs to be standardized.

- Curve

- Name: `Curve + pool + Pool`

- Examples: `Curve sBTC Pool`, `Curve 3pool`, `Curve Y Pool`, `Curve Compound Pool`

- In this case, `pool` is taken directly from curve.finance's UI, and we can adjust for capitalization as needed. In the case of the `3pool`, the redundant "Pool" is removed.

- Symbol: `crvPOOL or override`

- Examples: `crvBUSD`, `crvCOMP`, `crvGUSD`, `crvMUSD`, `crvTBTC`, `crvSBTC`, `yCRV`, `3Crv`

- These names were chosen as `crvBUSD` and `crvSBTC` are already fairly widely used, and applying this formula works well for other pools. `yCRV` and `3Crv` are the allowed exceptions, as `yCRV` is the most widely used name for that pool, and `3Crv` usage is now fairly common with the recent admin fee distribution.

- Uniswap

- Name: `Uniswap + v${self.version()} + TOKEN-TOKEN + LP`

- Examples: `Uniswap v2 USDT-WETH LP`, `Uniswap v2 WBTC-WETH LP`

- Symbol: `TOKEN-TOKEN UNI`

- Examples: `USDT-WETH UNI`, `WBTC-WETH UNI`

- Balancer

- Name: `Balancer + TOKEN-TOKEN + Pool`

- Examples: `Balancer USDT-WETH Pool`, `Balancer WBTC-WETH Pool`

- Symbol: `TOKEN-TOKEN BPT`

- Examples: `USDT-WETH BPT`, `WBTC-WETH BPT`

- Note: Since Balancer allows more than two tokens per pool, append as many `TOKEN` as needed for the pool in question.

- SushiSwap

- Name: `SushiSwap + TOKEN-TOKEN + LP`

- Examples: `SushiSwap USDT-WETH LP`, `Uniswap v2 WBTC-WETH LP`

- Symbol: `TOKEN-TOKEN SLP`

- Examples: `USDT-WETH SLP`, `WBTC-WETH SLP`

## yUSD

- While the term `yUSD` was used to refer to the Curve Y Pool yVault in the past, under our updated naming convention this vault token is now `yvCurve-Y`. However, usage of `yUSD` is still permissable when referring to the asset itself.

- Example: Yearn pays monthly grants in `yUSD`.

- In the future, if Yearn creates a new `yUSD` that is a collection of several yVault tokens (as has been previously discussed), then the current `yUSD` will simply be referred to as `yvCurve-Y` and only the new token will be `yUSD`.

## yEarn

-

These are Yearn's original yield-aware tokens, whose v1 and v2 contracts can be found here (https://docs.yearn.fi/getting-started/products/yvaults/vault-tokens#v2-yvault-tokens) or by clicking on the etherscan icon when viewing the vault:

![""](https://i.imgur.com/FZ0BJjf.png)

-

These products should be referred to as yEarn Tokens, `underlying token name + Earn`, or `y{token.symbol()}v${self.version()}`

- Examples: `yDAIv2`, `yDAI Earn`, `yBUSDv3`, `yBUSD Earn`

## Test Products

- For deployed contracts that have not reached their final production version, a simple modification is included to designate these on the contract level as being test products.

- Name: `${token.symbol()} or override + Test + Product`

- Symbol: `yt${token.symbol()} or override`

- Examples: `DAI Test yVault`, `ytDAI`

- Additionally, the v2 yVault contracts have upgradeable `name` and `symbol` fields. This means that should a test contract perform well, these fields can be updated to reflect that it is no longer a test contract, removing the need to deploy new contracts.

## Future Products

- Future products can follow a simple naming convention: `y + product`, where the product and any potential token names follow similar guidelines as above with yVaults. These can then be further modified as needed based on the product(s).

- Examples: `ySwap`, `yBorrow`, `yTrade`


Emergency Procedures for Yearn Finance

Emergency Procedures for Yearn Finance

Introduction

Definitions and Examples of Emergencies

Roles

Facilitator

Multi-sig Herder

Strategist Lead

Core Dev Lead (Guardian)

Web Lead

Ops

Emergency Steps

Emergency Checklist

Tools

Incident Post Mortem

Post Mortem Outputs

Post Mortem Steps

# Emergency Procedures for Yearn Finance

TL;DR: Emergency Checklist (https://docs.yearn.fi/developers/smart-contracts/deprecated/V2/version-0.4.2/process-and-procedures/emergency#emergency-checklist)

## Introduction

This document details the procedures and guidelines that should take place in the event of an emergency situation. Its purpose is to minimize the risk for loss of funds for Yearn's users, Treasury, and Smart Contracts.

## Definitions and Examples of Emergencies

For the purposes of this document, an emergency situation is defined to be:

Any situation that may lead to a considerable amount of loss of funds for Yearn users, Yearn's Treasury, or Smart Contracts deployed by Yearn.

This is a non exhaustive list of possible emergency scenarios:

- Bug/Exploit in Vault/Strategy code that can cause a loss of funds for users

- Bug/Exploit in an underlying protocol that a Yearn Strategy is utilizing that may lead to loss of funds

- Loss of private keys for a key role, such as a Strategist

- Potential exploit discovered by team or bounty program researcher

- Active exploit / hack in progress discovered by unknown party

## Roles

In the event of an emergency situation, the following roles should be assigned to Yearn contributors working to resolve the situation:

- Facilitator

- Multi-sig Herder

- Strategist Lead

- Core Dev Lead (Guardian)

- Web Lead

- Ops

A contributor may be assigned up to two of these roles concurrently.

### Facilitator

Facilitates the emergency handling and ensures the process described in this document is followed, engaging with the correct stakeholders and teams in order for the necessary decisions to be made quickly. A suitable Facilitator is any person familiar with the process and is confident that they can drive the team to follow through. It's expected that the person assigned to this role has relevant experience either from having worked real scenarios or through drill training.

### Multi-sig Herder

Responsible for ensuring that different Yearn teams' Multi-sig wallets (i.e. dev.ychad.eth, brain.ychad.eth, ychad.eth) are able to execute transactions in a timely manner during the emergency.

Main responsibilities:

- Help clear the queue of any pending operations once the War Room starts

- Coordinate required signers so they can respond quickly to queued transactions

- Prepare or help with transactions in different multi-sigs
Reference:

- emergency-toolbox (https://github.com/yearn/emergency-toolbox)

- CMO (https://github.com/yearn/chief-multisig-officer) - private

- strategists-ms (https://github.com/yearn/strategist-ms) - private

### Strategist Lead

In charge of coordinating quick changes to management and strategist roles during the emergency, including but not limited to:

- Prepare and Execute Strategist Multi-sig transactions and operations

- Set strategy in emergency exit mode

- Update debt ratios

- Remove Strategies from Queue

- Coordinate Harvests

### Core Dev Lead (Guardian)

Coordinates quick changes to Governance and Guardian roles during the emergency, including but not limited to:

- Prepare and Execute Core Dev Multi-sig transactions and operations

- Revoke a Strategy

- Set vault in emergency shutdown mode

### Web Lead

Coordinates quick changes to UI and Websites as required, including but not limited to:

- Disable deposits/withdrawals through the UI

- Display alerts and banners

- Other UI related work

### Ops

In charge of coordinating comms and operations assistance as required:

- Clear with War Room what information and communication can be published during and after the incident

- Coordinate Communications

- Take note of timelines and events for disclosure

## Emergency Steps

Also see Check list (https://docs.yearn.fi/developers/smart-contracts/deprecated/V2/version-0.4.2/process-and-procedures/emergency#emergency-checklist) and Tools (https://docs.yearn.fi/developers/smart-contracts/deprecated/V2/version-0.4.2/process-and-procedures/emergency#tools).

This acts as a guideline to follow when an incident is reported requiring immediate attention.

The primary objective is minimized the loss of funds, in particular for Yearn's users. All decisions made should be driven by this goal.

- Open a private chat room (War Room) with a voice channel and invite only the team members that are online that can cover the roles described above (https://docs.yearn.fi/developers/smart-contracts/deprecated/V2/version-0.4.2/process-and-procedures/emergency#roles). The War Room is limited to members that act in the capacities of the designated roles, as well as additional persons that can provide critical insight into the circumstances of the issue and how it can best be resolved.

- All the information that is gathered during the War Room should be considered private to the chat and not to be shared with third parties. Relevant data should be pinned and updated by the Facilitator for the team to have handy.

- The team's first milestone is to assess the situation as quickly as possible: Confirming the reported information and determine how critical the incident is. A few questions to guide this process:

- Is there confirmation from several team members/sources that the issue is valid? Are there example transactions that show the incident occurring? (Pin these in the War Room)

- Is the Strategist that knows the most about the code in the War Room? Can the Strategist in question be reached? If not, can we reach the backup Strategist?

- Are funds presently at risk? Is immediate action required?

- Is the issue isolated or does it affect several vaults/strategies? Can the affected contracts be identified? (Pin these in the War Room)

- Which Multi-sig will require signing to address the issue? The Multi-sig Herder should begin to notify signers and clear the queue in preparation for emergency transactions.

- If there is no immediate risk for loss of funds, does the team still need to take preventive action or some other mitigation?

- Is there agreement in the team that the situation is under control and that the War Room can be closed?

- Once the issue has been confirmed as valid, the next stop is to take immediate corrective action to prevent further loss of funds. If root cause requires further research, the team must err on the side of caution and take emergency preventive actions while the situation continues to be assessed. A few questions to guide the decisions of the team:

- Disable deposits to the affected Vaults? Should migrations and deposits be removed from the UI?

- Activate Emergency Exit on the affected Strategies?

- Remove one or more strategies from the withdrawal queue from the affected vaults?

- Activate Emergency Shutdown in the Vault?

- Revoke 1 or more Strategies?

- Are multiple Team members able to confirm the corrective actions will stop the immediate risk through local Ganache fork testing? Strategist and Core Dev main roles in particular to confirm this step.

- The immediate corrective actions should be scripted or taken from the repository emergency-toolbox (https://github.com/yearn/emergency-toolbox) and executed ASAP. Multi-sig Herder and Strategist Lead should coordinate this execution within the corresponding roles. NOTE: This step is meant to give the War Room time to assess and research a more long term solution.

- Once corrective measures are in place and there is confirmation by multiple sources that funds are no longer at risk, the next objective is to identify the root cause. A few questions/actions during this step that can help the team make decisions:

- What communications should be made public at this point in time?

- Can research among members of the War Room be divided? This step can be open for team members to do live debug sessions sharing screens to help identify the problem using the sample transactions.

- Once the cause is identified, the team can brainstorm to come up with the most suitable remediation plan and its code implementation (if required). A few questions that can help during this time:

- In case there are many possible solutions can the team prioritize by weighing each option by time to implement and minimization of losses?

- Can the possible solutions be tested and compared to confirm the end state fixes the issue?

- Is there agreement in the War Room about the best solution? If not, can the objections be identified and a path for how to reach consensus on the approach be worked out, prioritizing the minimization of losses?

- If a solution will take longer than a few hours, are there any further communications and preventive actions needed while the fix is developed?

- Does the solution require a longer term plan? Is there identified owners for the tasks/steps for the plan's execution?

- Once a solution has been implemented, the team will confirm the solution resolves the issue and minimizes the loss of funds. Possible actions needed during this step:

- Run in ganache fork simulations of end state to confirm the proposed solution(s)

- Coordinate signatures from multi-sig signers and execution

- Enable UI changes to normalize operations as needed

- Assign a lead to prepare a disclosure (https://github.com/yearn/yearn-security) (should it be required), preparing a timeline of the events that took place.

- The team agrees when the War Room can be dismantled. The Facilitator breaks down the War Room and sets reminders if it takes longer than a few hours for members to reconvene.

### Emergency Checklist

This checklist should be complemented with the steps (https://docs.yearn.fi/developers/smart-contracts/deprecated/V2/version-0.4.2/process-and-procedures/emergency#emergency-steps)

- Create War room with audio

- Assign Key Roles to War Room members

- Add Strategist or other Expert (or their backup) to the War Room

- Clear related Multi-sig queues

- Disable deposits and/or withdrawals as needed in the web UI

- If share price has been artificially lowered, then call `vault.setDepositLimit(0)` from governance

- Confirm and identify Issue

- Take immediate corrective/preventive actions in order to prevent (further) loss of funds

- Communicate the current situation internally and externally (as appropriate)

- Determine the root cause

- Propose workable solutions

- Implement and validate solutions

- Prioritize solutions

- Reach agreement in Team on best solution

- Execute solution

- Confirm incident has been resolved

- Assign ownership of security disclosure report

- Disband War Room

- Conduct immediate debrief

- Schedule a Post Mortem

### Tools

List of tools and alternatives in case primary tools are not available during an incident.

DescriptionPrimarySecondaryCode SharingGitHubHackMd (https://hackmd.io/), CodeShare (https://codeshare.io/5Og7mj)Communications*TelegramDiscordTransaction DetailsEtherscan (https://etherscan.io/)Tenderly (https://tenderly.co/)DebuggingBrownieTenderly (https://tenderly.co/)Transaction Builderape-safe (https://github.com/banteg/ape-safe)Backup if gnosis safe Api is not working?Screen Sharing*jitsi (https://jitsi.org/)Google Hangouts

Facilitator is responsible to ensure no unauthorized persons enter the War Room or join these tools via invite links that leak.

## Incident Post Mortem

A Post Mortem should be conducted after an incident to gather data and feedback from War Room participants in order to produce actionable improvements for Yearn processes such as this one.

Following the dissolution of a War Room, the Facilitator should ideally conduct an immediate informal debrief to gather initial notes before they are forgotten by participants.

This can then be complemented by a more extensive Post Mortem as outlined below.

The Post Mortem should be conducted at the most a week following the incident to ensure a fresh recollection by the participants.

It is key that most of the participants of the War Room are involved during this session in order for an accurate assessment of the events that took place. Discussion is encouraged. The objective is to collect constructive feedback for how the process can be improved, and not to assign blame on any War Room participants.

Participants are encouraged to provide inputs on each of the steps. If a participant is not giving inputs, the Facilitator is expected to try to obtain more feedback by asking questions.

### Post Mortem Outputs

- List of what went well

- List of what be improved

- List of questions that came up in the Post Mortem

- List of insights from the process

- Root Cause Analysis along with concrete measures required to prevent the incident from ever happening again.

- List of action items assigned to owners with estimates for completion.

### Post Mortem Steps

- Facilitator runs the session in a voice channel and shares a screen for participants to follow notes.

- Facilitator runs through an agenda to obtain the necessary outputs (https://docs.yearn.fi/developers/smart-contracts/deprecated/V2/version-0.4.2/process-and-procedures/emergency#post-mortem-outputs).

- For the Root Cause Analysis part, the Facilitator conducts an exercise to write the problem statement first and then confirm with the participants that the statement is correct and understood.

- Root Cause Analysis can be identified with following tools:

- Brainstorming (https://en.wikipedia.org/wiki/Brainstorming) session with participants

- 5 Whys Technique (https://en.wikipedia.org/wiki/Five_whys)

- Once Root Causes have been identified, action items can be written and assigned to willing participants that can own the tasks. It is recommended that an estimated time for completion is given. A later process can track completion of given assignments. Note: The action items need to be clear, actionable and measurable for completion

- The Facilitator tracks completion of action items. The end result of the process should be an actionable improvement in the process. Some possible improvements:

- Changes in the process and documentation

- Changes in code and tests to validate

- Changes in tools implemented and incorporated into the process