# setPendingRedemptionBalance() may cause the user's cash token to be lost

Admin setPendingRedemptionBalance overwrites user's concurrent requestRedemption increase in addressToBurnAmt, silently losing the user's cash tokens.

- Payout: Contest reward
- Severity: medium
- Program: Ondo Finance
- Credited: bin2chen
- Disclosed: 2023-02-28
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2023-01-ondo-findings/issues/82
- Library page: https://bugbountylibrary.com/r/c4%3A2023-01-ondo%3AM-05
- Tags: domain:web3 impact:funds-loss kind:contest platform:code4rena sev:medium tech:solidity technique:race-window vuln:accounting-error vuln:race-condition

**Target:** setPendingRedemptionBalance / requestRedemption in redemption manager contract
**Root cause:** setPendingRedemptionBalance sets addressToBurnAmt[user] to an absolute value without checking the prior balance, so a concurrent requestRedemption increment is clobbered.
**Steps:**
1. currentEpoch=1, addressToBurnAmt[alice]=50
2. Admin calls `setPendingRedemptionBalance(alice, 1, 60)` intending +10
3. Alice front-runs with higher gas: `requestRedemption(100)` making balance 150
4. Admin tx lands, overwriting to 60; alice loses 100
**How found:** Code review of setPendingRedemptionBalance noting it writes an absolute balance without reading/validating the existing addressToBurnAmt, combined with the fact requestRedemption also mutates the same mapping.
**Exploitation:** Race: user submits requestRedemption with higher gas price so it executes before the admin's setPendingRedemptionBalance, which then overwrites the incremented balance with a stale absolute value.
**Insight:** Admin setter functions that write absolute values to a mapping also mutated by user actions need an oldBalance/expected-value check or delta semantics; look for setters lacking compare-and-swap on shared accounting state.