# Selling sUSDe is vulnerable to sandwich attack when staked token is DAI

Ethena sUSDe redemption lacks slippage protection when borrow token is DAI, enabling MEV sandwich attacks that steal user funds.

- Payout: Contest reward
- Severity: high
- Program: Leveraged Vaults
- Credited: 0xrobsol
- Disclosed: 2024-06-18
- Write-up quality: 7/10
- Original: https://github.com/sherlock-audit/2024-06-leveraged-vaults-judging/issues/18
- Library page: https://bugbountylibrary.com/r/sherlock%3A2024-06-leveraged-vaults%3AH-3
- Tags: domain:web3 impact:funds-loss kind:contest platform:sherlock sev:high tech:evm tech:solidity technique:source-review vuln:business-logic

**Target:** Ethena.sol _sellStakedUSDe function
**Root cause:** The first trade (sUSDe to sDAI) has limit=0, relying on slippage check in the second trade, but the second trade is skipped when borrowToken is DAI, leaving no slippage protection.
**Steps:**
1. User calls _redeemFromNotional with instant redemption, triggering _executeInstantRedemption.
2. EthenaLib._sellStakedUSDe executes first trade: sUSDe to sDAI on Curve V2 pool with limit=0.
3. Since borrowToken is DAI, the second trade is skipped and borrowedCurrencyAmount = daiAmount.
4. MEV bot sandwiches the first trade, manipulating Curve pool price to extract value.
**How found:** Code review identified that slippage protection is only in the second trade, which is conditionally executed, leaving the first trade unprotected when borrowToken is DAI.
**Exploitation:** Attacker observes pending redemption transaction, front-runs by selling sUSDe into the Curve pool to depress its price, victim's trade executes at worse rate, attacker back-runs to profit from price restoration.
**Insight:** When a function has multiple trade legs, ensure each leg has independent slippage protection; conditional execution of later legs can leave earlier legs unprotected.