Cross-Chain Liquidation Hunting: Monitoring and Execution

By DeFi Intel Research · Reviewed 2026-07-02 · 9 min read · advanced

Cross-chain liquidation hunting is the practice of scanning multiple blockchain networks for undercollateralized positions in decentralized lending protocols and executing liquidations to capture bonuses. Unlike single-chain hunting, this strategy demands monitoring disparate chains, each with its own liquidation mechanics, gas markets, and competition levels, to find profitable opportunities that others miss.

For advanced DeFi operators, cross-chain liquidation hunting offers higher yields due to less efficient markets on emerging L2s and sidechains. However, it requires a robust tech stack—from subgraphs and RPC endpoint management to automated execution scripts—and careful capital allocation across chains to cover gas and seize opportunities instantly.

What Is Cross-Chain Liquidation Hunting?

Cross-chain liquidation hunting refers to the systematic monitoring of lending protocol positions across multiple blockchains (e.g., Ethereum, Polygon, Arbitrum, Avalanche) to identify accounts whose health factor drops below 1, making them eligible for liquidation. The hunter then repays part of the debt and receives collateral at a discount (the liquidation bonus).

Unlike single-chain hunting, this approach considers chain-specific parameters: for example, Aave v3 on Polygon offers a 5% liquidation bonus, while Compound v2 on Ethereum uses an 8% bonus but a 50% close factor. Cross-chain hunters also factor in gas costs, confirmation times, and mempool congestion. Tools like The Graph subgraphs and DefiLlama APIs provide real-time data across chains, enabling hunters to aggregate health factors and spot opportunities.

Why Hunt Liquidations Across Chains?

Liquidation hunting across chains can be more profitable than focusing on a single chain due to several factors:

• Lower competition: Smaller chains (e.g., Polygon, Avalanche) often have fewer bots, meaning you can win more liquidations without being frontrun.
• Diverse liquidation parameters: Some protocols offer higher bonuses or different close factors that impact profitability.
• Cross-chain price discovery: Price differences between a collateral asset on different chains can cause health factors to diverge, creating unique opportunities that single-chain hunters miss.
• Capital efficiency: You can deploy smaller amounts of capital on several chains rather than one large pool, reducing risk and increasing fill rate.

For instance, a whale position using wETH as collateral on both Ethereum Aave and Polygon Aave may have a health factor of 1.01 on Ethereum but 0.95 on Polygon due to different oracle prices. A cross-chain hunter can liquidate the Polygon position before the Ethereum one stabilizes.

Core Lending Protocols to Monitor

Focus on protocols with high total value locked (TVL) and active borrowing to ensure a steady stream of liquidation events. Aave v3 on Arbitrum and Polygon are often the most active due to high retail activity, while Compound on Ethereum remains a classic target.

Understanding Liquidation Mechanics Per Chain

Each chain and protocol combination has subtle differences that affect profitability. For example:

• Health factor calculation: Aave uses a weighted average of collateral and debt in USD, while Compound uses a 0.8 threshold with a close factor that determines how much debt you can repay. On Compound v2, if a user has a health factor of 0.75, you can repay up to 50% of their debt; on Aave, you can liquidate up to 50% of the debt directly at a 5% bonus.
• Gas costs and block time: Ethereum blocks every 12–15 seconds, Arbitrum every ~0.25 seconds, Polygon every ~2 seconds. On faster chains, you need even lower latency to win liquidations.
• Liquidation bonus variability: On Aave, the bonus can differ by asset – stablecoins might have 5%, while volatile assets like CRV have 10%. Check the protocol's risk parameters via their markets page or the subgraph.

For a concrete example, consider a position on Aave Polygon where the borrower’s health factor drops to 0.98. The hunter must call liquidationCall with the debt asset and debt amount to cover (up to 50% of the total debt). The bonus is applied to the collateral asset returned, e.g., with 5% bonus on ETH, you get 1.05 ETH for every 1 ETH of collateral you claim.

Setting Up a Monitoring Stack

A reliable monitoring stack is crucial to catch liquidation opportunities. The typical architecture includes:

