How Shared Collateral Can Be Liquidated Across Chains

Shared collateral can support borrowing on several blockchains, but liquidations need a single, current view of the borrower’s total risk. Without it, one chain may sell collateral while another still treats the same value as available to cover debt.

In a typical lending market, a position becomes liquidatable when its collateral no longer covers its debt under the protocol’s risk rules. Aave’s documentation describes this model: a liquidator repays part of a borrower’s debt and receives collateral, usually with a bonus. Across chains, the hard part is making that familiar process work when messages take time and transactions cannot settle together.

How does shared collateral work across chains?

A shared system tracks a borrower’s deposits and debts in one risk ledger, even when the assets sit on different chains. The ledger can be a contract on one chain, or a coordinated set of contracts that send updates to each other. In either case, each chain needs to know which assets count, what they are worth, and whether any have already been pledged or seized.

Suppose a borrower deposits an asset on one chain and borrows a stablecoin on another. The protocol records the deposit, sends a verified message that makes the collateral available to the borrowing market, then updates the ledger when the borrower takes on debt. For more on the message security, timing and fee questions behind this design, see this guide to checking omnichain messages before using them.

The key rule is that the same deposit cannot secure two positions at once. A protocol must reserve collateral as soon as it backs a loan, and release that reservation only after repayment or a confirmed liquidation.

What happens when a cross-chain position becomes unsafe?

The protocol compares the value of all eligible collateral with the debt, using its chosen price feeds and liquidation thresholds. If the position falls below its limit, a liquidator must repay debt and receive collateral. The decision should use one agreed record of balances, prices and pending actions; separate chain balances alone cannot show the whole position.

There are two broad ways to execute the sale. A protocol can send a liquidation instruction to the chain holding the collateral, then wait for confirmation before updating debt elsewhere. Or it can keep funds or liquidation capacity near each market so a local transaction can act quickly, then reconcile the shared ledger afterward. The first reduces idle reserves but depends on message delivery. The second can react faster but ties up capital and needs strict checks against duplicate claims.

Cross-chain messages are asynchronous: one chain can finish its transaction before another receives or acts on the update. LayerZero’s documentation describes cross-chain workflows as separate steps, with follow-up actions that may be handled in later messages. A liquidation design therefore needs to cope with delays and failed calls, not assume one transaction can settle every chain at once.

What should a liquidation system check?

Before enabling shared collateral, builders and users should be able to verify the rules that decide whether a position is safe and how a liquidation completes. A practical review should cover:

• Which chains and assets count toward collateral, and how their prices are updated.
• How the protocol prevents one deposit from backing multiple debts.
• What happens if a message arrives late, arrives twice, or cannot be executed.
• Where liquidators get the funds to repay debt, and whether the seized collateral can be sold locally.

For most designs, the safer trade-off is to let a liquidator act where the debt or collateral is available, while keeping shared balances locked until the other chain confirms the result. That can leave a position exposed during a delay, so thresholds and reserves must account for the time messages take. The benefit is a clear path to unwind debt without pretending that several blockchains share one instant transaction.