# Aura/Convex rewards are stuck after DOS

Anyone can call Convex getReward for Tokemak, pre-claiming rewards so balanceBefore/After accounting records zero, leaving rewards stuck in LiquidationRow.

- Payout: Contest reward
- Severity: high
- Program: Tokemak
- Credited: 0x007
- Disclosed: 2023-06-30
- Write-up quality: 7/10
- Original: https://github.com/sherlock-audit/2023-06-tokemak-judging/issues/738
- Library page: https://bugbountylibrary.com/r/sherlock%3A2023-06-tokemak%3AH-16
- Tags: domain:web3 impact:dos kind:contest platform:sherlock sev:high tech:evm tech:solidity technique:source-review vuln:accounting-error vuln:dos vuln:reward-distribution

**Target:** ConvexRewardsAdapter / LiquidationRow reward claiming
**Root cause:** _claimRewards measures claimed amounts via balanceBefore/After deltas, but Convex getReward is permissionless, so an attacker can transfer rewards to the contract before the claim, making the delta zero.
**Steps:**
1. Attacker calls Convex BaseRewardPool.getReward(tokemakLiquidationRow, true) for the Tokemak account
2. Reward tokens are transferred to Tokemak contract without accounting hook
3. Tokemak later calls claimRewards; balancesBefore already includes the tokens, so amountsClaimed[i] = 0
4. No transfer to sendTo occurs; rewards remain stuck in LiquidationRow and are never queued to MainRewarder
**How found:** Noticed Convex getReward is callable by anyone for any account, then observed _claimRewards relies on balanceBefore/After deltas which an external pre-transfer invalidates.
**Exploitation:** Attacker permissionlessly triggers Convex getReward for the Tokemak contract address, front-running Tokemak's own claim so the balance-delta accounting reads zero and rewards are stranded in LiquidationRow, denying reward distribution to stakers.
**Insight:** When a reward/claim adapter measures amounts via balance deltas, check whether the underlying reward contract lets third parties trigger the payout for your address — permissionless claim functions break delta-based accounting.