Skip to main content
The Liquidations view combines liquidation history with accounts that appear eligible from available data.

​
Candidates versus completed events

A candidate has debt and a displayed health factor at or below 1.1. Execution still requires up-to-date oracle data, recognized assets, liquidator funds and allowances, available external paths, and a transaction that fits resource limits. Plain collateral pricing failure can block liquidation. A completed Trader_Liquidate_Event indicates that the manager liquidation transaction executed. It does not mean the SmartAccount was deactivated or that every unknown debt symbol was cleared. Check current account state when interpreting outcomes.
Liquidation candidate table with Stellar addresses, health factor, debt, and collateral

Historical candidate table for orientation. Eligibility must be checked again against current account and oracle state. Click the image to zoom.

​
Proceeds

Current liquidation repays recognized debt from the liquidator, exits Blend collateral to them, transfers LP tokens, and sweeps direct collateral. LP receipt proceeds are not necessarily realized underlying tokens at that moment. History may be delayed or incomplete across Mercury/RPC sources. Use the transaction hash and current state for confirmation. A dashboard bad-debt label is a derived condition, not proof that losses have been written off in lending-pool accounting. See Liquidation and Bot Integration.