# Reward tokens can never be added again once they are removed without breaking rewards completely

Removing then re-adding a reward token in Olympus SingleSidedLiquidityVault resets global accumulatedRewardsPerShare but not per-user trackers, causing claim underflow.

- Payout: Contest reward
- Severity: medium
- Program: Olympus
- Credited: cccz
- Disclosed: 2023-03-06
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2023-02-olympus-judging/issues/177
- Library page: https://bugbountylibrary.com/r/sherlock%3A2023-02-olympus%3AM-4
- Tags: domain:web3 impact:dos kind:contest platform:sherlock sev:medium tech:solidity technique:incomplete-fix technique:source-review vuln:accounting-error vuln:dos

**Target:** SingleSidedLiquidityVault reward accounting
**Root cause:** Global accumulatedRewardsPerShare lives in the rewardToken struct and is cleared on removal, while per-user accumulatedRewards mapping keyed by token address is not cleared. Re-adding the token resets global to zero but user trackers retain old values.
**Steps:**
1. Deploy/observe SingleSidedLiquidityVault with reward token T; users accrue rewards so user.accumulatedRewards[T] > 0.
2. Admin calls removeRewardToken(T): global rewardToken[T].accumulatedRewardsPerShare cleared, user mapping untouched.
3. Admin calls addRewardToken(T) again: global tracker starts at 0.
4. User calls claimRewards(): reward owed computed from (global - user) underflows, reverting.
**How found:** Code reading of reward accounting: noticed global accumulatedRewardsPerShare stored in rewardToken struct vs per-user mapping keyed by address, and that removal clears only the struct, hypothesizing a reset mismatch on re-add.
**Insight:** When state is tracked in two places (struct array vs address-keyed mapping), audit every add/remove lifecycle for asymmetric clearing; re-adding a previously removed entity is a classic trigger for stale per-user state vs reset global state.