# Unwhitelisting does not clear _arbitrageProfits, so re-whitelisting may result in an unfair distribution of liquidity rewards

Unwhitelisting a token leaves stale _arbitrageProfits; re-whitelisting lets its pools claim outsized liquidity rewards from old profits.

- Payout: Contest reward
- Severity: medium
- Program: Salty.IO
- Credited: klau5
- Disclosed: 2024-04-19
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2024-01-salty-findings/issues/752
- Library page: https://bugbountylibrary.com/r/c4%3A2024-01-salty%3AM-10
- Tags: domain:web3 impact:funds-loss kind:contest platform:code4rena sev:medium tech:solidity technique:incomplete-fix technique:source-review vuln:business-logic vuln:reward-distribution

**Target:** DAO/PoolStats liquidity rewards accounting
**Root cause:** clearProfitsForPools only iterates currently whitelisted pools, so unwhitelisted pools retain _arbitrageProfits; re-whitelisting reuses stale profit values in reward distribution.
**Steps:**
1. Whitelist tokens A and B; add A/WETH, A/WBTC, B/WETH, B/WBTC, WETH/WBTC liquidity.
2. Generate arbitrage profits in A/WETH and B/WETH pools via swaps.
3. Unwhitelist token B without settling rewards; call `pools.clearProfitsForPools()` — B pools' `_arbitrageProfits` remain.
4. Re-whitelist token B; call `pools.profitsForWhitelistedPools()` and observe B pools still report old profits.
5. New arbitrage in A/WBTC yields skewed reward ratio (e.g. 1:1:10:10:11) favoring B pools.
**How found:** Code reading of clearProfitsForPools and profitsForWhitelistedPools: noticed both iterate only whitelistedPools(), so unwhitelisted pools' _arbitrageProfits are never zeroed.
**Exploitation:** Attacker holding liquidity in a to-be-re-whitelisted pool waits for unwhitelist/re-whitelist cycle; stale _arbitrageProfits inflate that pool's share of liquidity rewards at settlement, diluting honest LPs.
**Insight:** When accounting state is keyed by a mutable whitelist, check whether cleanup loops iterate the current whitelist rather than all known keys — removed entries silently retain stale balances that resurface on re-addition.