Summary:
This YIP proposes a redesign of the Yearn Vaults system to accommodate several improvements meant to increase the robustness, security, and flexibility of the Vaults moving forwards
Motivation:
The current yVault design has made it possible for Yearn to scale to the point it is today. However, due to it’s design, it has been difficult to maintain, and is missing a number of features that could improve the risk/return profile of Vaults, and improve their overall security and reliability in the process.
We propose that a refactor of the Vault system to add these features would be an improvement to the overall design, enabling the maintainers of the Yearn codebase to increase their efforts at Quality Assurance and testing for faults, streamline the development of new and innovative strategies (with an improved and standardized API for Strategists to use), and most importantly give the Governance of Yearn the tools they need to optimize Vault yields and manage risk of a larger system better.
Improvements for V2 design:
Allow a Vault to have multiple strategies at the same time
Streamline the development cycle of new strategies using a standard API
Streamline the QA/Security process for Vaults, to ensure the highest quality code
Ensure the Vaults are tested to handle different types of Strategy risk/return/volatility thresholds
Make it easier and safer for integrators to use Vaults in their projects
Specification:
The Specification for the proposal is being tracked a Gist to better track any changes made.
Trusted. This is a change versus the v1, because allowing open access to keepers has caused issues for us in the past.
Note this could eventually be a “Keeper DAO” of some sort, as soon as we can have a guarantee of the proper calling frequency of the the strategies to maintain stability
So the reasoning behind this decision is that the risk of issues should be lower by having a trusted/whitelisted Keeper ?
A “Keeper DAO” would make sense but would require complex specification and implementation.
An option is to have the Keeper bond/stake some funds to do it’s job and to reward it enough to make it worth the amount of funds locked + gas spent. Actually this stake could be shared by YFI holders who could choose to stake their YFI as risk assesment mechanism (similar to NXM or Aave staking), earning a little bit more rewards by doing so.
Anyway I guess my point is I don’t like so much the idea of a single point of failure, even though I would be unable to come up with a perfect alternative.
Thanks for the update! Few questions and feedback:
Can there be multiple guardians?
Can the guardian role be a smart contract?
The guardian role is quite interesting. I think we can even make it more permission-less by opening it to all to make the system more secure. For example: anyone can stake $YFI to be a guardian. If they saved a strategy from a disaster, the governance can vote on award the guardian based on their stake.
Will there be a reserve of “free” assets in each vault? If not, should we consider it as I think it will provide a better user experience for new users.
Let’s add " During Emergency Shutdown, users can withdraw their funds as usual"
The strategies implement harvestTrigger() which can be time-based, expected return-based, gas cost-based. The strategies currently don’t enforce that condition and don’t refund gas, which is refunded later in bulk from treasury vault. Opening up harvest() for calling outside the desired interval can lead to instability in some complex strategies. Refunding gas on harvest can lead to abuse.
1-3. In the specification it’s just an address, it can be anything, and I think we’ll be switching those to automated actors once they are developed. For example, in MakerDAO, a similar role to guardian is emergency shutdown, so I can imagine a contract where users can burn YFI to shut down a vault or something (just for analogy sake, not sure if it’s a good idea).
4. Yes, the suggestion is to keep a buffer not deposited in any strategies which can be freely withdrawn (for example, in YFI treasury vault it will be 100% of the amount) and have more and more punishing withdrawal fees to deter draining multiple layers of strategies at once. The formula could be something like 0.5% * 2^n, where n is strategy layers eaten.
How often can the strategist claim tokens related to performance fees?
There should be a way to enforce a HWM — i.e. prevent the strategist from claiming subsequent rewards on a position that lately lost money until it goes above water again.
I like the idea of “punishing” withdrawals that occur after too short a term, but if we are being honest, most withdraws likely are a result of decreasing yields.
Who is expected to maintain Keepers for a strategy, the Strategist or Governance? When are those funds distributed and how does that affect a strategy’s yield?
Yes, this sounds equally (if not more) complicated.
There’s no perfect solution here, but the idea behind it is that it is a security vulnerability for some class of Strategies (depending on the how harvest() works) to be called too often as well as not often enough, so leaving it unauthenticated could lead to dangerous and wild swings that could lead to heavy losses in some scenarios.
Part of the Strategy API is prototyping methods for signalling that a trigger is necessary in the first place. I’m hoping that these triggers can get reliable/safe enough over time that more complex functionality can be built around them, including an incentivized “censorship resistant” keeper system, which ensures that the updates are triggered at exactly the right times for strategies.
Both the strategist and governance have control over who the keeper is. It starts out as just the strategist, but they could delegate to those operating keeper infrastructure rather easily in case they don’t want to do it themselves. There’s currently no financial incentive for being a keeper, besides gas repayments and whatever other rewards are being offered. This could/should change in the future, but outside of scope here.
They don’t claim directly, but receive shares of the Vault in direct proportion to the performance of their strategy every time it reports a return to the Vault. If it reports no returns, the Strategist earns nothing. The longer they hold their shares in the Vault, the higher their profits should be, so this incentivizes them to optimize strategies for the long term profitability of the Vault.
No, it’s currently a single address. Governance also has the same capabilities as the Guardian (and then some)
Yes. I envisioned it being the current Yearn multisig as a start. It could evolve into a sort of “Guardian DAO” with people specializing guardian scripts for the task, if that seems useful.
This sounds very complex, but certainly likely can be pushed to an external system if it seems useful. I would say this is outside the scope right now
Yes, it will be up to governance what that threshold is, but this is similar to how Vaults work today. It’s a balancing act between lower potential yields and improved UX.
“A User is able to withdraw an amount of their shares above and beyond the “free” deposits that the Vault has not lent out with an additional fee based on the amount withdrawn early from the Vault’s Strategies.”
Clarify what is meant by “early”. Also, provide clarification as to what a “free” asset is and what makes it so.
“Only Governance can approve Strategies be able to interact with Vaults and take on debt.”
This sentence needs commas for clarity.
“Keeper: a bot which maintains the strategy, by ensures it regularly generates returns for the Vault during pre-defined intervals or events”