# Complete liquidity removals fail from stableswap pools

Stableswap pools lack multi-token withdrawal, so redeeming all LP tokens via remove_liquidity_one_asset overflows and reverts, locking initial liquidity.

- Payout: Contest reward
- Severity: medium
- Program: HydraDX
- Credited: carrotsmuggler
- Disclosed: 2024-04-10
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2024-02-hydradx-findings/issues/86
- Library page: https://bugbountylibrary.com/r/c4%3A2024-02-hydradx%3AM-04
- Tags: domain:web3 impact:dos kind:contest platform:code4rena sev:medium tech:solidity technique:source-review vuln:business-logic vuln:dos

**Target:** Stableswap pallet remove_liquidity_one_asset / withdraw_asset_amount
**Root cause:** Only single-asset withdrawal functions exist; redeeming the entire LP supply drives the stableswap invariant math to divide by zero remaining liquidity, causing an arithmetic overflow.
**Steps:**
1. Create a 3-asset stableswap pool with equal initial liquidity from ALICE.
2. Read ALICE's full LP token balance `received`.
3. Call `Stableswap::remove_liquidity_one_asset(ALICE, pool_id, asset_a, received, 0)`.
4. Observe `Arithmetic(Overflow)` revert because no liquidity remains for the conversion math.
**How found:** Code review noted the absence of Curve's multi-token `remove_liquidity` and hypothesized that full redemption through the single-asset path would break the invariant math; confirmed with a Substrate test.
**Exploitation:** Not weaponized; the flaw is a functional DoS where the last LP holder cannot exit, temporarily locking funds.
**Insight:** When a protocol ports an AMM but omits a withdrawal variant, test the extreme case of redeeming 100% of LP supply through the remaining paths—invariant math often assumes nonzero reserves.