# The redeem process updates the rewards in the wrong order

Elfi redeem burns stake tokens before syncing fee rewards, so users accrue rewards on already-burned balance, inflating payouts.

- Payout: Contest reward
- Severity: high
- Program: Elfi Protocol
- Credited: Cosine
- Disclosed: 2024-05-09
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2024-05-elfi-protocol-judging/issues/274
- Library page: https://bugbountylibrary.com/r/sherlock%3A2024-05-elfi-protocol%3AH-33
- Tags: domain:web3 impact:funds-loss kind:contest platform:sherlock sev:high tech:solidity technique:source-review vuln:business-logic vuln:reward-distribution

**Target:** RedeemProcess.executeRedeemStakeToken staking/rewards contract
**Root cause:** executeRedeemStakeToken burns the stake tokens first and only then calls updateAccountFeeRewards, so the reward sync uses the post-burn (lower) balance instead of the pre-burn balance.
**Steps:**
1. Call redeem on a supported stakeToken so RedeemProcess.executeRedeemStakeToken runs.
2. Observe _redeemStakeToken/_redeemStakeUsd burns tokens and reduces balance.
3. Observe FeeRewardsProcess.updateAccountFeeRewards is invoked after the burn.
4. Rewards are computed against the reduced balance, mis-accruing rewards versus a Masterchef-style sync-before-mutate flow.
**How found:** Code reading of the redeem flow: noticed updateAccountFeeRewards placed after the burn, contradicting the standard Masterchef pattern of syncing rewards before any balance mutation.
**Exploitation:** A staker redeems stake tokens; because rewards are synced after the burn, the accounting diverges from the correct pre-burn accrual, letting rewards be unfairly accrued/misstated across users.
**Insight:** In staking/reward contracts, check ordering of reward-sync calls relative to every balance mutation (burn, transfer, withdraw); a sync placed after the mutation silently mis-accrues rewards.