What Happens If a Liquidation Keeper Fails?

A failed liquidation bot is usually replaceable, but a market-wide execution delay can let an unhealthy loan become bad debt. Learn the failure path, economics, and protocol safeguards.

For educational purposes only; not investment advice. DeFi lending and liquidation systems can produce rapid, irreversible losses.

Direct answer

One failed liquidation keeper usually causes a missed or reverted transaction, not an immediate protocol failure. In many lending protocols there is no exclusive keeper: liquidation is permissionless, so another bot, contract, or user can submit the transaction. Aave, for example, says any network participant can liquidate an eligible position and describes liquidations as highly competitive.

The serious case is collective failure: no participant can or will execute at an economically viable price. A position can remain below its liquidation threshold while interest accrues and collateral keeps moving. If liquidation later recovers less value than the debt and costs assigned to the position, the difference becomes a shortfall or bad debt under that protocol’s accounting.

Who absorbs the shortfall is protocol-specific. Compound III’s absorb transfers an underwater account’s debt to the protocol and uses base-asset reserves, while the protocol takes the collateral. Maker’s Dog.bark transfers an unsafe Vault’s debt to the protocol, starts a collateral auction, and records the debt in its accounting system. Other systems may use reserves, insurance or stability funds, governance recapitalization, loss socialization, or a combination.

For a borrower, liquidation automation is therefore not a stop-loss service. The safe action is to monitor the position and repay debt or add collateral before the threshold is crossed; a delayed liquidation can increase both collateral loss and the chance of an unrecoverable deficit.

How it works

A typical external-liquidator path has five stages:

Eligibility: The protocol reads its configured oracle and determines that an account has crossed the liquidation threshold. A stale or paused oracle can delay or block that state change even when the market price has already moved.
Detection and pricing: Off-chain bots index positions, simulate the liquidation, estimate collateral proceeds, and decide whether the opportunity is profitable.
Transaction inclusion: A liquidator funds the required debt asset, submits a transaction, and competes for block space. Congestion, an underpriced fee, a failed RPC, a nonce conflict, or another liquidator winning first can leave the transaction pending or make it revert.
Contract execution: The contract checks current prices, account state, close-factor or auction limits, pause controls, and available liquidity. A transaction that was valid during simulation can fail after any of these inputs changes.
Collateral disposal: The liquidator or protocol must sell, hedge, or auction the seized collateral. Thin liquidity and a falling market can turn an apparent bonus into a loss.

The liquidator’s simplified decision is expected profit = liquidation incentive - gas - price impact - hedge cost - expected revert loss. Capital cost and protocol fees may also apply. A large quoted bonus is not enough if the collateral cannot be sold near the oracle price or if execution is unlikely.

Failure is often partial rather than absolute. One account, collateral type, chain, oracle, RPC provider, or auction can fail while others continue. Maker’s Liquidation 2.0 documentation, for example, includes per-collateral and global auction limits, auction resets, keeper incentives, and a four-stage circuit breaker. These controls change how delayed execution propagates through that particular system.

Worked example

Assume an eligible account has 100,000 USDC of debt and collateral worth 103,000 USDC. A simplified protocol lets a liquidator repay 50,000 USDC and claim collateral worth 52,500 USDC, a 5% gross incentive.

Selling the collateral is expected to cost 2,000 USDC in price impact.
Gas and priority fees are 700 USDC.
The expected cost of reverted or outcompeted transactions is 300 USDC.
Expected profit is therefore 52,500 - 50,000 - 2,000 - 700 - 300 = -500 USDC.

A rational liquidator may wait or skip the account. If nobody executes and the collateral falls another 5%, its value becomes 97,850 USDC, leaving a 2,150 USDC deficit against the original debt before additional interest or fees. A later liquidation can still reduce the loss, but it cannot create collateral value that no longer exists.

This is an illustration, not a model of one deployed market. Real close factors, bonuses, oracle prices, protocol fees, reserve rules, and transaction costs must be read from the current contracts and official documentation. Aave’s published rules, for example, vary the maximum liquidatable share with health factor and position size.

Risks and safeguards

Borrower controls: Keep a deliberate buffer above the liquidation threshold, set independent alerts, and maintain a tested way to repay or add collateral. Do not assume a front end, automation provider, or liquidator will remain available during congestion.
Protocol controls: Robust systems diversify oracle and transaction infrastructure, calibrate bonuses and minimum position sizes, bound liquidation volume, support partial or batched liquidation where appropriate, and define pauses, auction resets, reserves, and deficit handling before a crisis.
Liquidator controls: Operators should use multiple RPC endpoints, reconcile on-chain state before signing, simulate against the pending state, manage nonce replacement, cap slippage, and avoid relying on a single exchange or flash-liquidity source.
Lender and depositor checks: Identify the exact bad-debt waterfall. Verify which reserve covers which market, who can change parameters, whether the reserve is liquid and accessible, and what happens after it is exhausted.

No safeguard guarantees execution. Incentives can be too small in calm markets yet excessively generous or exploitable after parameters change. Pauses and circuit breakers can limit damage from a faulty oracle or contract, but they can also intentionally stop liquidation and allow price risk to accumulate. The relevant question is how the complete system behaves under simultaneous price, liquidity, network, and infrastructure stress.

Common misconceptions

Myth 1: Every protocol appoints one trusted keeper

Many protocols allow any address to liquidate. A named bot may be only one participant or interface provider. Its outage matters only to the extent that no substitute can execute.

Myth 2: An eligible position is already liquidated

Eligibility is a contract state; liquidation is a separate transaction or auction. Until that execution succeeds and the resulting debt and collateral are accounted for, market exposure remains.

Myth 3: Raising gas always fixes the failure

More transaction fees can improve inclusion priority, but cannot repair a stale oracle, a paused market, insufficient capital, missing allowance, changed account state, unprofitable collateral sale, or a contract revert.

Myth 4: Bad debt means lenders immediately lose the same amount

Bad debt first enters the protocol’s stated loss waterfall. Reserves or another backstop may absorb it. Lenders or governance token holders are affected only as the applicable rules and available resources dictate, and timing can differ from the moment the shortfall appears.

Sources

Health Factor & Liquidations - Aave (accessed: 2026-08-21)
Compound III Docs: Liquidation - Compound (accessed: 2026-08-21)
Liquidation 2.0 Module - Maker Protocol Technical Docs (accessed: 2026-08-21)