Yearn.Finance Security Review


Quantstamp completed its informal code review of Yearn Finance. Yearn Finance provides yield-maximizing opportunities for liquidity providers, and is intended to be governed in a decentralized manner. Due to the large number of contracts involved in the yEarn system, we limited our review to the most prominent contracts—those that hold funds or can distribute funds. We performed this review as a service to the community. Findings are divided by contract below.

Acknowledgements: We want to especially thank Devops199fan, Klim K, Angel, Michael Egorov, Samczsun, vasiliy, Will Price, Cooper Turley, Damir Bandalo and others in the community for reaching out, walking through the code, and gathering needed documentation, as well as Andre Cronje for creating this grand experiment in decentralization. We are looking forward to seeing how this develops.

We hope this is useful documentation to community members that seek to understand and improve yearn. We understand yearn is a work in progress undergoing rapid iteration, and so is this review, we hope it is helpful.


For the better-rendered version of the report:

The code base for this review was relatively challenging due to the following reasons:

  • The files contain very few code comments and there was no technical specification available other than posts on Medium or other websites.
  • The Solidity files were flattened by default, and each of them therefore has a copy of common contracts such as SafeMath, ERC20, etc. However, it is not trivial to compute a diff of all of these files with the standard implementations of SafeMath, ERC20, etc., because the files may use different versions of these standard contracts and in some places code comments were stripped out, but not always and not all comments. This means that there could be a small change in one of these standard contracts that could represent a vulnerability.
  • The code base did not have any unit-, integration- or e2e-tests. This is worrying because we have seen vulnerabilities in many projects which do not have tests, especially in edge cases, which do not occur on the “happy” code-paths.
  • There were instances where privileged roles were used to manually distribute protocol fees.

YearnRewards (1st pool) - yCurve LP tokens

The yearn pool stakes yCRV tokens from the Y pool on Curve Finance. The Y pool performs automatic yield-hunting for liquidity providers. It switches liquidity between Aave, Compound, and dydx to provide the best yield among these platforms. Users of the yearn pool receive YFI tokens.


This contract is a copy of the Synthetix Unipool contract, which was reviewed by Sigma Prime in Feb 2020. Their report can be found here:

The only difference is that Uniswap V1 token was changed to the yCRV token ( yDAI/yUSDC/yUSDT/yTUSD (yDAI+yUSD…)) 0xdF5e0e81Dff6FAF3A7e52BA697820c5e32D806A8.

This contract does not have any governance logic in it.

YearnRewards (2nd pool) - Balancer BPT tokens

Pool #2 stakes pool tokens received when providing liquidity to a Balancer DAI-YFI pool. YFI is distributed to incentivize DAI-YFI liquidity. Users receive YFI tokens for providing this liquidity.


This contract is a copy of the Synthetix Unipool contract, which was reviewed by Sigma Prime in Feb 2020. Their report can be found here:

The only difference is that Uniswap V1 token was changed to the BPT token 0x60626db611a9957C1ae4Ac5b7eDE69e24A3B76c5.

This contract does not have any governance logic in it.

YearnGovernance (3rd pool) - Balancer BPT tokens

The Governance pool stakes pool tokens received when providing liquidity to a Balancer yCRV-YFI pool. Users receive YFI, and if they stake more than 1000 pool tokens, are eligible to vote on YFI governance proposals.


Owner and Governance are not multisig-wallet

Severity: High

  • [owner] Set the reward distribution address
  • [governance]
    • Transfer any token besides YFI, BPT and the reward token ( feesPaidIn ) to their own address, by calling seize
    • Set the breaker that will block all fee claims when withdrawing, voting and staking, by calling setBreaker
    • Set the reward token address
    • Set the governance address
    • Set the minimum amount needed for proposals
    • Set the number of blocks (period) after a proposal when one can vote
    • Set the amount of time the vote is locked

The RewardDistribution address decides what reward will be given for the next 7 days, not the governance address

Severity: Medium

The rewardDistribution address is not public and therefore its value cannot be read directly from the smart contract. However, looking at the transaction history of the smart contract it is visible that the rewardDistribution address was set in the 3rd transaction ever to be executed on this contract: Ethereum Transaction Hash (Txhash) Details | Etherscan and it was set to the address controlled by Andre, namely 0x2d407ddb06311396fe14d4b49da5f0471447d45c . The rewardDistribution address is the only address that is allowed to call the notifyRewardAmount function, which can set the following state variables:

  1. rewardRate
  2. lastUpdateTime
  3. periodFinish , which is 7 days from the time when this function is called

