# Lost rewards when the supply is `0`, which always happens if the rewards are queued before anyone has `StakeTracker` tokens

MasterChef-style rewarder advances lastUpdateBlock while totalSupply is 0, so rewards queued before first deposit are permanently stranded.

- Payout: Contest reward
- Severity: medium
- Program: Tokemak
- Credited: 0x73696d616f
- Disclosed: 2023-06-30
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2023-06-tokemak-judging/issues/387
- Library page: https://bugbountylibrary.com/r/sherlock%3A2023-06-tokemak%3AM-2
- Tags: domain:web3 impact:funds-loss kind:contest platform:sherlock sev:medium tech:solidity technique:source-review vuln:accounting-error vuln:reward-distribution

**Target:** AbstractRewarder / MainRewarder / ExtraRewarder reward accounting
**Root cause:** rewardPerToken() returns stored value unchanged when totalSupply()==0, but lastUpdateBlock is still advanced, so the elapsed interval's rewards are never accrued to anyone.
**Steps:**
1. Queue rewards via `queueNewRewards(newRewards)` while `totalSupply()==0` (before any DestinationVault/LMPVault deposit).
2. Observe `rewardPerToken()` returns `rewardPerTokenStored` unchanged because `total == 0`.
3. Note `lastUpdateBlock` is updated to current block, skipping the interval.
4. Later depositors stake; the rewards emitted during the zero-supply window are never distributed and remain stuck in MainRewarder/ExtraRewarder.
**How found:** Code review of MasterChef-style reward accounting: noticed the totalSupply()==0 early-return preserves rewardPerTokenStored while lastUpdateBlock still advances, creating an unaccounted interval.
**Insight:** In MasterChef forks, check that the zero-supply early-return also freezes lastUpdateBlock (or blocks queueing); otherwise any reward emission during an empty-supply window is silently burned.