A liquidation system converts an account's risk breach into executable, settled actions. Its design must connect valuation, repayment size, incentives, market depth and the treatment of any remaining debt. This guide explains those connections with an illustrative partial-liquidation calculation and compares execution paths, failure handling and validation evidence for institutional software architectures.
Separate the trigger, execution and recovery
A liquidation trigger determines when an account becomes eligible for intervention. Execution determines how positions or collateral are converted into repayment. Recovery records the final assets, liabilities and any shortfall. Combining these into one vague promise of automatic liquidation hides the most important dependencies.
For a simple collateralized loan, a health ratio can compare collateral weighted by liquidation thresholds with outstanding debt. Aave's health-factor documentation describes this pattern and a trigger below one. A portfolio margin account instead needs a maintenance requirement derived from its positions and risk model. Neither trigger guarantees that enough liquidity will be available to complete the closeout.
The designs below are illustrative. FT Inc develops software for client-defined market infrastructure; the article does not claim that FT operates a liquidation venue, guarantees recovery or supplies committed backstop capital.
Calculate what partial repayment actually achieves
Consider collateral worth $120,000, debt of $100,000 and an 80% liquidation threshold. The initial health ratio is 0.96. Suppose a liquidator repays $20,000 and receives collateral worth 105% of that repayment, including a 5% incentive. The remaining collateral is $99,000 and debt is $80,000. The new ratio is 0.99, so the account remains below one.
health after repayment x = 0.80 × (120,000 - 1.05 × x) / (100,000 - x)
illustrative target health = 1.05
repayment needed under these assumptions ≈ $42,857At that repayment, approximately $45,000 of collateral transfers, leaving $75,000 of collateral and $57,143 of debt. Their weighted ratio is approximately 1.05. This assumes fixed prices, no extra fees, no limits on repayment size and sufficient transferable collateral. A real execution must recalculate from actual amounts.
The example explains why selecting an arbitrary close percentage is insufficient. Incentives consume the buffer being restored. When an account is deeply impaired, some liquidation terms can even worsen its remaining ratio. The policy needs explicit target, size, incentive and residual-debt rules, supported by calculations across the full range of eligible account states.
Choose a mechanism that matches the available liquidity
Different markets need different execution paths. A proposed architecture can support several, but each transition needs an explicit condition rather than an unbounded wait for a better price.
| Mechanism | Useful when | Design constraint |
|---|---|---|
| Atomic repayment and collateral transfer | Collateral can be acquired and financed in one transaction | Incentive, funding and transaction costs must support participation |
| RFQ | Approved counterparties can price a defined risk package | Quotes need expiry, fill limits, permissions and enforceable settlement |
| Auction | Price discovery benefits from competition over time | Time limits, participation, reserve rules and no-bid handling are essential |
| Depth-aware slices | The full account exceeds immediate executable size | Unclosed exposure continues to carry market and funding risk |
| Position transfer | An eligible counterparty can assume a complete risk group | The receiver must satisfy its own margin and settlement obligations |
Aave's Pool interface is a public example of repayment in exchange for collateral through a liquidation call. It should not be treated as a universal specification for portfolio transfers or permissioned assets. The RFQ engine guide covers the additional quote and settlement controls.
Specify a bounded state machine
An illustrative workflow is: observe a breach, validate current eligibility, reserve the selected exposure, obtain an executable route, settle a bounded amount, then recompute the account. Continue only while the defined policy permits intervention. Cancellation, expiry and failed settlement must release reservations exactly once.
A keeper's simulation is a proposal, not final authority. The contract must recheck eligibility at execution because a borrower may have repaid, prices may have recovered or another keeper may already have liquidated part of the account. Use committed amounts and current debt accrual rather than replaying an obsolete snapshot.
For portfolio positions, preserve useful hedges where practical. Closing one liquid leg can increase risk on the remainder. A package transfer or atomic pair of fills may reduce that problem, but only if both sides can actually settle. Define the behavior when one venue, asset or receiver becomes unavailable.
The hedge-unwind allocation study isolates one part of this decision: how the remaining position mix changes scenario margin when close size and fees are held equal.
Test participation under the same stress as the account
Liquidator economics depend on executable resale value, financing cost, transaction fees and exposure during settlement. A fixed percentage incentive that works in normal markets may be inadequate when spreads widen or transactions compete for scarce block space. Increasing the incentive indefinitely is also unsafe because it transfers more collateral out of the distressed account.
Measure capacity across all accounts that can breach together. Ten accounts cannot each assume exclusive access to the same quoted market depth. Simulations should remove depleted liquidity, include failed attempts and account for the market impact of previous slices.
Permissioned collateral narrows participation further. Check whether potential receivers can accept the asset, redeem it and deliver the required settlement currency. Displayed liquidity from an ineligible counterparty should contribute zero executable capacity until those constraints are resolved.
Define liquidation behavior during data or network failure
A stale or incorrect price can turn a protective mechanism into a wrongful asset transfer. Freshness, asset identity and feed-status checks belong in the execution path. A fallback source must have an approved economic meaning and adequate manipulation resistance; accepting any available number is not recovery.
On supported rollups, sequencer interruption creates a separate access problem. Chainlink's sequencer-uptime guidance describes checking sequencer status and using a recovery grace period. The grace period and allowed actions require chain-specific design: recovery should account for both user access and the age of the relevant price observations.
Specify which repayment and deposit actions remain available while liquidation is restricted. Also define how losses are monitored during that restriction. A pause changes the distribution of risk; it does not stop prices, interest or funding from moving.
Make backstops and bad debt explicit
A backstop is a separate resource with a capacity limit, operating conditions and a funding source. It can be a committed counterparty, a funded reserve or another contractually defined mechanism. Its availability cannot be assumed merely because the diagram contains a final box labeled backstop.
When ordinary execution fails, record why: no bids, invalid data, unavailable financing, restricted transfers or insufficient collateral. Different causes require different responses. Time-bound retry rules and exposure caps prevent a failed workflow from remaining invisible indefinitely.
If proceeds are insufficient, retain an explicit deficit record and apply the approved loss-allocation rules. Do not erase debt to make the account appear closed or assume a reserve covers every shortfall. Reporting should reconcile recovered assets, paid incentives, fees, remaining collateral and outstanding liabilities.
Validate the complete closeout path
Test healthy accounts, boundary accounts, partial repayments, insolvent accounts and dust balances. Check that price changes or competing liquidations cannot cause excessive seizure, duplicate rewards or repayment beyond the actual debt. Apply rounding consistently and verify balances after supported token transfers.
Exercise no-bid auctions, expired quotes, keeper outages, depleted funding, receiver restrictions and the largest permitted account. A successful trigger test is insufficient if the subsequent execution cannot fit within transaction limits. Replay multiple simultaneous breaches and measure time to settled recovery as well as financial shortfall.
The review artifact should connect each trigger to permitted actions, each action to accounting entries and each failure to an observable state. That makes the closeout system understandable to engineers, risk owners and operators before production exposure is introduced.
Common engineering questions
Does liquidation guarantee that a loan is repaid?
No. A liquidation trigger authorizes a recovery process. Actual repayment depends on collateral value, executable liquidity, transaction access, permissions and costs. Any remaining deficit needs an explicit accounting and loss-allocation policy.
Why can an account remain unhealthy after partial liquidation?
Repayment reduces debt but also removes collateral, including any liquidator incentive. The resulting ratio depends on both changes. The repayment amount should be tested against a defined target using actual settlement amounts.
When is RFQ useful for liquidation?
RFQ can support a defined collateral amount or position package when eligible counterparties can quote and settle it. The architecture still needs quote expiry, current eligibility checks, fill accounting and a fallback if no executable quote arrives.