# No slippage protection when withdrawing and providing liquidity in rebalanceAll

rebalanceAll withdraws and re-deposits all pool liquidity without amount0Min/amount1Min slippage checks, exposing LPs to sandwich/slippage losses.

- Payout: Contest reward
- Severity: high
- Program: Real Wagmi
- Credited: ast3ros
- Disclosed: 2023-06-14
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2023-06-real-wagmi-judging/issues/94
- Library page: https://bugbountylibrary.com/r/sherlock%3A2023-06-real-wagmi%3AH-2
- Tags: domain:web3 impact:funds-loss kind:contest platform:sherlock sev:high tech:evm tech:solidity technique:source-review vuln:business-logic

**Target:** Multipool.sol rebalanceAll liquidity withdraw/deposit
**Root cause:** rebalanceAll calls _withdraw and _deposit without amount0Min/amount1Min parameters, unlike deposit/withdraw which enforce slippage bounds.
**Steps:**
1. Call `rebalanceAll` on Multipool.sol
2. Observe `_withdraw(_totalSupply, _totalSupply)` at L853 and `_deposit(reserve0, reserve1, _totalSupply, slots)` at L885 execute with no min-amount args
3. Attacker sandwiches the rebalance tx to move pool price, causing withdraw/deposit to execute at unfavorable rates
4. LP funds in multipool lose value to the slippage
**How found:** Code review comparing rebalanceAll against deposit/withdraw functions, noting the latter pass amount0Min/amount1Min (L437-438, L559-560) while rebalanceAll omits them.
**Exploitation:** Attacker front-runs the rebalanceAll transaction to skew pool price, lets the unprotected withdraw/deposit execute at manipulated rates, then back-runs to capture the delta from LPs.
**Insight:** When auditing rebalancers, diff the slippage-guarded deposit/withdraw paths against the rebalance path—rebalancers often bypass the min-amount checks the user-facing functions enforce.