# SetDelegateStakePlacement error is not handled in RewardDelegateStake

RewardDelegateStake ignores SetDelegateStakePlacement error, so RewardDebt isn't persisted and a delegate staker can re-claim the same rewards repeatedly.

- Payout: Contest reward
- Severity: high
- Program: Allora
- Credited: imsrybr0
- Disclosed: 2024-06-24
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2024-06-allora-judging/issues/30
- Library page: https://bugbountylibrary.com/r/sherlock%3A2024-06-allora%3AH-4
- Tags: domain:web3 impact:funds-loss kind:contest platform:sherlock sev:high tech:go technique:source-review vuln:access-control vuln:business-logic vuln:reward-distribution

**Target:** Cosmos SDK module msg server (emissions keeper RewardDelegateStake)
**Root cause:** The return value of SetDelegateStakePlacement is discarded after SendCoinsFromModuleToAccount, so if the state write fails the RewardDebt update is lost while the payout already happened.
**Steps:**
1. Call `MsgRewardDelegateStake` with a topic/reputer where pendingReward > 0.
2. Coins are sent from AlloraPendingRewardForDelegatorAccountName to sender.
3. `SetDelegateStakePlacement` fails (error ignored), leaving RewardDebt unchanged.
4. Repeat the call to claim the same pendingReward again.
**How found:** Code review of RewardDelegateStake noticed the unchecked error return on SetDelegateStakePlacement after the coin transfer, breaking the reward-debt accounting invariant.
**Exploitation:** A delegate staker repeatedly invokes RewardDelegateStake; each call pays out pendingReward while the failed state write leaves RewardDebt stale, draining the AlloraPendingReward module account.
**Escalation:** Repeated calls drain the pending-reward module account, causing insolvency for other delegate stakers.
**Insight:** In Cosmos reward-accounting flows, verify every state-write after a payout is checked; an ignored keeper Set error leaves the debt checkpoint stale and enables repeat claims.
