# Sender transferring GiantMevAndFeesPool tokens can afterward experience pool DOS and orphaning of future rewards

Transferring GiantMevAndFeesPool LP tokens leaves claimed[] stale, causing underflow reverts (pool DOS) and orphaning future ETH rewards.

- Payout: Contest reward
- Severity: high
- Program: Stakehouse Protocol
- Credited: 9svR6w
- Disclosed: 2023-01-20
- Write-up quality: 7/10
- Original: https://github.com/code-423n4/2022-11-stakehouse-findings/issues/178
- Library page: https://bugbountylibrary.com/r/c4%3A2022-11-stakehouse%3AH-12
- Tags: domain:web3 impact:dos impact:funds-loss kind:contest platform:code4rena sev:high tech:evm tech:solidity technique:source-review vuln:accounting-error vuln:dos

**Target:** GiantMevAndFeesPool / SyndicateRewardsProcessor reward accounting
**Root cause:** afterTokenTransfer does not reduce claimed[] on the sender side, so claimed[] can exceed the max claimable for the reduced balance; subtraction in _previewAccumulatedETH/_distributeETHRewardsToUserForToken underflows.
**Steps:**
1. Deposit 8 ETH into giantFeesAndMevPool as user1.
2. Add 2 ETH rewards to manager1 stakingFundsVault; user1 calls `claimRewards(...)` receiving 2 ETH; claimed[user1] = 2 ETH.
3. User1 transfers 4 ETH of lpTokenETH to user2; claimed[user1] stays 2 ETH.
4. Call `previewAccumulatedETH(user1,...)` or `lpTokenETH().transfer(...)` -> reverts on underflow.
5. Add 2 ETH rewards to manager2; user2 claims 1 ETH; user1's previewAccumulatedETH returns 0 despite owing 1 ETH -> rewards orphaned (totalRewardsReceived 4, totalClaimed 3).
**How found:** Code reading of afterTokenTransfer in GiantMevAndFeesPool: noticed claimed[] is not adjusted on the from side, then reasoned the stale value exceeds max claimable for the smaller balance, producing underflow in subtraction.
**Exploitation:** Any LP holder who claims then transfers tokens bricks their own reward/transfer functions via underflow; subsequent rewards attributable to their remaining shares become unclaimable and stranded in the pool.
**Insight:** In share-based reward accounting, any hook that changes balances (transfer, burn, migrate) must reconcile per-user claimed accumulators; check the from-side of afterTokenTransfer for stale accounting that can exceed the new entitlement.