# _liquidateUser() should not re-use the same minimum swap amount out for multiple liquidation

Tapioca's batch liquidate() reuses one minAssetAmount for all borrowers, causing under-protected swaps or reverting the whole batch.

- Payout: Contest reward
- Severity: high
- Program: Tapioca DAO
- Credited: peakbolt
- Disclosed: 2023-11-16
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2023-07-tapioca-findings/issues/1168
- Library page: https://bugbountylibrary.com/r/c4%3A2023-07-tapioca%3AH-20
- Tags: domain:web3 impact:dos impact:funds-loss kind:contest platform:code4rena sev:high tech:solidity technique:source-review vuln:business-logic vuln:liquidation

**Target:** Singularity/BigBang _liquidateUser swap slippage parameter
**Root cause:** liquidate() decodes a single minAssetAmount from dexData and applies it to every borrower's swap, though each collateral position has a different expected output.
**Steps:**
1. Call liquidate() with multiple borrowers and dexData encoding minAssetAmount=1000 USDO.
2. Observe _liquidateUser decodes the same minAssetAmount for each borrower's swapper.swap().
3. Borrower X collateral worth 1000 USDO swaps fine; borrower Y collateral worth 5000 USDO also swaps against the 1000 floor, underpaying.
4. Alternatively borrower Y collateral worth 300 USDO cannot meet the 1000 floor, reverting the entire batch including X.
**How found:** Code reading of _liquidateUser: noticed minAssetAmount decoded once from dexData and reused across the multi-borrower loop, inconsistent with per-position slippage needs.
**Exploitation:** Liquidator sets a low minAssetAmount to pass all swaps; low-liquidity pools then fill large collateral swaps at the shared floor, shortchanging liquidator and protocol. Or a high floor reverts the whole batch, blocking liquidation.
**Insight:** In batch operations, per-item slippage/limit parameters must be per-item; a single decoded bound shared across heterogeneous positions either under-protects large ones or reverts small ones.