# Rewards distribution can be disrupted by a early user

First depositor wraps 1 wei, inflating reward_integral past uint128 max via large reward_token transfer, bricking reward distribution.

- Payout: Audit contest
- Severity: medium
- Program: Yield
- Found by: WatchPug
- Disclosed: 2022-03-04
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2022-01-yield-findings/issues/116
- Library page: https://bugbountylibrary.com/r/c4%3A2022-01-yield%3AM-02
- Tags: domain:web3 impact:dos kind:contest platform:code4rena sev:medium tech:evm tech:solidity technique:source-review vuln:accounting-error vuln:dos

**Target:** ConvexStakingWrapper reward accounting (_calcRewardIntegral)
**Root cause:** reward_integral is stored as uint128 but computed as (bal - rewardRemaining)*1e20/_supply; with _supply==1 a large reward_token balance makes the quotient exceed type(uint128).max, overflowing the cast.
**Steps:**
1. Be the first user; wrap just `1` wei of convexToken so `_supply == 1`.
2. Transfer `5e18` of reward_token directly to the contract.
3. Trigger `_calcRewardIntegral`; `(bal - rewardRemaining)*1e20/_supply` exceeds `type(uint128).max`.
4. uint128 cast overflows, corrupting reward_integral and disrupting rewards distribution.
**How found:** Code review of _calcRewardIntegral: noticed reward_integral is uint128 while the integral formula divides by _supply, and reasoned that a minimal first deposit makes _supply==1, amplifying the quotient enough to overflow.
**Exploitation:** Griefer sacrifices the transferred reward tokens to permanently brick reward accounting for all subsequent stakers; no direct theft, only DoS at griefer's cost.
**Insight:** When an accumulator divides by total supply, check the first-depositor case where supply==1 and whether the stored type (uint128) can hold the resulting scaled value; a griefer can donate tokens to force overflow.