# Update to `managerFeeBPS` applied to pending tokens yet to be claimed

Manager can raise managerFeeBPS before fee collection, retroactively taking up to 100% of pending UniV3 fees owed to stakers.

- Payout: Contest reward
- Severity: medium
- Program: Arrakis
- Credited: 0xDjango
- Disclosed: 2023-06-05
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2023-06-arrakis-judging/issues/198
- Library page: https://bugbountylibrary.com/r/sherlock%3A2023-06-arrakis%3AM-5
- Tags: domain:web3 impact:funds-loss kind:contest platform:sherlock sev:medium tech:evm tech:solidity technique:source-review vuln:accounting-error vuln:business-logic

**Target:** ArrakisV2 vault contract (setManagerFeeBPS / _applyFees)
**Root cause:** managerFeeBPS is applied at collection time to all pending fees rather than being checkpointed when the fee is earned, so a later rate change applies retroactively to unclaimed fees.
**Steps:**
1. Manager calls `setManagerFeeBPS(10000)` (max allowed, 100%).
2. UniV3 fees are collected via `burn()` or `rebalance()`.
3. `_applyFees` computes `managerBalance0 += fee0_ * managerFeeBPS / 10000`, crediting 100% of pending fees to manager.
4. Stakers receive nothing from fees accrued before the rate change.
**How found:** Code reading of _applyFees and setManagerFeeBPS: noticed fee rate is read at collection time with no checkpoint, so pending fees are exposed to retroactive rate changes.
**Exploitation:** Manager (privileged or compromised) front-runs fee collection by setting managerFeeBPS to 10000, then triggers burn/rebalance so _applyFees diverts all pending UniV3 fees to managerBalance, extracting value owed to LPs/stakers.
**Insight:** For any fee/rate parameter applied lazily at collection, check whether changing the parameter retroactively affects already-accrued but unclaimed amounts; the fix is to checkpoint/collect before mutating the rate.