DeFi Protocol Liquidation Engine: Frequently Asked Questions

Liquidations are the risk management layer of every DeFi lending protocol. When they work correctly, they are invisible — bad positions get closed, the protocol stays solvent, and users barely notice. When they fail — because the incentives are wrong, the oracle is stale, or the engine has a bug — the protocol accumulates bad debt that can trigger a death spiral. These are the questions we get most often about liquidation engine design.

What is a health factor and how should it be calculated?

The health factor is a single number that expresses whether a position is solvent. The formula is:

health_factor = sum(collateral_i * price_i * liquidation_threshold_i) / sum(debt_j * price_j)

When health factor is above 1.0, the position is adequately collateralized. When it falls to exactly 1.0, the position is at the liquidation threshold. When it drops below 1.0, the position is eligible for liquidation.

The liquidation threshold is distinct from the loan-to-value (LTV) ratio. LTV governs the maximum a user can borrow at deposit time. The liquidation threshold is higher than LTV — for example, LTV of 75% and liquidation threshold of 80%. The gap between them creates a buffer that prevents instant liquidations from normal price movements.

Each collateral asset can have different thresholds based on its volatility, liquidity, and price oracle quality. More volatile or less liquid assets warrant more conservative thresholds.

What is the liquidation bonus and how do you set it correctly?

The liquidation bonus (sometimes called the liquidation incentive) is the discount a liquidator receives on the collateral they seize relative to its oracle price. If the bonus is 5%, a liquidator who repays $100 of debt receives $105 worth of collateral at oracle prices.

Setting the bonus too low means liquidations are not profitable after gas costs, so liquidators will not show up — especially for small positions on mainnet where gas cost relative to position size may exceed the bonus. Setting it too high means borrowers are over-punished for brief periods of undercollateralization and creates an incentive to liquidate positions that are borderline rather than deeply underwater.

A reasonable starting range for most assets is 5–10%, calibrated based on expected gas costs, the typical distribution of position sizes, and oracle update frequency. Assets with high price volatility or thin on-chain liquidity warrant higher bonuses to ensure liquidators can exit the collateral quickly.

What is a close factor and why does it matter?

The close factor limits how much of a position can be liquidated in a single transaction. A close factor of 50% means a single liquidation call can repay at most 50% of the outstanding debt.

Without a close factor, a position that dips just below the liquidation threshold could be entirely liquidated in one transaction. The borrower loses 100% of their collateral despite the protocol being exposed to only a small shortfall. This is an unnecessarily harsh outcome and discourages protocol usage.

With a close factor, the borrower can partially recover: if the price recovers after a 50% partial liquidation, they retain the remaining position. The protocol remains solvent, the liquidator earns their incentive, and the borrower is not completely wiped out by a brief market move.

What happens when a liquidation cannot cover the debt?

When collateral value falls so fast that a position becomes undercollateralized before liquidators can act — or when no liquidator executes during a sharp decline — the protocol holds bad debt: debt that exceeds the value of the collateral backing it.

Most production protocols handle this through one or more mechanisms:

• Insurance fund: A portion of protocol fees is reserved in a separate fund. When bad debt occurs, the fund covers it, protecting depositors.
• Governance token backstop: As a last resort, the protocol mints new governance tokens and sells them to cover bad debt. This dilutes existing holders but protects depositors.
• Socialized losses: Bad debt is spread proportionally across all depositors of the affected asset, reducing their redemption value slightly. Aave's original model used this approach.

Each approach has tradeoffs. Insurance funds provide the cleanest protection but require building up reserves over time. Token dilution is seen as a protocol failure event by markets. Socialized losses are opaque and may surprise depositors who do not read protocol documentation carefully.

How do you prevent liquidation bot gas wars from congesting the network?

When a large position becomes liquidatable, dozens of bots compete to liquidate it first by submitting transactions with progressively higher gas prices. The winner earns the liquidation bonus; all others waste gas. This activity can congest the network and creates a winner-take-all dynamic that discourages participation by less sophisticated operators.

Mitigation strategies:

• Dutch auction liquidations: The liquidation bonus starts low and increases over time for a given position. Any liquidator who acts can capture the prevailing bonus, removing the incentive to front-run each other. The trade-off is that time passes before liquidation occurs, which increases bad debt risk.
• Partial liquidation parity: Allow any liquidator to initiate a partial liquidation at a fixed bonus, with no priority advantage for being first. If multiple partial liquidators hit the same position simultaneously, each gets their portion.
• Keeper networks: Integrate Chainlink Automation or Gelato to trigger liquidations automatically, capturing the bonus for a protocol-managed keeper address. This removes the adversarial dynamic entirely for positions that keepers are watching.

What oracle latency is acceptable before liquidation risk increases materially?

This depends on the volatility of the collateral assets and the collateralization ratio buffer. For volatile assets like ETH during fast market moves, a 1-hour Chainlink oracle heartbeat can mean the price used for health factor calculations is significantly stale.

The practical guideline:

• For stable or low-volatility collateral, a 30–60 minute maximum oracle age is acceptable
• For high-volatility collateral (major L1/L2 tokens), consider requiring a maximum age of 5–15 minutes, even if this means triggering the circuit breaker more frequently during oracle downtime
• Build in a mechanism to pause new borrows — but not repayments or withdrawals — when oracle data exceeds the maximum age, rather than pausing the entire protocol

How do you test a liquidation engine before launch?

A liquidation engine should be tested with:

• Unit tests for every state transition: Position creation, health factor crossing the threshold, liquidation execution with various close factors, and post-liquidation state validation
• Fuzz tests for price oracle values: Randomize oracle prices across reasonable ranges and verify that health factor calculations are always correct and that no liquidation can produce negative protocol equity
• Simulation of bad debt scenarios: Manually set oracle prices such that positions are underwater and verify that the bad debt handling mechanism activates correctly
• Gas profiling: Measure gas cost for liquidating positions of different sizes and confirm that the liquidation bonus covers gas at expected gas prices

---

Liquidation engine design sits at the intersection of economics, smart contract engineering, and risk management. Getting it wrong is one of the most reliable ways a lending protocol accumulates bad debt. If you are building a lending protocol and want an engineering team with DeFi risk system experience, start a build with Clixo.