# Rewards distribution can be disrupted by a early user

Early depositor with 1 wei of lpToken makes _supply==1, so reward.integral overflows uint128 and disrupts rewards distribution.

- Payout: Audit contest
- Severity: medium
- Program: Concur Finance
- Found by: WatchPug
- Disclosed: 2022-05-24
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2022-02-concur-findings/issues/193
- Library page: https://bugbountylibrary.com/r/c4%3A2022-02-concur%3AM-24
- 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 (Solidity)
**Root cause:** reward.integral is uint128 and computed as (d_reward * 1e20) / _supply; with _supply==1 the scaled value exceeds type(uint128).max and overflows.
**Steps:**
1. Attacker deposits 1 wei of lpToken first so _supply == 1.
2. Attacker transfers ~5e18 reward_token to the contract.
3. On reward update, (d_reward * 1e20) / 1 overflows uint128, corrupting reward.integral.
4. Rewards distribution is disrupted and further deposits are DOSed.
**How found:** Code reading of the integral update formula, noticing uint128 cast and division by _supply that can be 1.
**Exploitation:** Frontrun the pool with a 1 wei deposit to force _supply==1, then donate reward tokens so the integral computation overflows uint128, breaking reward accounting and blocking deposits.
**Insight:** When a share/accumulator is scaled by a large constant and divided by totalSupply, check the minimum-supply case: a 1 wei first deposit can make the numerator overflow the accumulator's integer width.