Full Report
Yearn is a decentralized suite of products for managing yield of digital assets. The Yearn system was using Curve creation called veCRV (vote-escrowed CRV). Users will lock their tokens away for an extended period of time. As the balance decays of veCRV, the relative voting power for the system does as well. Yearn comes into play here with BribeV2. The idea was to incentivize veCRV voters to make their votes to increase the emissions of CRV. A user could post their tokens into BribeV2 and the contract calculates how much relative voting power they should have. It should be noted that the gauge weights are determined by their veCRV balance instead of the users locked amount. While viewing the SPELL bribes, the authors of Yearn noticed an irregularity. While calculating the amount of control of the system, Yearn was using the slope value instead of the bias value. The slope value is the veCRV is the decay rate per second of their locked amount without their lock duration. This is terrible, because a user would get paid out an equal rate compared to somebody who has locked their tokens away for a long time. Because CRV can be withdrawn after a week, an attacker can cycle the same CRV through multiple wallets to perform the attacks mentioned above. Yikes! How did the devs miss something this bad? Interesting finding none-the-less.
Analysis Summary
# Vulnerability: Miscalculation of Voter Power in Yearn BribeV2 via incorrect veCRV Metric
## CVE Details
- **CVE ID**: N/A (DeFi protocols often lack formal CVE assignments; tracking via Yearn Disclosure 2022-11-01)
- **CVSS Score**: Estimated 8.1 (High)
- **CWE**: CWE-682 (Incorrect Calculation)
## Affected Systems
- **Products**: Yearn Finance BribeV2 Contract
- **Versions**: Production versions active prior to November 2022
- **Configurations**: Integration with Curve’s `veCRV` (vote-escrowed CRV) mechanics for incentive distribution.
## Vulnerability Description
The flaw resides in how the `BribeV2` contract calculates a user's relative voting power for distributing rewards (bribes). The contract was designed to reward users based on their `veCRV` balance, which represents a user's "bias" (locked amount adjusted for time decay).
However, the implementation mistakenly utilized the **slope** value rather than the **bias** value. The "slope" in the Curve ecosystem represents the constant rate of decay per second of a locked position, regardless of the remaining lock duration. Consequently, the contract treated a user who locked tokens for only one week as having the same weight/earning power as a user who locked tokens for four years, provided their initial deposit amounts were identical.
## Exploitation
- **Status**: Discovered by Yearn developers during internal monitoring (SPELL bribe analysis); no public exploitation reported.
- **Complexity**: Low
- **Attack Vector**: Network (Smart Contract Interaction)
- **Details**: Because CRV can be withdrawn after a minimum lock period (e.g., one week), an attacker could cycle the same CRV tokens through multiple wallets. By creating numerous short-term locks, the attacker could capture a disproportionate share of bribes, effectively "sybil attacking" the incentive pool.
## Impact
- **Confidentiality**: None
- **Integrity**: High (Incorrect distribution of financial rewards/assets)
- **Availability**: None
## Remediation
### Patches
- The Yearn team identified the irregularity and updated the reward calculation logic to reference the `bias` (actual `veCRV` balance) rather than the `slope`.
- Users and integrators should ensure they are interacting with the updated bribe contracts deployed post-disclosure.
### Workarounds
- There are no manual workarounds for the faulty contract; the protocol required a migration to a corrected contract deployment.
## Detection
- **Indicators of Compromise**: Disproportionate bribe claims from wallets with high `slope` but low `veCRV` balances; frequent cycling of CRV tokens through fresh addresses with minimum-duration locks.
- **Detection Methods**: Auditing smart contract state for discrepancies between `get_last_user_slope` and `balanceOf` (veCRV) during reward calculation calls.
## References
- Yearn Security Disclosure: hxxps://github[.]com/yearn/yearn-security/blob/master/disclosures/2022-11-01.md
- Curve Finance Documentation (veCRV Mechanics): hxxps://curve[.]readthedocs[.]io/dao-vecrv.html