Autonomous Yield Seeking Vaults

# Autonomous Yield Seeking Vaults Current 4626 implementations come with a few issues: 1. With ever changing yield environments constant work is needed to wrap and integrate new protocols 2. Integrating protocols is hard. Getting things absolutely right and save takes time and money 3. Less flexibility. Since the integration takes time its rare that yield aggregators can utilise the hottest products even though those are usually the ones with the highest yield. 4. Management. Vaults needed to constantly monitored and managed. 5. MEV. A lot of vaults simply farm and compound rewards which makes these compounding action succeptable to MEV. This new vault design aims to tackle of these issues. The proposed model will work for any protocol without the need for additional adapters. The vault will guarantee market or even better than market rates without the need of permissioned roles or active management. Lastly it removes MEV from the vault entirely. As a depositor I simply want to earn a competitive rate on my assets and not loose any funds. I dont really care exactly where the yield came from or who produced it as long as I get my yield and my funds are save. Now as a fund manager you want to manage as much money as possible earning high yield to get a huge payout in performance fees. If we now bundle depositor funds in a vault and let anyone manage them to earn a performance fee how should we select the best manager for the job? If we simply appoint someone they might not work as hard since they arent in danger of loosing that job. So we make it open for everyone. But how to select from a group of anonymous strangers? We dont know if they will manage what yield they can achieve or if they will manage the funds responibly. The first issue we can solve by letting anyone propose a rate they want to achieve for depositors. The manager-to-be simply posts a deposit to the vault and sets a rate in which this deposit will be paid out as yield to the vault. Now the vault depositors get a save rate paid for by the manager. They are set. From this point on its in the managers best interest to make their deposit back and than some. Since the users are covered with their yield we will give all actual accrued yield of the vaults asset to the manager aligning their incentives with the vault depositors. Though how do we know that they wont mismanage the funds? Afterall they only needed to pay a small deposit amount (which is paid out to the depositors) to play with a bunch of money of all depositors. For this we add `mandates`. A `mandate` is set by the vault creator and specifies which assets can be used to generate yield and which oracle shall be used to quantify the vaults holding of that asset. Everytime the `manager` now claims funds, sells rewards, buys new assets or simply rebalances the vault can check (using the oracles) that the vaults value didnt drop below its expected value (depositor inflow + yield paid by the `manager`). If an action of the `manager` would violate this condition their action simply reverts. It would also revert if the `manager` uses assets that arent allowed by the `mandate`. This creates an environment in which external `managers` compete to deliver yield to the vault depositors for the right to farm with their deposits. Over time the yield paid out by `managers` should converge with the rate that a `manager` can achieve by farming with the deposited assets. Anytime there is a spread between what the current `manager` pays to farm and the extractable yield some other external `manager` should swoop in, pay a higher rate to the vault for the right to farm. The achievable rate is simply limited by the assets allowed via `mandates`. Less risky assets like cTokens, aTokens or sDAI will allow the `manager` to extract less yield. Therefore they will pay less to the vault to extract that value. But the risk of drawdowns is also severly limited. A vault that also allows the `manager` to buy BTC, ETH or farm riskier protocols makes it worthwhile for the `manager` to pay higher yield to the vault but increases the risk of drawdowns. The `manager` can be forced to post an additional security deposit which can be used in case of drawdowns. Worst case if this isnt enough and assets drop too fast in value we use dutch actions to allow anyone to restore the vault clsoe to its expected value. In this case anyone can buy all the vaults assets for a discount which will limit the drawdown. ## Permissionless Yield The core innovation at the heart of this new design is how yield gets generated. Traditionally the vault sells farmed rewards for additional assets. In this new model anyone can bid to manage the vaults assets. They pay yield out directly to the vault depositors and in turn get the right to keep all yield generated by the assets in the vault. We call these actors `managers`. `Managers` observe the yield potential in a vault and bid to extract it. For example if a vault has assets in a convex farm earning 18% a `manager` could offer up to 18% yield in the vaults asset to extract the rewards from that convex farm for the vault. In this way the vault will always accrue yield up to market rate in its accounting asset while outsourcing all MEV and management to external `managers` which will run off-chain infrastructure to handle it efficiently. ## Rebalancing Now if `managers` could only farm one opportunity per vault, users would still need to chase the highest rates across multiple protocols. This is where the `mandate` comes into play. The `mandate` describes which assets can be utilised by `managers` and what the `min` and `max`-allocation per asset must be. The `mandate` also includes an oracle per asset which we will elobarate later. Only assets allowed by a `mandate` can be held in the vault. Based on these `mandates` a `manager` rebalances the vaults assets to extract as much yield as possible for themselfs. Since this creates more opportunities for profit other `managers` will come in and bid higher yield to the vault for the right to extract the farmed yield. This should at some point converge to the point where the vault earns the ideal market rate for whats possible by their `mandates` minus a small spread for the active `manager`. In essence `managers` bid for the right to extract the most yield which can be gained with the vaults assets. They pay upfront yield to the vault and try than to make it back by extracting as much yield as possible for themselfs. A `manager` can therefore loose their deposit which is used as yield for the vault but has the potentialy to earn multiples higher than that if they can invest it well. Which leaves the vault with no further need for management and steady competitive yield. The active `manager` is chosen simply by submitting a higher yield rate than the previous active `manager`. If the current `manager` pays out 8% APY to the vault and someone offers to pay out more than that they will become the new active `manager` and get the right to manage the vaults funds. ## Safeguards One can think of this system as a sort of undercollateralized loan. The `manager` delivers for example 10% upfront and than gets to use all of the vaults funds. This begs the question "If a `manager` only needs to invest a small amount, is incentivised to extract as much as possible and isnt on the hook for losses how do you keep the vault safe?". One of the main features for safeguarding are the `mandates`. These control which assets can be utilised by the `managers`. Lets take two vaults to illustrate this. Both vaults use USDC as their accounting asset which users deposit and withdraw. Vault A has set more conservative `mandates` which allow only assets like sDAI, oUSD, and some USDC-LPs on Convex. These assets shouldnt vary much in price against USDC. Since the `manager` can only use these assets there isnt too much risk of drawdowns. Vault B in comparison allows the `manager` to also hold BTC, ETH and some covered-call vaults. Now the `manager` could simply buy and hold BTC with the vault which may earn a lot but has the potential for steep drawdowns aswell. Though before depositing users can choose which kind of risk they are comfortable with. Since `mandates` also include a `max`-allocation variable this risk can further be kept in check by only allowing a small allocation to BTC in Vault B. Nonetheless drawdowns might happen. Either in the event of a depeg or simply by falling asset values. To combat this all assets in the vault can be sold off via dutch auctions once the asset value drops below a certain pre-configured level. This wont stop drawdowns entirely but limits their impact. Additionally `managers` can be required to deposit a security deposit next to their yield payment which can be used first to stop drawdowns. ## Functionality To compute the expected vault value we will track all deposits/withdrawals of users. `Managers` will deposit their yield and submit a `rate per second` to drip into the vaults funds from their deposit. Together with the deposits this calculates the expected `totalAssets`. The active `manager` can now send any encoded call to the vault to use the vaults funds in any way the like from depositing it, trading or claiming and selling rewards. At the end of the transaction a hook in the vault simply checks if the `totalAssets` still aligns with our expected `totalAssets` and if the vault only holds assets allowed by the set `mandates`. Since each asset has a configured oracle in the `mandate` we will simply multiple the asset balances with the oracle value and sum them to check that the managers action didnt steal any user funds. This value simply must align with the `totalAsset` value based on deposits and yield. Exess funds can be withdrawn by the `manager`. In case the action would cause a drawdown we can first take funds from the `managers` security deposit. If this isnt enough to cover slippage or drawdown the action will simply revert. This allows the `manager` to have full flexibility while also making sure that they cant steal user funds. When a new user wants to become `manager` they simply need to provide a higher `rate per second` and post a deposit. After a small time delay (to prevent someone from simply claiming rewards in the same block) they will become the new `manager` and the previous `manager` can claim their unused `yield deposit`. If a `managers` `yield deposit` runs out they automatically loose access to the vault. If at any point the `calculated totalAssets` falls below the `expected totalAssets` anyone can liquidate the `managers` security deposit to restore the `expected totalAssets`. If this isnt enough to cover everything all assets get auctioned off via dutch actions. Now anyone can claim the vault assets by paying the vaults accounting asset. Changes to `mandates` can be proposed by anyone. This includes removing assets, changing allocation limits or oracles and adding entirely new `mandates`. This can be used by `managers` for example to propose new investments as soon as a new protocol goes live. This allows the vault to stay constantly comeptitive and flexible. Currently there is a permissioned `owner`-role that controls which changes actually get accepted. This `owner` can also manage the required `safety deposit` for managers. To make this entirely permissionless we can add a futher contract in the future that acts as the `owner` and lets vault share holders vote on all these decisions. ## Risks Since managers can use the vault deposits like an undercollateralized loan and can call any encoded function via the vault we need to safeguard against them trying to steal funds or deploying the funds in a reckless fashion. This should be largely controlled via `mandates` and the included oracles but still leaves some room for issues. Thats where `safety deposit` and the dutch actions for liquidations come into play. This should make the vaults safe if set up properly. The biggest risk therefore comes from bad, faulty or manipulated oracles. A clear attack vector is to manipulate an oracle to show a very high value for a certain `mandate`-asset and than to withdraw funds from the vault. The vault would think that its `calculated totalAssets` is still higher than the `expected totalAssets` cause of the inflated oracle value giving the manager the chance to withdraw user funds. Therefore similar to lending protocols vaults need to be set up with sensible assets and must put special attention on the used oracles. ## Further Research There are some things left to improve on. ### Vault as Smart Wallet First is how to use the vault like a smart wallet as a `manager`. The manager should be able ideally to use any DeFi frontend to interact but simply send the calls to the managed vault. ### Multiple Managers In case vaults get significant TVL it might be hard for one `manager` to front the `security deposit` and yield. This would only allow big players to act as `managers` leading to further centralisation. Managers could bid for a certain allocation of the `totalAssets` by the vault not just the total amount. For this we would need an ordered stack of `managers` with their `allocation`, `yield per second`, `security deposit`, `yield deposit` and their vault holdings (the asset balances which they managed). This stack would be sorted by `yield per second`. The new `manager` would now remove `allocations` from all `managers` that posted a lower `yield per second`. In this scenario `managers` would define how much of the vault TVL they would want to manage. One `manager` could post a small rate for the whole TVL and smaller `managers` could post higher rates for smaller allocations that they can support. ### Withdrawal In the current model users would need to request a withdrawal which prompts the manager to free up those funds. Ideally though we could allow for instant withdrawals without the need for float in the vault. At the moment withdrawals will simply withdraw from float and fail if there arent enough funds. #### Option A One option would be to have a seperate withdrawal function that simply withdraws an available asset chosen by the user. The user would burn shares as usual, define the asset amount (in the accounting asset) and than specify the address of the asset they wish to withdraw. We will use that assets oracle to calculate the actual withdraw amount and return that asset to the user. Now they can zap it out to the original asset. #### Option B Similar to "Option A" but the function would take an "afterWithdraw" call which encodes a function call to an external protocol to convert the withdrawn asset to the accounting asset and return it to the user. #### Option C Add a `requestWithdraw` following suggestions from [EIP-7540](https://eips.ethereum.org/EIPS/eip-7540#definitions). Though this would need some incentive/punishment system for the `manager` to service the request in a timely manner. ### Zero Oracles In the current design there is no need for any hardcoded smart contract interactions with other protocols. This frees up time and ressources BUT we still need to write custom oracles to support a variety of assets. Ideally we can find a way to get rid of that aswell by economic securites and rely on the `expected totalAssets` as only accounting tool. This feels like a hard issue to crack since the entire security model of `managers` beeing able to call arbitrary functions is based on these oracles to protect the user.