Ch_301 - users will steal/lose some CRV rewards from `WCurveGauge.sol`

[sherlock-admin]

Ch_301

high

users will steal/lose some CRV rewards from WCurveGauge.sol

Summary

from Curve Docs

The weight system
Each gauge also has a weight and a type. Those weights represent how much of the daily CRV inflation will be received by the liquidity gauge.

WCurveGauge.sol have this logic to mint CRV reward for curve gauge and update the tracking system for reward

    function _mintCrv(ILiquidityGauge gauge, uint256 gid) internal {
        uint256 balanceBefore = CRV.balanceOf(address(this));
        ILiquidityGaugeMinter(gauge.minter()).mint(address(gauge));
        uint256 balanceAfter = CRV.balanceOf(address(this));
        uint256 gain = balanceAfter - balanceBefore;
        uint256 supply = gauge.balanceOf(address(this));
        if (gain > 0 && supply > 0) {
            accCrvPerShares[gid] += (gain * 1e18) / supply;
        }
    }

Vulnerability Detail

On this POC I will take as an assumption the gauge has a constant weight to simplify the computation. This is the constant weight: If you deposit in the gaugeX 10 LP tokens you will receive 2 CRV every week (so if you deposit 20 LP tokens you will receive 4 CRV every week).

THE TIMELINE STARTS HERE Day_one:

• user_01 deposit in the gaugeX 10 LP tokens
• the gain of this week = 0 CRV
• total supply of CRV is 0 (in WCurveGauge)
• accCrvPerShares [ GaugeX_ID ] == 0

After_One_Week:

• user_02 deposit in the gauge X 20 LP tokens
• the gain of this week = 2 CRV
• total supply of CRV is 2 (these 2 CRV are only for user_01)
• accCrvPerShares [ GaugeX_ID ] == 1 (the 1 comes from (gain / supply) + old value so (2 / 2) + 0 =1)

After_One_Week:

• user_03 deposit in the gauge X 10 LP tokens
• the gain of this week = 6 CRV (2 + 4)
• total supply of CRV is 8 ( 4 CRV for user_01 and 4 CRV for user_02)
• accCrvPerShares [ GaugeX_ID ] == 1.75 (6 / 8) + 1 =1.75)

After_One_Week: if any user decides to close his position we should have these results

• the gain of this week = 8 CRV (2 + 4 + 2)
• total supply of CRV is 16 ( 6 CRV for user_01, 8 CRV for user_02 and 2 CRV for user_03 )
• accCrvPerShares [ GaugeX_ID ] == 2.25 (6 / 8) + 1.75 =2.25) user_01 deposit 10 LP tokens for 3 weeks ==> 2 CRV 3 weeks = 6 CRV user_02 deposit 20 LP tokens for 2 weeks ==> 4 CRV 2 weeks = 8 CRV user_03 deposit 10 LP tokens for 1 week ==> 2 CRV * 1 week = 2 CRV

THE END OF THE TIMELINE

Let's take user_01 as an example: (POC) user_01 invoke burn() this logic will calculate the rewards

        uint256 stCrv = (stCrvPerShare * amount) / 1e18;
        uint256 enCrv = (accCrvPerShares[gid] * amount) / 1e18;
        if (enCrv > stCrv) {
            rewards = enCrv - stCrv;
            CRV.safeTransfer(msg.sender, rewards);
        }

we have: (ignore 1e18 ) stCrv = 0 10 = 0 enCrv = 2.25 10 = 22.5 (we only have 16 CRV in this contract) so enCrv > stCrv ==> 22.5 > 0 == true rewards = enCrv - stCrv ==> 22.5 - 0 = 22.5 so rewards is 22.5 CRV this amount is not even here

You can do different scenarios with all the users and some of them end up stealing rewards (e.g:user_03 will receive 5 CRV so he gets an extra 3 CRV)

Impact

users will steal/lose some rewards from WCurveGauge.sol

Code Snippet

Tool used

Manual Review

Recommendation

Update this part

        if (gain > 0 && supply > 0) {
            accCrvPerShares[gid] += (gain * 1e18) / supply;
        }

from _mintCrv()

[Ch-301]

Escalate for 10 USDC

The POC above shows exactly how this part of the logic

        if (gain > 0 && supply > 0) {
            accCrvPerShares[gid] += (gain * 1e18) / supply;
        }

failed to calculate the correct value of accCrvPerShares[gid]

[sherlock-admin]

Escalate for 10 USDC

The POC above shows exactly how this part of the logic

        if (gain > 0 && supply > 0) {
            accCrvPerShares[gid] += (gain * 1e18) / supply;
        }

failed to calculate the correct value of accCrvPerShares[gid]

You've created a valid escalation for 10 USDC!

To remove the escalation from consideration: Delete your comment.

You may delete or edit your escalation comment anytime before the 48-hour escalation window closes. After that, the escalation becomes final.

[hrishibhat]

Escalation rejected

Invalid issue The example above uses the total supply of CRV but the code is using the total supply of the LP deposited into the gauge, not CRV.

[sherlock-admin]

Escalation rejected

Invalid issue The example above uses the total supply of CRV but the code is using the total supply of the LP deposited into the gauge, not CRV.

This issue's escalations have been rejected!

Watsons who escalated this issue will have their escalation amount deducted from their next payout.