# Liquidations are impossible for some Curve pools

Curve vault's reentrancy check calls remove_liquidity(0,[0,0]) which underflows on some pools like CRV/ETH, making liquidations always revert and bad debt unrecoverable.

- Payout: Contest reward
- Severity: high
- Program: Notional
- Credited: usmannk
- Disclosed: 2023-02-27
- Write-up quality: 7/10
- Original: https://github.com/sherlock-audit/2023-02-notional-judging/issues/21
- Library page: https://bugbountylibrary.com/r/sherlock%3A2023-02-notional%3AH-1
- Tags: domain:web3 impact:funds-loss kind:contest platform:sherlock sev:high tech:evm tech:solidity technique:source-review vuln:dos vuln:liquidation

**Target:** Curve leveraged vault reentrancy guard (Curve2TokenVaultMixin)
**Root cause:** _checkReentrancyContext probes Curve's reentrancy state by calling remove_liquidity(0,[0,0]); on pools like CRV/ETH this call reverts with an underflow, so the guard always reverts and deleverageAccount cannot execute.
**Steps:**
1. Identify Curve vault using Curve2TokenVaultMixin._checkReentrancyContext.
2. Note it calls `remove_liquidity(0, [0,0])` on the pool.
3. Target CRV/ETH pool 0x8301ae4fc9c624d1d396cbdaa1ed877821d7c511.
4. Call deleverageAccount for a position on that vault; the reentrancy check reverts via underflow, blocking liquidation.
**How found:** Code review of the reentrancy guard's use of remove_liquidity as a probe, then checking pool-specific behavior where zero-liquidity removal underflows.
**Exploitation:** Any liquidation attempt on affected Curve pools reverts, so underwater positions cannot be deleveraged; accounts drift into bad debt with no recovery path.
**Insight:** Reentrancy guards that probe external state via a state-changing call can revert on edge-case pools/params; test guard calls against each integrated pool's actual math rather than assuming a no-op succeeds.