yearnyCRV Yearn Boosted Staker Launch: All You Need to Know
All the details you'll need to be fully prepared
yearnUpcoming yPRISMA YBS Staking Launch: All You Need to Know
All the details you'll need to be fully prepared
yearnEverything Must Go
Participating in Yearn Oracle-Free & Permissionless Dutch Auctions for fun and profit
Subscribe to yearn
Share Dialog
Given recent events, seems like it is as good as time as any to explain how Yearn vaults governance and security process works, as well as what can and cannot be changed within a vault and by who.
Long post time.
Whether you are you are a DPRK agent, looking to gain access to funds held within a Yearn vault. Or just a user or protocol wondering what the safety of funds are when deployed to Yearn, it's good to know how exactly the vaults work and what the high risk touch points are.
For starters, Yearn uses no upgradable contracts. It is part of the ethos from the beginning and is something I am confident will never change. Once code is deployed it cannot be changed, for better or worse.
However, that doesn't mean nothing can change in how it operates. As with almost all smart contract systems there are things that can be configured and updated throughout a vaults life, some mundane, some high risk.
This post will focus entirely on the V3 vault system, but most Yearn products work (roughly) the same way.
The Yearn V3 vaults run on a "Role" system. In that each permissioned function has a specific role attached to it. These roles are built using Vyper Enumerators, you can read more about how Vyper Enum's work here: https://medium.com/@de33/enums-in-vyper-0-3-4-6ec2d387bc3a.
TLDR is that any address can hold any combination of roles, meaning the permissions are fully configurable.
While the full setup of how our roles are given out is outside of the scope of this post, as with everything it is fully codified, you can point your clanker at this contract 0xb3bd6B2E61753C311EFbCF0111f75D29706D9a41 and it should be able to explain to you each holder and what roles they are given and what that means.
For the sake of this post though, the most important and most security critical role is the ADD_STRATEGY_MANAGER. For ANY vault provider the highest risk moments in its life is adding a new yield source or strategy.
Unfortunately, many in the industry have chosen cosplay security or restrictions for the things their vaults can and cannot interact with or fund. They will claim some fancy protections held within the vault itself, but in reality the team operating it has effective unilateral control to yeet and update these meaningless restrictions at will, much of the time using arbitrary calldata provided from unknown off chain sources.
Given recent events, seems like it is as good as time as any to explain how Yearn vaults governance and security process works, as well as what can and cannot be changed within a vault and by who.
Long post time.
Whether you are you are a DPRK agent, looking to gain access to funds held within a Yearn vault. Or just a user or protocol wondering what the safety of funds are when deployed to Yearn, it's good to know how exactly the vaults work and what the high risk touch points are.
For starters, Yearn uses no upgradable contracts. It is part of the ethos from the beginning and is something I am confident will never change. Once code is deployed it cannot be changed, for better or worse.
However, that doesn't mean nothing can change in how it operates. As with almost all smart contract systems there are things that can be configured and updated throughout a vaults life, some mundane, some high risk.
This post will focus entirely on the V3 vault system, but most Yearn products work (roughly) the same way.
The Yearn V3 vaults run on a "Role" system. In that each permissioned function has a specific role attached to it. These roles are built using Vyper Enumerators, you can read more about how Vyper Enum's work here: https://medium.com/@de33/enums-in-vyper-0-3-4-6ec2d387bc3a.
TLDR is that any address can hold any combination of roles, meaning the permissions are fully configurable.
While the full setup of how our roles are given out is outside of the scope of this post, as with everything it is fully codified, you can point your clanker at this contract 0xb3bd6B2E61753C311EFbCF0111f75D29706D9a41 and it should be able to explain to you each holder and what roles they are given and what that means.
For the sake of this post though, the most important and most security critical role is the ADD_STRATEGY_MANAGER. For ANY vault provider the highest risk moments in its life is adding a new yield source or strategy.
Unfortunately, many in the industry have chosen cosplay security or restrictions for the things their vaults can and cannot interact with or fund. They will claim some fancy protections held within the vault itself, but in reality the team operating it has effective unilateral control to yeet and update these meaningless restrictions at will, much of the time using arbitrary calldata provided from unknown off chain sources.
Subscribe to yearn
yearnyCRV Yearn Boosted Staker Launch: All You Need to Know
All the details you'll need to be fully prepared
yearnUpcoming yPRISMA YBS Staking Launch: All You Need to Know
All the details you'll need to be fully prepared
yearnEverything Must Go
Participating in Yearn Oracle-Free & Permissionless Dutch Auctions for fun and profit
Share Dialog
So when evaluating the relative security of any vault product, users should ask themselves, how are new yield sources added and funded.
The only way to touch funds held within a Yearn vault is to have a strategy added, so lets go through the process of what it takes to do just that.
Getting a strategy added to a Yearn vault is no easy feat, even after years of being a Yearn strategist, and building the V3 vaults themselves I struggle to get things added. And while this can be frustrating as someone who wants to build and ship things fast, it is for good reason and comes from processes developed and hardened over the course of years and started before I ever showed up.
Step 1 : Code the Son-a-bitch
All new yield sources need to be codified. We have base contracts strategist use to make integrations simpler, but code must be etched in for each allowed interaction with the underlying protocols or yields sources being integrated.
This means not only happy path deposit, withdraw, reward selling reports etc. But also unhappy paths, deposit limits and emergency functions that may be needed in the cycle of a strategies life. Using immutable code for integrations means simplicity during operation and lower maintenance and trust, but also means if something is missed, funds are potentially bricked and there is nothing we can do about it.
Step 2: A jury of your peers
Next, up we have the peer reviews. Once a strategy is built and coded, it must go through the internal security process, the first step is getting two other strategists to peer review it.
This recent post from Tay wasn't lying, the peer review process is at the core of Yearn's security process and shapes the way strategies are built.
This means reviewing the code for obvious things like bugs or missed integration needs, as well as making sure the trust assumptions are up to standards, the setters are appropriately scoped etc. as well as getting multiple other internal people to have at least some hands on experience understanding of how the code works before it ever hits prod.
Step 3 : Stop, Security time.
Once you get a LGTM from your peer review's its time to send the strategy to security. Yearn has always had its own internal security team that has over the years found countless bugs and save untold amounts of money.
Security reviews are less focused on the operational aspects or code choices that peer reviews may be, and as it sounds fully security centric, especially around integration of the underlying protocol. Tapir is our current in house extraordinaire. He also just happens to be one of sherlock's highest rated auditors and has found bugs in many other high profile DeFi projects outside of Yearn. (He's also single for any of the 3 women left in DeFi 😉)
Step 4: Score the Son-a-bitch
Once a strategy has been fully approved for production the choice comes, what vault can it be added to and what amount of debt can it be allocated. This is where our risk reports and analysis come in. There has been much talk lately about getting more robust risk analysis about different protocols especially on factors such as governance controls, multisigs, timelocks etc. Fortunately at Yearn we have been doing this already for years.
Our security team puts together a risk report for any protocol we are planning to integrate that analyses risks such as audits history, operational, liquidity, and of course centralization and control. We have passed up on many protocols in the past that others were touting despite the higher yields due to concerns and issues with managements control of the protocol around things such as upgradability, minter roles etc.
As with everything it is all public for anyone to consume and review for both protocols as well as assets our curation team underwrites at https://curation.yearn.fi/
Based on the underlying protocol and the complexity or risk of the actual strategy itself, each strategy is finally given a risk score that dictates which vaults it can be added to.
Step 5: Monitoring the situation
Risk scores are a key function of any integration, but as we know in DeFi things change, and sometimes very fast. So a purely static report is only worth so much for integrations that are continuous.
Using the risk report that is generated during the review process, the security team will also set up monitoring services for the crucial aspects of any of the underlying protocols we integrate. We have telegram groups constantly alerting us of any parameter changes or non-normal fund movements not just for Yearn but the actual protocols we are deploying funds to as well.
What that means if you run a protocol that Yearn deposits into, just know, were watching you......
Anyways.
So now we have our strategy built, peer reviewed, security reviewed, rated and protocol monitoring setup. How do we get it added and funded?
Step 6: The multisig (da da da dahhhhhhhh).
But worry not, this is no ordinary multisig. I would go on record to say ychad.eth is likely the most secure multisig used by any protocol in DeFi.
It is quite important to understand that not all multisigs are created equal, and the value of it lies within the details of how it works.
Just to get a txn proposed to ychad you need to build it (in code) and get yet one more reviewer's approval to send it through our internal pipeline.
yChad is a 6 of 9. Comprised of almost entirely non-yearn affiliated signers scattered all across the world, many of which are the most trusted longest standing members of DeFi such as 0xngmiI, Michael Egorov, Lefteris and more; all done with public attestations from the signers of their keys and public governance based rotations.
You can view the full signer list and public attestations here: https://docs.yearn.fi/developers/security/multisig
For those that don't remember, back in the day it was quite normal to have DeFi protocols use external signers on many of their higher risk multisigs in order to make sure that even a high threshold could not be circumvented by purely internal actors. Nowadays we have protocols controlling hundreds of millions with 2/n and 3/n multisigs made up of unknown and entirely internal signers, of which I can guarantee you more than a handful are just the same person signing with multiple keys to make it seem more secure than it is.
Step 7: Now, we wait.
Once signed and executed we go to the last step to get a strategy added, the timelock. The only address that can add strategies to a V3 vault is the timelock who has a min delay of another 7 days.
Obviously what good is a timelock if no one is watching it, so we have our own internal monitoring of any txn proposed across every chain deployed on.
Step 8: Wait, we aren't done yet??
Finally, you have waited the week for the timelock. Your strategy can be added! This is the moment a would be attacker would be giddy with joy as they have circumvented the system that even internal strategist struggle to get code through.
But alas, adding a strategy to a vault does not inherently mean that strategy can be funded, and the timelock address itself does not have the authority to move funds within the vault, thereby adding another degree of security separation. We have one more final step which is our operational strategist multisig needs to first execute the timelock txn, and then configure our on chain debt allocator contract who holds the vaults DEBT_MANAGER_ROLE, to actually push funds from the vault into the strategy itself.
huffff
If I am being honest getting strategies through our full system is one of the great burdens of operating at Yearn.
It is one of the reasons from the outside we often appear to be slow or disregard certain opportunities. But is also why we have the best risk management of any vault provider in the industry while also being around the longest.
Immutable code, two peer reviews, one security review, a risk score, monitoring, 9 independent signers across 2 multisigs from people scattered across the globe and a week long timelock is what it takes to get a strategy added to a Yearn vault, and it is EXHAUSTING!!!
But it is non-negotiable. It is what makes Yearn Yearn. And it is why our vaults have been around longer than anyone else and will be here long after many of the new players are gone.
So when evaluating the relative security of any vault product, users should ask themselves, how are new yield sources added and funded.
The only way to touch funds held within a Yearn vault is to have a strategy added, so lets go through the process of what it takes to do just that.
Getting a strategy added to a Yearn vault is no easy feat, even after years of being a Yearn strategist, and building the V3 vaults themselves I struggle to get things added. And while this can be frustrating as someone who wants to build and ship things fast, it is for good reason and comes from processes developed and hardened over the course of years and started before I ever showed up.
Step 1 : Code the Son-a-bitch
All new yield sources need to be codified. We have base contracts strategist use to make integrations simpler, but code must be etched in for each allowed interaction with the underlying protocols or yields sources being integrated.
This means not only happy path deposit, withdraw, reward selling reports etc. But also unhappy paths, deposit limits and emergency functions that may be needed in the cycle of a strategies life. Using immutable code for integrations means simplicity during operation and lower maintenance and trust, but also means if something is missed, funds are potentially bricked and there is nothing we can do about it.
Step 2: A jury of your peers
Next, up we have the peer reviews. Once a strategy is built and coded, it must go through the internal security process, the first step is getting two other strategists to peer review it.
This recent post from Tay wasn't lying, the peer review process is at the core of Yearn's security process and shapes the way strategies are built.
This means reviewing the code for obvious things like bugs or missed integration needs, as well as making sure the trust assumptions are up to standards, the setters are appropriately scoped etc. as well as getting multiple other internal people to have at least some hands on experience understanding of how the code works before it ever hits prod.
Step 3 : Stop, Security time.
Once you get a LGTM from your peer review's its time to send the strategy to security. Yearn has always had its own internal security team that has over the years found countless bugs and save untold amounts of money.
Security reviews are less focused on the operational aspects or code choices that peer reviews may be, and as it sounds fully security centric, especially around integration of the underlying protocol. Tapir is our current in house extraordinaire. He also just happens to be one of sherlock's highest rated auditors and has found bugs in many other high profile DeFi projects outside of Yearn. (He's also single for any of the 3 women left in DeFi 😉)
Step 4: Score the Son-a-bitch
Once a strategy has been fully approved for production the choice comes, what vault can it be added to and what amount of debt can it be allocated. This is where our risk reports and analysis come in. There has been much talk lately about getting more robust risk analysis about different protocols especially on factors such as governance controls, multisigs, timelocks etc. Fortunately at Yearn we have been doing this already for years.
Our security team puts together a risk report for any protocol we are planning to integrate that analyses risks such as audits history, operational, liquidity, and of course centralization and control. We have passed up on many protocols in the past that others were touting despite the higher yields due to concerns and issues with managements control of the protocol around things such as upgradability, minter roles etc.
As with everything it is all public for anyone to consume and review for both protocols as well as assets our curation team underwrites at https://curation.yearn.fi/
Based on the underlying protocol and the complexity or risk of the actual strategy itself, each strategy is finally given a risk score that dictates which vaults it can be added to.
Step 5: Monitoring the situation
Risk scores are a key function of any integration, but as we know in DeFi things change, and sometimes very fast. So a purely static report is only worth so much for integrations that are continuous.
Using the risk report that is generated during the review process, the security team will also set up monitoring services for the crucial aspects of any of the underlying protocols we integrate. We have telegram groups constantly alerting us of any parameter changes or non-normal fund movements not just for Yearn but the actual protocols we are deploying funds to as well.
What that means if you run a protocol that Yearn deposits into, just know, were watching you......
Anyways.
So now we have our strategy built, peer reviewed, security reviewed, rated and protocol monitoring setup. How do we get it added and funded?
Step 6: The multisig (da da da dahhhhhhhh).
But worry not, this is no ordinary multisig. I would go on record to say ychad.eth is likely the most secure multisig used by any protocol in DeFi.
It is quite important to understand that not all multisigs are created equal, and the value of it lies within the details of how it works.
Just to get a txn proposed to ychad you need to build it (in code) and get yet one more reviewer's approval to send it through our internal pipeline.
yChad is a 6 of 9. Comprised of almost entirely non-yearn affiliated signers scattered all across the world, many of which are the most trusted longest standing members of DeFi such as 0xngmiI, Michael Egorov, Lefteris and more; all done with public attestations from the signers of their keys and public governance based rotations.
You can view the full signer list and public attestations here: https://docs.yearn.fi/developers/security/multisig
For those that don't remember, back in the day it was quite normal to have DeFi protocols use external signers on many of their higher risk multisigs in order to make sure that even a high threshold could not be circumvented by purely internal actors. Nowadays we have protocols controlling hundreds of millions with 2/n and 3/n multisigs made up of unknown and entirely internal signers, of which I can guarantee you more than a handful are just the same person signing with multiple keys to make it seem more secure than it is.
Step 7: Now, we wait.
Once signed and executed we go to the last step to get a strategy added, the timelock. The only address that can add strategies to a V3 vault is the timelock who has a min delay of another 7 days.
Obviously what good is a timelock if no one is watching it, so we have our own internal monitoring of any txn proposed across every chain deployed on.
Step 8: Wait, we aren't done yet??
Finally, you have waited the week for the timelock. Your strategy can be added! This is the moment a would be attacker would be giddy with joy as they have circumvented the system that even internal strategist struggle to get code through.
But alas, adding a strategy to a vault does not inherently mean that strategy can be funded, and the timelock address itself does not have the authority to move funds within the vault, thereby adding another degree of security separation. We have one more final step which is our operational strategist multisig needs to first execute the timelock txn, and then configure our on chain debt allocator contract who holds the vaults DEBT_MANAGER_ROLE, to actually push funds from the vault into the strategy itself.
huffff
If I am being honest getting strategies through our full system is one of the great burdens of operating at Yearn.
It is one of the reasons from the outside we often appear to be slow or disregard certain opportunities. But is also why we have the best risk management of any vault provider in the industry while also being around the longest.
Immutable code, two peer reviews, one security review, a risk score, monitoring, 9 independent signers across 2 multisigs from people scattered across the globe and a week long timelock is what it takes to get a strategy added to a Yearn vault, and it is EXHAUSTING!!!
But it is non-negotiable. It is what makes Yearn Yearn. And it is why our vaults have been around longer than anyone else and will be here long after many of the new players are gone.
Schlag
Schlag
>2.7K subscribers
>2.7K subscribers
No activity yet