# Best Practices at yearn: emergency functions

If a yearn strategy has any parts of its functional logic contain any of the following pieces, emergency functions need to be in place to allow retrieval of funds in emergency scenarios.

Every chain of the logic can break, so during strategy writing and review, assume each part of the chain could be broken through migration, exploitation or strategy writing logic flaw and account for that with writing emergency functions.

Differentiate through modifiers inside strategy also between access level of SMS (strategist multi-sig) that can move funds back only into the strategy and incur small losses and CMO (chief multi-sig officer) that can update existing addresses to new addresses (exploitable otherwise) and move funds even outside of strategies. In yearn V3, the SMS' address should be set to the emergencyAdmin of the strategy, while some strategies should potentially feature an additional onlyGovernance custom modifier referencing the CMO address (ychad.eth) as the governance address to call sensitive functions like e.g. sweep.

**All of the listed possible emergency functions should be implemented in a yearn strategy if the corresponding logic piece exists inside the strategy**. They also necessitate a good explanation with especially thorough commenting inside the strategy, considering that they might have to be called in a scenario where a lot of funds are at stake by any other strategist.

## Necessary emergency function sorted by scenario (and urgency)

### War room scenario:
- SMS emergency function to move funds into strategy immediately with single tx. Reduce all allowances to other protocols to 0. Reason: **ease-of-use in war room**. Speed is king. This should be done in V3 with emergencyWithdraw override.
- Alternative scenario where single tx is important: honeypot scenario, where many exploiters could also be draining funds of underlying protocol non-atomically: get funds back into strategy in one fast tx (high gas cost since other exploiters are trying to get more funds and are willing to pay a lot of gas for it).
- SMS emergency function to retrieve funds into strategy ignoring illiquidity.
- SMS emergency function to retrieve funds into strategy and leaving/ditching rewards (small loss only: usually low percentage of total funds, so sometimes important to get funds out while ignoring rewards).
- CMO emergency function to cut significant losses (such as debt) --> retrieve only surplus/overcollateralization of collateral minus debt and retrieve into strategy.

### Leveraged strategy LTV/collateralization ratio movement:
- There should always be a function to allow keepers to tend the strategy and rebalance the strategy's LTV/collateralization ratio. Logically, it can also be used by strategists directly to rebalance in case keepers aren't working. It's important to have good commenting & documentation so any strategist can call this function from SMS in case keepers aren't working.
- SMS emergency function to easily manually fully deleverage if something is broken. (low or no function arguments required for ease of use)
- SMS emergency function for lossy rebalancing of the strategy's LTV/collateralization ratio in case the usual rebalance function has a loss protection built-in. We need to be able to ignore that loss protection with this emergency function. We need to save the strategy from liquidation to stop incurring an even higher loss.

### Approval to swap-router/swap-pool exploit:
- Usually yearn strategies give type(uint256).max approvals to swap-routers/swap-pool to sell rewards. In case of an exploit of the swap-router/swap-pool that can be drained, but unharvested reward amounts are usually small enough in size that a draining of just rewards is not a big issue. In case want token or any other token that makes up a significant part of the strategy is given such an approval to a swap-router/swap-pool, there needs to be an SMS emergency function to reduce that allowance to 0. If strategy health (e.g. LTV) is maintained by tending of keepers that requires that allowance to be non-zero to maintain the strategy health, then the emergency function needs to pull all the funds into the strategy and unwind the position so the strategy health is not at risk. In addition the allowance must then be reduced to 0.
- A much better practive for approval for essential non-reward tokens (such as want token) to swap-routers/swap-pools is to give not type(uint256).max approval, but just the exact approval amount to rebalance the strategy health and then remove the allowance until the next tending action.

### Flashloan migration or flaw:
- SMS emergency function to be able to partially unwind strategy and send funds back to the strategy **without** a Flashloan (use loops if necessary; test if gas usage is realistic).
- SMS emergency function to FULLY unwind strategy and send back to the strategy **without** a Flashloan (use loops if necessary; test if gas usage is realistic).
- SMS emergency function to switch between predefined flashloan addresses (preferred). If not possible: CMO emergency function to define new address to flashloan address.
- Account for sudden illiquidity of flashloan or reduction of maximum flashloan and

### Strategy logic flaw:
- SMS emergency function to retrieve funds in the simplest way possible into the strategy circumventing complex math OR a lot of moving pieces inside the strategy.
- SMS emergency function to circumvent loss protection built into a strategy if a strategy was assumed to be completely lossless, but has netted a loss due to unforseen circumstances.
- CMO function to move funds to a new strategy is usually done through prepareMigration. If that is not possible (e.g. multi-step process), write custom CMO emergency function to move funds and account for prepareMigration as part of the steps.

### Reward swap-router/swap-pool migration or flaw:
- SMS emergency function to switch between predefined swap-router/swap-pool addresses (preferred). If not possible: CMO emergency function to define new address to swap-router/swap-pool address.
- Account for sudden illiquidity of defined swap-router/swap-pool and allow for alternative paths of Reward selling (different protocol ideally).
- Potentially add the possibility to let Tradefactory swap the reward as an alternative. It's also possible if reward addresses could change in the future to add a SMS function to migrate to a new reward/additional reward address by requiring that the new address is not want token address (or any other current vital part of the strategy, such as debt tokens etc.)