• Subgraphs: Use The Graph to query protocol subgraphs (e.g., Aave v3 on Polygon has a hosted subgraph). You can poll for users with health factors near 1.0. Advanced hunters stream changes via GraphQL subscriptions.
• RPC endpoints: Directly call contract methods like getUserAccountData on Aave or getAccountSnapshot on Compound. Use multiple providers (Alchemy, Infura, QuickNode) to reduce latency and avoid rate limits.
• DefiLlama API: For a high-level overview of liquidatable positions across chains, use DefiLlama’s liquidations endpoint (e.g., https://liquidations.defillama.com/v1/liquidations). This aggregates data from many protocols.
• Custom database: Store historical health factors to compute trends and predict upcoming liquidations.

Example: Set up a cron job on a server running Node.js that queries the Aave Polygon subgraph every 2 seconds, fetches the last 1000 users with healthFactor < 1.05, then locally calls the contract to get exact values and checks if healthFactor < 1.0. When found, trigger a liquidation transaction.

Building a Custom Liquidation Bot

To execute profitable liquidations, you need a bot that can act within blocks. Steps:

1. Connect to RPCs: Use ethers.js or web3.py with multiple endpoints per chain for redundancy.
2. Fetch user data: Continuously poll the protocol contracts for user account data (health factor, collateral, debt). Prioritize accounts with healthFactor closest to 1.0 where the debt is in a liquid asset.
3. Simulate liquidation: Estimate gas required and expected profit. For Aave, profit = collateralAmount * liquidationBonus - debtRepaid - gasCost. Only proceed if profit > minProfit.
4. Prepare transaction: Build the liquidation call (e.g., liquidationCall(…) on Aave) with the correct collateral asset, debt asset, user, and debtToCover.
5. Send transaction: Use Flashbots (on Ethereum) to avoid mempool frontrunning or standard txns on L2s. Monitor for inclusion and resend if necessary.
6. Manage nonces: On each chain, maintain a nonce manager to avoid duplicate liquidations.

For cross-chain, you’ll run separate bot instances per chain, each with its own wallet funded with the appropriate native token for gas.

Cross-Chain Execution Strategies

Executing liquidations across multiple chains requires careful strategy:

• Separate wallets per chain: Each chain needs its own funds for gas, plus capital to repay debt. A same-chain flash loan can supply the debt repayment atomically, but flash loans are single-chain only. For cross-chain, you can’t flash-loan from one chain to another; you need native capital on each chain to repay debt and collect collateral. So fund each chain’s wallet appropriately.
• Use keepers networks: Services like Chainlink Keepers or Gelato can automate liquidation tasks on multiple chains without running a 24/7 server. Set up a keeper job that calls a contract function to check for liquidations.
• Cross-chain communication: Some teams build cross-chain liquidators using LayerZero or CCIP to transfer funds between chains instantly, but this is advanced and still experimental. Most hunters use independent bots per chain.

For best results, prioritize chains with low competition and high gas limits, such as Arbitrum (low gas, fast blocks) and Polygon (moderate competition). Allocate at least 0.5 ETH worth of native token per chain to cover gas and any minimal debt repayment.

Risk Management and Capital Allocation

Cross-chain liquidation hunting is not risk-free. Key risks and mitigations:

• Failed liquidations: Another bot or the user themselves might repay before your transaction lands. Mitigate by monitoring the mempool and using priority fees.
• Collateral price volatility: The collateral you receive is discounted but can lose value before you sell. Hedge by immediately swapping to stablecoins or using a DEX aggregator.
• Gas waste: Polling and dry runs cost gas on some L2s. Optimize by using public subgraphs for filtering and only calling RPCs when a candidate is likely.
• Capital fragmentation: Spreading capital across many chains dilutes your ability to liquidate large positions. Start with 2-3 high-opportunity chains.

Reallocate capital weekly based on realized profits per chain. Tools like DeBank can show your cross-chain portfolio. Maintain a reserve on the highest profitability chain.

Comparison Table: Monitoring Approaches

Choose based on your budget and technical ability. Most advanced hunters use a combination: subgraphs for broad scanning and direct RPC for final confirmation and execution.

Common Mistakes and How to Avoid Them

• Ignoring chain-specific gas limits: Liquidations on Ethereum often get stuck due to high gas; use Flashbots to bypass mempool. On L2s, ensure you set adequate priority fees.
• Not handling liquidation bonus updates: Protocols can change bonuses via governance. Always check the current bonus on-chain before calculating profit.
• Overlooking cross-chain oracle delays: Prices may differ between chains due to oracle update frequencies. Use Chainlink’s feed to verify they are within tolerance.
• Underestimating competition: Even on smaller chains, MEV bots may arrive. Use private mempools (e.g., Bloxroute on Polygon) to increase success rate.

Future Trends: Cross-Chain Liquidation Automation

The future of cross-chain liquidation hunting lies in native cross-chain keepers and automation. Protocols like Chainlink CCIP and LayerZero enable smart contracts on one chain to trigger actions on another. Already, projects like DeFi Saver offer automated liquidation protection, but the inverse – automated liquidation hunting – is emerging.

Imagine a smart contract that monitors health factors across chains via oracles and automatically repays debt on one chain while claiming collateral on another using a single cross-chain transaction. This reduces capital requirements and latency. As these technologies mature, cross-chain liquidation hunting will become more efficient and accessible to capital-efficient funds.

Step-by-step

1. 1. Identify target chains (e.g., Ethereum, Polygon, Arbitrum) and lending protocols (Aave, Compound, Morpho) based on TVL and liquidation frequency.
2. 2. Set up real-time monitoring using The Graph subgraphs or DefiLlama API to track users with health factors below 1.05.
3. 3. Spin up a server with ethers.js or web3.py, connecting to multiple RPC endpoints per chain for redundancy.
4. 4. Fetch user account data (getUserAccountData for Aave, getAccountSnapshot for Compound) for identified candidates.
5. 5. Simulate the liquidation transaction: estimate gas, compute profit after bonus, and filter for minimum profitability.
6. 6. Prepare the liquidation call with correct parameters (debt to cover, collateral asset, user address) and sign the transaction.
7. 7. Submit the transaction via Flashbots (on Ethereum) or a private mempool (on L2s) to avoid frontrunning, using appropriate priority fees.
8. 8. Monitor chain for transaction inclusion and resend if not mined within a few blocks; track success/failures per chain.
9. 9. Rebalance capital across chains weekly, keeping a reserve in native tokens for gas based on historical gas costs.

Common mistakes to avoid

• Not accounting for cross-chain gas cost differences: Ethereum liquidations may require $20+ in gas, eating profits.
• Relying solely on subgraph data without validating on-chain – subgraphs can be stale by several seconds.
• Ignoring the impact of flash loans: without a flashloan, you need enough native capital on each chain to repay debt.
• Failing to update liquidation parameters (bonus, close factor) when protocols upgrade governance.
• Assuming same profitability across all assets – some have higher bonuses but also higher risk of slippage.
• Not using private mempools on chains that support them (e.g., Polygon via Bloxroute), leading to frontrunning.

Frequently asked questions

Related reading

• Chainlink Link Oracle Network
• How To Safely Bridge Tokens Cross Chain
• How To Verify Cross Chain Bridge Security
• Layerzero Zro Cross Chain Messaging
• Pyth Network Pyth Oracle
• Bridge
• Flash Loan
• Liquid Staking