# Reward token not correctly recovered

Streaming.recoverTokens computes excess reward balance using a monotonically increasing rewardTokenAmount that never decreases on claims, so excess underflows and stuck reward tokens cannot be recovered.

- Payout: Audit contest
- Severity: high
- Program: Streaming Protocol
- Found by: cmichel
- Disclosed: 2022-02-11
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2021-11-streaming-findings/issues/214
- Library page: https://bugbountylibrary.com/r/c4%3A2021-11-streaming%3AH-03
- Tags: area:web3 domain:web3 impact:funds-loss kind:contest platform:code4rena sev:high tech:solidity technique:source-review vuln:accounting-error

**Target:** Solidity Streaming contract recoverTokens/claimReward accounting
**Root cause:** rewardTokenAmount is incremented in fundStream but never decremented when claimReward transfers reward tokens out, so balanceOf - (rewardTokenAmount + fee) underflows or yields zero excess.
**Steps:**
1. fundStream(1000) sets rewardTokenAmount = 1000
2. Wait until block.timestamp > endRewardLock
3. User calls claimReward() receiving 1000 tokens; contract balance = 0, rewardTokenAmount still 1000
4. Send 1000 reward tokens to contract
5. Call recoverTokens(rewardToken, recipient): excess = 1000 - 1000 = 0, nothing recoverable
**How found:** Code reading of recoverTokens: noticed rewardTokenAmount only increases in fundStream and is never decreased in claimReward despite tokens leaving the contract, making the excess formula inconsistent with actual balance.
**Exploitation:** No attacker profit; the flaw prevents recovery of accidentally sent reward tokens, effectively locking them in the contract.
**Insight:** When auditing 'recover excess' functions, verify the tracked accounting variable is decremented on every outflow path (claims/withdrawals), not just incremented on inflows; a monotonic counter in a balance-difference formula is a red flag.