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.
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 (Curve.fi yDAI/yUSDC/yUSDT/yTUSD (yDAI+yUSD…)) 0xdF5e0e81Dff6FAF3A7e52BA697820c5e32D806A8.
This contract does not have any governance logic in it.
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: https://github.com/sigp/public-audits/blob/master/synthetix/unipool/review.pdf
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.
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] Set the reward distribution address
- Transfer any token besides YFI, BPT and the reward token (
feesPaidIn) to their own address, by calling
- Set the breaker that will block all fee claims when withdrawing, voting and staking, by calling
- 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
- Transfer any token besides YFI, BPT and the reward token (
The RewardDistribution address decides what reward will be given for the next 7 days, not the governance address
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:
periodFinish, which is 7 days from the time when this function is called
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:
lastTimeRewardApplicablefunction will always return the
periodFinishdate, which will lead the (see next bullet)
rewardPerTokenfunction to stop increasing the reward.
By default the
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
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:
- Prerequisite: Governance address sets the
period = 18000and leaves
lock = 17280.
- Alice creates a proposal (having a voting period = 18000)
- Bob, who already has a stake of 100, places his vote. His tokens are locked for 17280 blocks.
- After 17280 blocks, Bob’s tokens are unlocked and he withdraws them.
- 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.
Community member Klim has brought up that a user can vote for and against simultaneously. We located the code segments in
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.
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.
Description: Similarly to pool 3 above, the current
governance addresses are set to
0x2d407ddb06311396fe14d4b49da5f0471447d45c . This gives the address power to transfer tokens (other than YFI and yCRV) to itself.
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.
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.
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:
- Ethereum Transaction Hash (Txhash) Details | Etherscan From Ygov.finance: RewardsTo yearn: Deployer For 1.085475338406696829 ($2,339.54)
- Ethereum Transaction Hash (Txhash) Details | Etherscan From Ygov.finance: 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:
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.
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
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.
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:
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).
getDyDxAPR, 31622400 - stands for the number of seconds in a 366 day year.
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.
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.
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.
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 yearn.finance on its plan to deploy v2 contracts in the next 3-4 days (yearn.finance 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.