This notifyRewardAmount function was called on July 19th at 03:38:14 PM +UTC in this transaction Ethereum Transaction Hash (Txhash) Details | Etherscan with the reward parameter set to 10,000 YFI . This means that the periodFinish will be on July 26 at 03:38 PM +UTC. At this point in time the:

  • lastTimeRewardApplicable function will always return the periodFinish date, which will lead the (see next bullet)
  • rewardPerToken function to stop increasing the reward.

Voting ‘period’ and ‘lock’ values may differ

Severity: Medium

By default the period and lock state variables in the YearnGovernance contract have the same value of 17280 blocks (approximately 3 days), which is not a problem. However, the governance address can change these values independently such that they differ. If period “> lock then stakers are allowed to withdraw their stake after lock blocks, then they can re-stake the same amount and double their votes for the same proposal. Here are the steps to execute this attack:

  1. Prerequisite: Governance address sets the period = 18000 and leaves lock = 17280 .
  2. Alice creates a proposal (having a voting period = 18000)
  3. Bob, who already has a stake of 100, places his vote. His tokens are locked for 17280 blocks.
  4. After 17280 blocks, Bob’s tokens are unlocked and he withdraws them.
  5. Using a different address Bob places another stake using the same 100 tokens. Bob is now allowed to vote on Alice’s proposal again, which increases his vote count to 200 and locks his tokens for 17280 blocks.

Recommendation: Merge the lock variable with the period variable. It’s not clear why and if they will ever have different values.

A user can vote"For" and “Against” on the same proposal simultaneously

Severity: Medium

Community member Klim has brought up that a user can vote for and against simultaneously. We located the code segments in YearnGovernance , voteFor() and voteAgainst() functions and have confirmed the issue. While the functions check that if the user has voted for the sameposition before and accounts for the votes, they do not check if a user’s vote has been accounted for the other stance and thus allows double voting. The issue is present in both functions.

Recommendation: We recommend adding a requirement statement and only allow the user to vote for one given stance.

YearnFeeRewards (4th pool) - stakes YFI for % of protocol fees

The Fee Rewards pool allows users who have staked more than 1000 pool tokens in Pool #3 and also voted on a proposal to stake their YFI. By staking YFI, they receive rewards in the form of yCRV tokens.


Owner and Governance are not multisig-wallet

Severity: Medium

Description: Similarly to pool 3 above, the current owner and governance addresses are set to 0x2d407ddb06311396fe14d4b49da5f0471447d45c . This gives the address power to transfer tokens (other than YFI and yCRV) to itself.

Users have to voteLock recently to claim rewards

Severity: Informational

The getReward() function requires the user to have a certain amount of yGov staked balance and have been active in governance, i.e. to have voted recently at the time they are claiming the reward. This requirement is identical as the ones in the stake() function, however, it is unclear whether this is intended as it is not documented or communicated openly. Recommendation: confirm if this is the intended behavior of the function and document the rationale to inform the users.

YFI Contract


The governance address can add any address as a minter. That minter can mint tokens arbitrarily as there is no cap.

Recommendation: Cap value for minting should be decided by governance.



YFI Tokens can be seized by the governance (yearn:Deployer) address

Severity: Medium

A total of 10.85475338406697 YFI tokens were seized (transferred out the contract) by the yearn:Deployer address (0x2d407ddb06311396fe14d4b49da5f0471447d45c) on the 21st of July 2020, at 12:19 UTC. This happened in 2 consecutive calls to the seize function shown in the 2 transactions below:

  1. Ethereum Transaction Hash (Txhash) Details | Etherscan From RewardsTo yearn: Deployer For 1.085475338406696829 ($2,339.54)
  2. Ethereum Transaction Hash (Txhash) Details | Etherscan From RewardsTo yearn: Deployer For 9.769278045660271461 ($21,055.82)

The entire amount of YFI was then transferred to the DistributeYFI contract located here DistributeYFI | Address 0x812ac0eaeb422efa44eac670aa2246a25ecfa017 | Etherscan

