# Reward token in the killed gauge may be stolen

Killed Silo gauge stops receiving balance-change hooks, letting a late depositor claim rewards accrued for existing depositors.

- Payout: Contest reward
- Severity: medium
- Program: Silo
- Credited: 0x37
- Disclosed: 2025-03-19
- Write-up quality: 6/10
- Original: https://cdn.cantina.xyz/reports/cantina_competition_silo.pdf#3.2.7
- Library page: https://bugbountylibrary.com/r/cantina%3Asilo%3A3.2.7
- Tags: domain:web3 impact:funds-loss kind:contest platform:cantina sev:medium tech:solidity technique:source-review vuln:business-logic vuln:reward-distribution

**Target:** SiloIncentivesController / gauge hook receiver
**Root cause:** afterAction returns early when the gauge is killed, so user balances are never re-accrued; _accrueRewardsForPrograms then uses the stale index against the new share balance.
**Steps:**
1. Create incentives program with emissionPerSecond and distributionEnd
2. user1 deposits 100e18; hook accrues rewards
3. warp past distributionEnd and kill the gauge via hookMockKillGauge
4. user2 deposits 100e18 after kill; no afterTokenTransfer hook fires
5. user2 calls `_controller.claimRewards(user2)` and receives rewards accrued for user1's stake
**How found:** Noticed the `if (theGauge.is_killed()) return;` early-exit in afterAction means balance changes post-kill are invisible to the gauge, then reasoned the index-diff reward math would misattribute rewards to new shares.
**Exploitation:** Attacker waits for gauge kill, deposits shares so the stale reward index is applied to a fresh balance, then claims rewards directly from the controller, diluting honest depositors' accrued incentives.
**Insight:** When a hook receiver silently no-ops on a state flag (killed/paused), check whether reward accounting depends on that hook firing — stale index vs fresh balance is the exploitable gap.