# Redemptions during undercollateralization can be hot-swapped to steal all funds

MEV searcher front-runs a redeem with refreshBasket() during collateral disable, forcing partial prorata redemption that burns all rTokens for dust.

- Payout: Contest reward
- Severity: medium
- Program: Reserve
- Credited: Cyfrin
- Disclosed: 2023-04-27
- Write-up quality: 7/10
- Original: https://github.com/code-423n4/2023-01-reserve-findings/issues/399
- Library page: https://bugbountylibrary.com/r/c4%3A2023-01-reserve%3AM-04
- Tags: domain:web3 impact:funds-loss kind:contest platform:code4rena sev:medium tech:evm tech:solidity technique:chained vuln:business-logic vuln:oracle-manipulation

**Target:** RToken redeem / BasketHandler refreshBasket
**Root cause:** redeem() only checks basket status != DISABLED, not full collateralization; refreshBasket() is permissionless when a collateral is DISABLED, so an attacker can switch the basket to a backup collateral the protocol holds ~none of before the victim's redemption executes.
**Steps:**
1. Victim submits redeem tx for 1M rToken to mempool while a collateral is DISABLED.
2. Attacker orders `refreshBasket()` before the redeem in the same block (permissionless when status()==DISABLED).
3. Basket switches to backup tokenB; protocol holds ~0 tokenB, status becomes SOUND.
4. Attacker sends dust tokenB to BackingManager so redemption doesn't revert.
5. Victim's redeem executes: `_burn(redeemer, amount)` burns all 1M rToken; prorata bound `(prorate * bal) / FIX_ONE` returns ~0 tokenB.
**How found:** Code review of redeem()'s status check versus fullCollateralization, combined with noticing refreshBasket() is callable by anyone when a collateral is DISABLED and that RedemptionBattery charge scales with totalSupply.
**Exploitation:** Validator/MEV searcher reorders a pending redeem tx, inserting refreshBasket() ahead of it after a collateral disable, and seeds dust of the new collateral so the redemption succeeds partially. Victim loses full rToken balance for dust; value accrues to RSR stakers via subsequent auctions.
**Escalation:** Attacker can also inflate rToken supply via flash-issue in handoutExcessAssets (buying tokenA, sending to BackingManager) to lift the RedemptionBattery cap, enabling larger redemptions; or coordinate with StRSR holders to honeypot redeemers.
**Insight:** When a redemption path checks only 'basket not DISABLED' rather than full collateralization, and basket switching is permissionless, any pending redeem is front-runnable into a partial payout that still burns the full rToken amount — look for status checks that omit solvency.