Liquidium

Liquidations

How liquidations protect the protocol and its users

Liquidation Eligibility

A position becomes liquidatable when:

plaintext
health_factor < 1.0

This means the risk-adjusted collateral value no longer covers the debt.

For the borrower-facing safety display, Liquidium may show position safety as Health %, while technical examples often use decimal Health Factor. See the Health Factor guide for the Health Factor to Health % conversion table and calculation.

Close Factor

The close factor determines how much of a position's debt in one asset can be repaid in a single liquidation:

Health Factor

Close Factor

Meaning

0.975 - 1.0

50%

Partial liquidation

≤ 0.975

100%

Full liquidation allowed

The close factor applies to the borrower's debt in the debt pool being liquidated. The amount is also limited by the collateral available in the chosen collateral pool. Partial liquidation gives borrowers a chance to recover their position before complete closure.

Liquidation Bonus

Liquidators receive a bonus as incentive to maintain protocol health:

Asset

Liquidation Bonus

BTC

5%*

ETH

5%*

USDC

5%*

USDT

5%*

ICP

7.5%*

Live liquidation bonuses can change. Check the live Insights page for current asset-specific liquidation bonuses, liquidation thresholds, and Max LTV values.

The bonus is paid in collateral tokens, meaning liquidators receive more collateral than the debt they repay.

Liquidation Math

Collateral Calculation

plaintext
max_repay_amount = position.debt_in_pool × close_factor

repay_value_usd = repay_amount × debt_asset_price
bonus_value_usd = repay_value_usd × liquidation_bonus

Protocol Fee

The protocol fee is taken from the bonus only, not from the repaid amount:

plaintext
protocol_fee_usd = bonus_value_usd × protocol_liquidation_fee (currently 5%)
liquidator_receives_usd = repay_value_usd + bonus_value_usd - protocol_fee_usd

seized_collateral = (liquidator_receives_usd + protocol_fee_usd) / collateral_asset_price

Example Liquidation

Underwater Position:

plaintext
Borrower:
  Collateral: 1 BTC @ $50,000 (LT = 74%)
  Debt: $38,000 USDC

Health Factor: (50000 × 0.74) / 38000 = 0.974 (liquidatable)

Liquidator Action:

plaintext
Close factor: 100% (HF ≤ 0.975)
The liquidator chooses to repay $19,000 USDC

Liquidation bonus: 5%
Bonus value: $19,000 × 0.05 = $950

Protocol fee (5% of bonus): $950 × 0.05 = $47.50
Liquidator receives: $19,000 + $950 - $47.50 = $19,902.50 = 0.39805 BTC
Protocol receives: $47.50 = 0.00095 BTC
Total collateral seized: 0.399 BTC

Result:

plaintext
Borrower after liquidation:
  Collateral: 1 - 0.399 = 0.601 BTC
  Debt: $38,000 - $19,000 = $19,000 USDC
  New HF: (0.601 × 50000 × 0.74) / 19000 = 1.17 ✓ Safe

Liquidator profit:
  Paid: $19,000 USDC
  Received: 0.39805 BTC = $19,902.50
  Profit: $902.50 (4.75%)

At a Health Factor above 0.975, the same position would allow at most 50% of the debt to be repaid in one liquidation.

Liquidation Flow

  1. The liquidator calls scan_at_risk_positions to find eligible positions.
  2. The liquidator submits liquidate or liquidate_with_slippage with a LiquidationRequest.
  3. The Lending Canister validates the position's Health Factor and calculates the close factor, seized collateral, liquidation bonus, and protocol fee.
  4. The protocol atomically updates the borrower's debt and collateral shares and records the liquidation.
  5. The debt asset is collected from the liquidator and the seized collateral is sent to the requested receiver principal.

Atomic State Updates

Liquidations update state atomically before any async operations:

  1. Burn borrower's debt shares - Reduces their debt
  2. Burn borrower's collateral shares - Seizes collateral
  3. Mint treasury shares - Protocol fee captured
  4. Record liquidation event - Audit trail

The actual asset transfers (debt repayment, collateral delivery) happen asynchronously via the WAL system.

Learn more about Write Ahead Logging here.

Finding Liquidatable Positions

The production Lending Canister is:

plaintext
hyk4r-jqaaa-aaaar-qb4ca-cai

Use the cursor-based query to find eligible positions:

plaintext
scan_at_risk_positions(
  cursor: opt principal,
  scan_limit: nat64,
  max_results: nat64
) -> ScanResult

Results include the borrower principal, Health Factor, weighted liquidation threshold, pool positions, and total debt.

The legacy offset-based query remains available:

plaintext
get_at_risk_positions(
  offset: nat64,
  limit: nat64
) -> vec LiquidatableUser

Liquidator Requirements

To execute a liquidation, the liquidator must:

  • Have sufficient debt asset to repay the borrowed amount
  • Call the Lending Canister using their IC principal
  • Specify the borrower, debt pool, collateral pool, and debt amount
  • Provide the principal that should receive the collateral

Liquidations are publicly callable in production. You do not need to register or have your principal added to an allowlist. Allowlisted liquidators are processed immediately; other callers wait one extra round of consensus, which gives allowlisted liquidators a head start.

The available execution methods are:

plaintext
liquidate(request: LiquidationRequest)

liquidate_with_slippage(
  request: LiquidationRequest,
  min_collateral_amount: nat
)

liquidate_with_slippage protects against receiving less than the specified minimum gross collateral amount.

Liquidations are competitive. Successful liquidators typically run automated bots that monitor positions and execute quickly when opportunities arise.
Liquidation execution is separate from the Liquidium SDK. The SDK does not currently provide a liquidation-execution helper.

Economic Security

The liquidation mechanism provides several security guarantees:

Feature

Purpose

Overcollateralization

Positions start with buffer above liquidation threshold

Liquidation bonus

Incentivizes quick liquidation before bad debt

Protocol fee

Builds treasury for unexpected losses

Close factor

Allows partial recovery for borrowers

Price oracles

Exchange Rate Canister prices; liquidations stop if prices are stale