# First depositor can break staking-rewards accounting

First depositor inflates rewards/shares ratio, causing uint128 overflow in virtual rewards and breaking staking accounting so claims revert.

- Payout: Contest reward
- Severity: high
- Program: Salty.IO
- Credited: 0xRobocop
- Disclosed: 2024-04-19
- Write-up quality: 7/10
- Original: https://github.com/code-423n4/2024-01-salty-findings/issues/341
- Library page: https://bugbountylibrary.com/r/c4%3A2024-01-salty%3AH-04
- Tags: domain:web3 impact:dos impact:funds-loss kind:contest platform:code4rena sev:high technique:source-review vuln:business-logic vuln:precision-loss vuln:share-inflation

**Target:** StakingRewards contract
**Root cause:** virtualRewardsToAdd computed as ceilDiv(totalRewards * increaseShareAmount, existingTotalShares) can exceed uint128 when first depositor donates SALT to inflate totalRewards relative to shares; cast to uint128 truncates.
**Steps:**
1. Alice (first depositor) adds minimal liquidity to a pool, receiving 202 shares.
2. Alice calls `addSALTRewards` with 100e18 SALT for the pool, setting totalRewards high relative to shares.
3. Bob deposits 100e8 tokens, receiving 200e18 shares; virtualRewardsToAdd = ceilDiv(100e18 * 200e18, 202) overflows uint128.
4. Charlie deposits 10000e8 tokens, receiving 20000e18 shares; further overflow.
5. Sum of claimable rewards exceeds contract SALT balance; `claimAllRewards` reverts with 'ERC20: transfer amount exceeds balance'.
**How found:** Code review of StakingRewards.sol identified that virtualRewardsToAdd uses ceilDiv with totalRewards and existingTotalShares, and that the result is cast to uint128; recognized first-depositor donation can inflate ratio beyond uint128 max.
**Exploitation:** Attacker becomes first depositor, donates SALT to inflate rewards/shares ratio, then subsequent depositors trigger uint128 overflow in virtual rewards accounting, bricking reward claims and locking funds.
**Insight:** When a contract simulates virtual rewards via a ratio and stores in uint128, check if an attacker can inflate the numerator (e.g., by direct token donation) to cause overflow; first-depositor share inflation attacks extend beyond ERC4626 to reward accounting.