# Internal reward tokens can and likely will over commit rewards

Olympus SingleSidedLiquidityVault internal reward tokens accrue indefinitely with no end timestamp or balance check, over-committing rewards and bricking all claims.

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

**Target:** SingleSidedLiquidityVault reward accounting (Solidity)
**Root cause:** Internal reward tokens are registered with a fixed _rewardPerSecond and no end timestamp, so accrual continues indefinitely regardless of the contract's actual token balance; no check ensures committed rewards are funded.
**Steps:**
1. Add an internal reward token via the add function with a fixed _rewardPerSecond and no end time.
2. Rewards accrue every block indefinitely, exceeding the contract's token balance.
3. Users call claim; the reward transfer reverts once balance is exhausted.
4. Because claim is all-or-nothing across reward tokens, one reverting token blocks claiming of every reward token.
**How found:** Code reading of the internal reward token accrual logic, noticing the absence of an end timestamp and any balance/funding check.
**Escalation:** Single reverting reward token in the all-or-nothing claim loop blocks all reward claims, not just the over-committed one.
**Insight:** When a reward stream has no end time and no funding check, compare total committed emissions against actual token balance; also check whether claim loops are all-or-nothing so one bad token bricks the rest.