# Rewards squatting - setting rewards in different ERC20 tokens opens various economic attacks.

Changing the rewards token lets users front-run setRewards to claim old valuable tokens or roll accrued rewards into a more valuable new token, squatting rewards.

- Payout: Audit contest
- Severity: medium
- Program: Yield
- Found by: moose-code
- Disclosed: 2021-09-17
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2021-08-yield-findings/issues/64
- Library page: https://bugbountylibrary.com/r/c4%3A2021-08-yield%3AM-03
- Tags: area:web3 domain:web3 impact:funds-loss kind:contest platform:code4rena sev:medium tech:solidity technique:race-window vuln:business-logic vuln:reward-distribution

**Target:** rewards token contract (setRewards / claim)
**Root cause:** Accrued rewards are denominated in whatever token is currently set, so switching the rewards token retroactively revalues all users' unclaimed balances; no per-cycle accounting exists.
**Steps:**
1. Monitor mempool for `setRewards(tokenB)` transactions.
2. If tokenB is less valuable than current tokenA, front-run with `claim()` to lock in tokenA rewards.
3. If tokenB is more valuable, do nothing so accrued tokenA balance rolls into tokenB rewards.
4. Result: users squat on rewards, forcing new reward tokens to always be less valuable than prior ones.
**How found:** Reading the rewards contract, noticed claim lets users choose current vs future reward token and reasoned about mempool front-running of setRewards and the economic incentive to squat.
**Exploitation:** Attacker watches mempool for setRewards; front-runs with claim when the new token is cheaper, or passively holds when the new token is more valuable, extracting value from the reward pool at other users' expense.
**Insight:** When a config setter (setRewards) retroactively revalues user balances, treat the setter as a front-runnable event and check whether users can choose which denomination their accrued balance settles in.