# Bad Debt Redistribution Not Happening Between Liquidations in Batch Mode

Batch liquidation in Bima's LiquidationManager defers debt redistribution to end of batch, so later liquidations use stale debt values, miscomputing ICR and collateral surplus.

- Payout: Contest reward
- Severity: high
- Program: Bima
- Credited: 0xNirix
- Disclosed: 2025-02-05
- Write-up quality: 7/10
- Original: https://cdn.cantina.xyz/reports/cantina_competition_bima_december2024.pdf#3.1.9
- Library page: https://bugbountylibrary.com/r/cantina%3Abima_december2024%3A3.1.9
- Tags: domain:web3 impact:funds-loss kind:contest platform:cantina sev:high tech:evm tech:solidity technique:regression technique:source-review vuln:accounting-error vuln:liquidation

**Target:** LiquidationManager.sol batch liquidation functions
**Root cause:** batchLiquidateTroves accumulates totals and only calls finalizeLiquidation (which applies debt/coll redistribution) after the whole loop, so each subsequent liquidation reads pre-redistribution debt.
**Steps:**
1. Open two troves (user1 1 BTC, user2 2 BTC) at max debt via `_openTrove`.
2. Drop oracle price to 30000e8 and warp.
3. Sequentially call `liquidationMgr.liquidate(troveMgr, user1)` then `liquidate(troveMgr, user2)`, recording `Liquidation` events.
4. Revert snapshot, reopen troves, call `liquidationMgr.batchLiquidateTroves(troveMgr, [user1,user2])`.
5. Compare: `seqLiqDebt1+seqLiqDebt2 > batchLiqDebt` and `seqLiqColl1+seqLiqColl2 > batchLiqColl`, proving batch under-reports debt and over-assigns collateral surplus.
**How found:** Code reading of batchLiquidateTroves revealed `_applyLiquidationValuesToTotals` inside the loop but `finalizeLiquidation` (which performs redistribution) only after the loop; hypothesis validated by differential test comparing sequential vs batch liquidation event totals.
**Exploitation:** Liquidator batches multiple underwater troves; because redistribution is deferred, later troves' ICR is computed on stale (lower) debt, so more collateral is classified as surplus and returned to borrowers while the unaccounted debt is socialized to remaining system users.
**Insight:** In CDP/lending batch liquidation loops, check whether redistribution/socialized-debt accounting is applied per-iteration or deferred to a finalize call; a differential test (sequential vs batch) on emitted debt/collateral totals exposes stale-state ordering bugs.