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
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
The Specification for the proposal is being tracked a Gist to better track any changes made.
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.
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.
“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”