This contract has then distributed this amount non-uniformly in this transaction: Ethereum Transaction Hash (Txhash) Details | Etherscan to 17 addresses as indicated (hardcoded) in the distribute() function of the DistributeYFI contract:

  1. yfi.safeTransfer(0x28b88cfD875C883cDb61938C97B8d1baabf31c88,4084730714199977);
  2. yfi.safeTransfer(0x3F47A66aDA01491c3d364599e5bcBf80A1a67092,1405800000000000000);
  3. yfi.safeTransfer(0x5ade40e345817B739b91c6B4615eFCE87F9D7c57,1000000000000000);
  4. yfi.safeTransfer(0x6c6145d05Cd02B40403fd739f7B9B24fc8d8C410,2000000000000000);
  5. yfi.safeTransfer(0xc7D2fdE79bDAe639115607A5bddd1596058E9c29,100000000000000);
  6. yfi.safeTransfer(0xd6b806f51d41947B6C8465363De90941a81FD8Bd,85800000000000000);
  7. yfi.safeTransfer(0x4A915B337B38f4755b39f2801D4Df2901A1432CD,75500000000000000);
  8. yfi.safeTransfer(0xbA766A08f0a126Ed43B2699F722d2063e5fBb308,4282600000000000000);
  9. yfi.safeTransfer(0x5398850A9399Da87624874704FEAa8A9C6C4089B,10000000000000000);
  10. yfi.safeTransfer(0x93aa8C9A50EFa30Bb28cE0AD12516686c963472a,2416900000000000000);
  11. yfi.safeTransfer(0xf853184415AC2312844E77Cc7BaBda372e8F56aF,257000000000000000);
  12. yfi.safeTransfer(0xd53C9Fedcc95187307908D659846a443cb1e7350,122100000000000000);
  13. yfi.safeTransfer(0xCC1cc238f0D0de0bB82cD1F36Ea988D8EB4489AB,243200000000000000);
  14. yfi.safeTransfer(0xDda8901508211dfd3a2A912fEb0b913a6558c113,1006600000000000000);
  15. yfi.safeTransfer(0x1AE3A0366C8F540C9f31cfC18A23b7E4AC9D4d8D,289700000000000000);
  16. yfi.safeTransfer(0xdA581d5E0c21f59E681ADe7747F477D44e4E6FD4,634668653352768313);
  17. yfi.safeTransfer(0xbff3BdC458D94C9Ca36230bE24838e778305A954,17700000000000000);

These addresses burned these exact amounts of YFI tokens before by calling the claim function of the YearnRewards contract, for which they received aDAI (Aave interest bearing DAI) in exchange. It is not entirely clear why they were given back the YFI tokens later. Those addresses do not seem to have returned the aDAI in this transaction history: Token Transfer | Etherscan

We believe this is related to the fact that some manual operations still need to be performed by the yearn: Deployer admin key.


Severity: Informational


The updateTargetGovernance and updateThisGovernance functions are not access controlled in any way. Anyone can call these functions. The update period is hardcoded to 3 days (17280 blocks) and cannot be updated. The addMinter function cannot be called by TimelockGovernance .

APR oracle


APR calculation sometimes takes 365 days, other times 366

Severity: Informational

Description: For Compound, the contract calculates APR based on a 365-day calendar; for DxDy, it does so using a 366 baseline. Both are approximations, but 365 seems more accurate.

Heavy use of magic numbers

Severity: Informational

Description: The contract makes heavy use of undocumented numerical constants (magic numbers), which requires readers and auditors alike to reverse engineer the underlying context. Examples:

  • In getCompoundAPR : 2102400. After a closer look, it stands for the blocks per year on compound:

  • 1 block per ~ 15sec → 4 blocks per minute

  • 4 blocks per minute → 240 blocks per hour
    5760 blocks per day* 5760 blocks per day → 2102400 blocks per year (365 days)
    The constant 2102400 is then used to calculate Compounds’ APR. Note that results may differ from Compound unless the latter keeps this constant hardcoded in their contracts (currently the case).

  • In getDyDxAPR , 31622400 - stands for the number of seconds in a 366 day year.

No official documentation on DxDy APR calculation

Severity: Low

