Add rebalancing slippage protection

[jribbink]

Work towards #5.

Adds slippage protection to vault rebalancing only — deposit/redeem slippage is the caller's, via the ERC4626 router (#53). The lever/delever swaps set amountOutMinimum to the oracle-expected output less maxSlippageBps (1e4-scaled), tunable by the admin via setMaxSlippageBps.

[holyfuchs]

The proposed implementation essentially checks price impact not slippage and enforces a specific number on all users.
We can use the Yearn ERC4626 Router and don't have to make changes to our contract implementations.

We still need the price impact protection for the rebalance function.

[jordanschalm]

@holyfuchs Can you be more specific about the changes you're suggesting?

We can use the Yearn ERC4626 Router and don't have to make changes to our contract implementations.

The Yearn ERC4626 Router operates on vault instances satisfying IYearn4626. As I understand it, that interface adds additional functions to the vault which allow the user to specify maxLoss (equivalent to the slippage protections here). But if we were to use that pattern, we would still need to implement those loss-constraining functions used by the router in our vault contract, no?

Here's the issue description #5:

User-facing slippage limits on both deposit and redeem flows. Can be wrapped via the Yearn ERC4626 Router (Yearn-ERC4626-Router).

Below I'm using the term "slippage" to mean the difference between the oracle price and the price we actually realize in a swap.

My interpretation of the desired behaviour here:

• Implement the slippage-constraining functions defined by IYearn4626 in FCMVault
  • Then we have user-facing slippage protection (users can configure desired bands
  • Then we can use the Yearn Router for these methods
  • The implication is that for user-initiated actions (deposit etc), the user is responsible for setting slippage protection bands
• Since rebalancing is initiated by the vault, the vault needs to set slippage protection bands for swaps occuring during a rebalance.
  • So, we still need admin-set config for slippage protection, but it will only apply for rebalancing (or generally automated swaps as opposed to user-initiated swaps)

[holyfuchs]

• Implement the slippage-constraining functions defined by IYearn4626 in FCMVault

  • Then we have user-facing slippage protection (users can configure desired bands
  • Then we can use the Yearn Router for these methods
  • The implication is that for user-initiated actions (deposit etc), the user is responsible for setting slippage protection bands

• Since rebalancing is initiated by the vault, the vault needs to set slippage protection bands for swaps occuring during a rebalance.

I would suggest using an implementation that doesn't require changing the core contract, unless there is a specific benefit in doing so. For example this one:
https://github.com/ERC4626-Alliance/ERC4626-Contracts/blob/main/src/ERC4626Router.sol

• So, we still need admin-set config for slippage protection, but it will only apply for rebalancing (or generally automated swaps as opposed to user-initiated swaps)

Yes, we still need this functionality for rebalancing.

[jribbink]

@holyfuchs @jordanschalm

Got it, so from what I can see the ERC4626-Alliance ERC4626Router is the best fit for our situation then. The initial ticket mentioned the possibility of using Yearn-ERC4626-Router, but it seems like it's fairly specific to Yearn, and that this is the generic standard.

I think we can split this into two separate PRs then:

1. I'll open a PR to add integration tests with the ERC4626Router to validate that our vault is compatible (this is generally guaranteed by spec conformance, however, differences like our allowlist could cause compatibility issues and I just think it's a good sanity check overall). In addition, I'll make sure the contract is deployed on both mainnet & testnet, shouldn't require changes to our repo other than maybe a doc/README change, but at least this way it's ready for frontend integration.
2. I'll focus this PR on adding slippage protection to rebalancing, not deposit/redeem. I still have some open questions about how this should be tuned - skipping a DEX swap when slippage is high could cause larger NAV losses (through increased liquidation risk) than the DEX fees it aims to prevent. Having thought it through, I think this is less of an issue than I initially worried. The Morpho liquidation fee is fixed and low (~5% at our LLTV), so our downside here is bounded, and it only materializes in the unlikely case where our bound is too tight during a price crash - an acceptable loss. Since it's both bounded and unlikely, I think we can discount the cost of liquidations when tuning slippage, as it's outweighed by the long-term slippage savings the protection provides.