Liquidation Design

Liquidatable Condition

A vault is liquidatable when its unlocked REP backing is below the required threshold:

The contract snapshots the target vault when liquidation is queued. Execution reuses that snapshot, so adding REP later cannot block the pending liquidation.

Execution Gates

The liquidatable-threshold inequality is necessary but not sufficient for execution. A staged liquidation also needs a valid current oracle price, an unexpired staging window, target allowance unchanged and target ownership not below the queued snapshot, and enough distance beyond the threshold to satisfy minLiquidationPriceDistanceBps. These gates fail in different ways. If the current price is stale, execution reverts and the staged operation stays pending. If coordinator-level checks fail after a valid price is available, such as expiry, stale snapshot data, or too little distance from the threshold, the coordinator consumes the staged operation without calling the pool. If the pool call itself fails after consumption, for example because the caller would become liquidatable or because a requested chunk leaves forbidden debt dust, the coordinator emits a failed execution result. See OpenOracle integration for the full settlement and distance-check flow.

Penalty Math

The seized REP is based on the debt chunk's market value plus a fixed liquidation bonus. The current implementation uses LIQUIDATION_REP_BONUS_BPS = 500, or a five percent REP bonus to the liquidator.

The maximum executable debt chunk is bounded by the target's unlocked REP. The contract will not liquidate away the last MIN_REP_DEPOSIT unless a separate flow closes the vault fully.

There is one more chunking constraint at execution time: remainingDebt = targetAllowanceEth - debtToMove must be zero or at least MIN_SECURITY_BOND_DEBT. The caller's post-liquidation allowance must also be at least MIN_SECURITY_BOND_DEBT, because any successful liquidation moves non-zero debt to the caller. A chunk that is safe for the target can still revert if it would leave the liquidator below that minimum non-zero debt floor. Very small chunks can also revert when ceiling-rounded REP seizure would reduce the target's REP faster than the chunk reduces required backing, because every successful liquidation must strictly improve target health.

Repeated Liquidations

A punitive liquidation is not guaranteed to restore target safety in one execution. A liquidation can move the target toward safety without restoring it completely, because the liquidator is also paid a REP bonus. Repeated liquidations at the same price can therefore remain possible until the target debt is cleared, the target becomes safe again, the target hits a floor constraint, or the liquidator side would become liquidatable after absorbing more debt. This is one source of path dependence: a smaller first liquidation can make the target safe again and block a later same-price liquidation that would have been absorbed inside one larger execution.

Worked Examples

Unless a row says otherwise, assume the caller vault already has enough REP backing to remain non-liquidatable after it absorbs the moved debt and receives seized REP. The rows focus on target-side sizing and penalty math; execution still applies the caller post-liquidation check.

Slider Examples

These calculators use whole ETH and REP units for readability. The equations above describe the scaled integer math used onchain.

Incentive Implications

The protocol uses a target-funded REP penalty. That means the liquidator has a direct immediate reward and the target is explicitly punished when it falls below the collateral threshold.

This only improves the target if debt relief frees more required backing than the protocol seizes as a REP bonus. Ignoring integer rounding, the economic condition is:

securityMultiplier > 1 + liquidation bonus

With a 2x security multiplier and a 5% REP bonus, ordinary-sized liquidations reduce required backing faster than seized REP, so the target gets healthier even while it loses collateral. The executable rule is still the strict onchain health-improvement guard debtToMove * securityMultiplier * currentRepPerEthPrice > repToMove * PRICE_PRECISION; ceil-rounded tiny chunks can fail with No gain.

The tradeoff is boundary sensitivity, not generic path dependence. Partial liquidations can leave the target still liquidatable, and exact results become path-sensitive when integer rounding, REP floors, debt floors, or caller threshold checks bind. Away from those boundaries, the linear REP penalty means repeated partial liquidations at a fixed price can reach the same final state as one combined liquidation.