Description: DxDy does not provide any official documentation on how to calculate the supply APR for an underlying token. The developer of this APR Oracle even acknowledges that—see his Medium post “How we built on-chain APR for Ethereum DeFi”. Thus, it could be the case that the current implementation does not actually match DxDy’s true APR. Nonetheless, the implemented logic seems correct.

Privileged Roles - Key Person Risk

Severity: Medium/High

Description: The contract contains many restricted functions (as they should be); thus, they can only be called by the address who deployed the contract (currently, the oracle address, which is the same as the contract owner: 0x284b672380a4b5e4d7ccfcc0541a1d0a78c37f8c). There is a risk that if its key gets compromised, the entire Oracle becomes unusable as it could be incorrectly configured by means of its set-like functions.

Unused Functions

Severity: Undetermined

Description: The Oracle contains some functions that do not seem to be used anywhere in the given contracts we had access to. However, we cannot claim that these functions are not indeed used (e.g., it could be the case that we did not get all contracts that participate in this platform). Among those functions that are not called, we found functions that change the Oracle’s price for a given token, as well as its liquidity.

No sanity check of input address parameters

Severity: Low

Description: All set-like functions that take a contract address as a parameter do not check if the given address is different from 0x0, nor that it points to a contract. Thus, 0x0 and EOA addresses can be accidentally set.


This informal security review is applicable to the current version of contracts as of July 24, 2020 10PM UTC. Quantstamp is aware of the announcement by on its plan to deploy v2 contracts in the next 3-4 days ( v2. In the next 3~4 days we will be… | by Andre Cronje | Yearn | Medium). The v2 contracts are not yet all available and have not been included as part of this security review.


YearnGovernance (3rd pool) -Owner and Governance are not multisig-wallet
Severity: High

Any comments , guys ?

Hey there, this is Dan on the Communications at Quantstamp.

Our engineering team is sleeping right now so I will do my best to answer.

First of all it should be noted that in a security audit, engineers will always picture the worst case scenario. In addition, vulnerabilities are written to be precisely worded for developers, so may not always be clear for laypeople.

The first point of possible confusion is this line:
“Transfer any token besides YFI, BPT and the reward token ( feesPaidIn ) to their own address, by calling seize”

This may sound quite bad at first but on the plus side this implies YFI, BPT and reward tokens CANNOT be transferred.

What can be transferred here is tokens which are NOT those tokens currently relevant to Yearn. Tokens which are NOT YFI, BPTs or rewards would usually be tokens sent by mistake.

This power could be used maliciously to siphon off those accidentally sent tokens, but in the case of a benevolent owner could be used legitimately to return tokens sent by mistake to the contract, back to the original owner.

The other point to note is that this vulnerability, as I understand it, is mostly a “Centralization of Power” issue. The ability to do those actions listed is still not decentralized.

From a security standpoint audit engineers always assume the worst, and users should strongly consider the possibility that these abilities will be abused.

However in practical reality, almost all “decentralized applications” will start off with some degree of “centralization of power”. This allows parameters to be adjusted or emergency fixes to be made while the application is still in alpha or beta phases.

As the project develops and is more well understood, developers may choose to give up those abilities.


One of the loudest concerns of YFI involves the multisig contract. The original concern was that the original address could print unlimited YFI and then drain the 2 balancer pools. So the multisig was born. More info: YFI Minting Ownership

That YFI minting ownership post clarifies a lot of what has happened but did not clarify some things and hoping to get some opinions from knowledgable experts like Quantstamp

The multisig seems to enable unlimited YFI printing (as the original concern) but after reading the minting ownership post, it seems that the multisig can only activate if there is a passed proposal.

Question: If the activated proposal requests 1000 YFI, this means the multisig can only create the requested amount by the proposal? The multisig cannot create less or more?


I asked our engineers and this is what they had to say

"There is nothing in the code to enforce the 1000 YFI cap mentioned in this question.

However, at the moment the minting feature cannot be called by the governance contract. The governance contract first needs to be updated by the multi-sig owners in order to add a function that can add another address as a minter. Only that address will then be able to mint, but that address would be able to mint as much as it wants"

So it seems to me that there are is an extra barrier to minting currently, but the amount of minting is governed by the social consensus of the multi-sig signers, which presumably follows the on chain voting.

1 Like

Thats what I thought. Thanks Dan! Seems an odd choice to allow minting unlimited tokens behind a multisig if you cant enforce minting limits through code instead of social constructs.