# Incorrect slippage check in the AMO2.rebalanceUp can be attacked by MEV

AMO2.rebalanceUp computes min xETH received by subtracting slippage from virtual-price estimate, which understates the true one-sided Curve withdrawal amount, enabling a small MEV sandwich.

- Payout: Audit contest
- Severity: medium
- Program: xETH
- Found by: ronnyx2017
- Disclosed: 2023-08-15
- Write-up quality: 6/10
- Original: https://code4rena.com/reports/2023-05-xeth#m-07
- Library page: https://bugbountylibrary.com/r/c4%3A2023-05-xeth%3AM-07
- Tags: area:web3 domain:web3 impact:funds-loss kind:contest platform:code4rena sev:medium tech:evm tech:solidity technique:source-review vuln:business-logic vuln:oracle-manipulation

**Target:** AMO2.rebalanceUp / bestRebalanceUpQuote on Curve peg pool
**Root cause:** bestRebalanceUpQuote derives min_xETHReceived as applySlippage(vp * lpBurn / BASE_UNIT), but virtual price only reflects a balanced pool; when removing only the overweight xETH coin (pool >75% xETH), actual xETH received exceeds the vp estimate, so the computed lower bound is wrong and does not protect the defender quote.
**Steps:**
1. Observe rebalanceUp requires preRebalanceCheck true, i.e. `xETHBal / (stETHBal + xETHBal) > REBALANCE_UP_THRESHOLD` (default 0.75E18).
2. Note rebalanceUp removes liquidity as only xETH, so slippage is positive (more xETH per LP than vp).
3. Read bestRebalanceUpQuote: `bestQuote.min_xETHReceived = applySlippage((vp * defenderQuote.lpBurn) / BASE_UNIT)` with `applySlippage(amount) = amount * (BASE_UNIT - maxSlippageBPS) / BASE_UNIT`.
4. Because the vp-based estimate is below the real one-sided withdrawal amount, the contractQuote lower bound is too low and the defenderQuote is not protected.
5. Sandwich the rebalanceUp tx: front-run to skew the pool, let rebalanceUp execute against the weakened bound, back-run to capture the difference.
**How found:** Warden reasoned about preRebalanceCheck threshold (>0.75 xETH) and the fact that rebalanceUp withdraws only the overweight coin, concluding slippage is positive; then compared that to the applySlippage formula which subtracts slippage from the vp estimate, spotting the mismatch.
**Exploitation:** Attacker sandwiches a rebalanceUp transaction; since the computed min_xETHReceived is derived from an incorrect vp-based estimate rather than the true one-sided Curve withdrawal amount, the slippage bound is too loose and the attacker can extract value via front-run/back-run around the rebalance.
**Insight:** When a protocol uses virtual price (a balanced-pool invariant) as the reference for a one-sided Curve withdrawal, the true received amount diverges from vp; check whether the slippage bound is computed from vp or from the actual one-coin withdrawal quote, especially when the pool is intentionally imbalanced by design thresholds.