# User can prevent liquidations by frontrunning the tx and slightly increasing their collateral

Liquidator specifying max debt reverts when borrower frontruns by adding tiny collateral, shrinking max liquidation amount below requested value.

- Payout: Contest reward
- Severity: medium
- Program: Taurus
- Credited: Ruhum
- Disclosed: 2023-02-08
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2023-03-taurus-judging/issues/12
- Library page: https://bugbountylibrary.com/r/sherlock%3A2023-03-taurus%3AM-6
- Tags: domain:web3 impact:dos kind:contest platform:sherlock sev:medium tech:evm tech:solidity technique:source-review vuln:business-logic vuln:liquidation

**Target:** BaseVault liquidation logic (Solidity vault)
**Root cause:** _calcLiquidation reverts when _debtToLiquidate exceeds _getMaxLiquidation, which depends on current collateral/debt; a small collateral increase lowers max repay below the liquidator's fixed _debtAmount.
**Steps:**
1. Borrower has 100 TAU debt, 100 collateral at price $1, liquidatable.
2. Liquidator computes max repay ~23.07e18 and submits `liquidate(account, 23.07e18, minRate)`.
3. Borrower frontruns by adding 1 unit collateral (or repaying tiny debt).
4. New max repay becomes ~22.3e18; `_debtToLiquidate > _getMaxLiquidation` triggers `revert wrongLiquidationAmount()`.
5. Liquidation fails; borrower repeats to delay liquidation.
**How found:** Code reading of liquidate()/_calcLiquidation(): noticed _debtAmount is caller-fixed while max liquidation depends on mutable position state, so any position change invalidates the tx.
**Exploitation:** Borrower monitors mempool for liquidate() calls and frontruns with a minimal collateral deposit or debt repayment, causing the liquidator's fixed _debtAmount to exceed the recomputed max and revert.
**Insight:** When a liquidation function takes a caller-supplied amount and reverts if it exceeds a health-derived max, the borrower can grief by nudging state; check whether the contract should clamp instead of revert.