Note: when ETH drops 15% in an hour, hundreds of positions simultaneously cross the liquidation threshold. The first liquidator to call absorb captures discounted collateral assets. The second gets nothing. This is a competitive environment measured in milliseconds: Compound liquidations are captured by MEV bots with direct connections to builders and custom Rust implementations. Our team, with over 7 years of experience in DeFi and having developed over 40 trading and liquidation bots, builds solutions that work in this environment. Average profit per successful liquidation is $150–250, and gas savings compared to naive approaches reach 35–45%.
Compound v3: A New Approach to Liquidations
According to Compound v3 (Comet) documentation, liquidation occurs in two steps: absorb and buyCollateral.
Compound v3 (Comet) differs significantly from v2 in its liquidation model. In v2, there was liquidateBorrow — the liquidator repays the borrower's debt and receives their collateral with an 8–15% bonus. In v3, a two-step model is introduced: absorb and buyCollateral. Profit on v3 liquidations comes from the arbitrage between the purchase price from Comet and the market price. The bot must atomically: call buyCollateral, sell the obtained asset on a DEX, and return the base token. Flash loans from Aave or Uniswap v3 for financing are a standard pattern.
How to Identify Insolvent Positions in Real Time?
A position is insolvent when the borrowing capacity falls below the debt. Compound v3 provides isLiquidatable(address account) and getBorrowableOf(...). Polling hundreds of thousands of positions via eth_call is impractical. An effective approach is event-based monitoring: listen for Supply, Withdraw, Transfer events from Comet, update a local copy of states. When the collateral price drops (Chainlink AnswerUpdated event), recalculate the health factor for positions with that collateral. The data structure is a sorted set in Redis by health factor, allowing O(log n) lookup of positions closest to liquidation.
| Parameter | Naive | Optimized |
|---|---|---|
| Detection | Polling every 12 sec | WebSocket + event-based (3x faster) |
| Submission | Public mempool | Flashbots bundle |
| Gas price | Fixed | Dynamic (80th percentile + boost) |
| Execution | EOA transaction | Liquidation contract (1 tx) |
Bot Architecture
Position Monitoring
Monitoring Details
Two levels: The Graph subgraph for historical data, WebSocket subscription via ethers.js provider.on or viem watchContractEvent for real-time. The subgraph updates with a 1–3 block delay — sufficient for competitive liquidations. Chainlink price feeds via AggregatorV3Interface with updatedAt staleness checks.
Liquidator Smart Contract
Atomic liquidation via flash loan:
contract CompoundLiquidator { function liquidate( address comet, address[] calldata accounts, address collateralAsset, uint baseAmount, address flashLoanPool // Uniswap v3 pool ) external { // 1. Flash loan base token from Uniswap v3 // 2. absorb(address(this), accounts) // 3. buyCollateral(collateralAsset, minOut, baseAmount, address(this)) // 4. Swap collateral -> base token via DEX // 5. Return flash loan + fee // 6. Profit goes to msg.sender or treasury } } A critical detail: absorb and buyCollateral are two separate calls. Between them, another bot could buy the collateral. You must either check available collateral before purchase (quoteCollateral) or accept that in rare cases the transaction reverts.
Profitability Filter
Not every liquidatable position is profitable. Before submitting a transaction, calculate: profit = buyCollateralValue * (1 - storeFrontPriceFactor) - flashLoanFee - gasCost - swapSlippage
If profit < threshold (usually $50–100 considering risk), skip.
How We Build an Efficient Bot?
- Analyze Compound v3 architecture and deploy a test environment (Goerli/Sepolia).
- Develop event-based monitoring with Redis and health factor calculator.
- Implement liquidator smart contract with flash loan.
- Comprehensive testing on a mainnet fork.
- Deploy and configure monitoring (alerts, logs).
- Documentation and source code transfer.
Atomicity of Calls Is Critical
Separate absorb and buyCollateral calls create a window for frontrunning. Another MEV bot could notice the Absorb event and intercept the collateral purchase. Atomicity in a single transaction (via an aggregator contract) eliminates this risk.
Common Mistakes and Their Solutions
| Mistake | Solution |
|---|---|
| Ignoring cooldown after absorb | Retry logic with backoff |
| Incorrect minimum output calculation | Dynamic calculation based on oracle price with 1–2% buffer |
| Not checking protocol reserves | Check getReserves() before sending |
| Lack of atomicity | Use an aggregator contract for a single call |
What Is Included in Development?
- Full audit of the liquidation model and writing of the liquidator smart contract (Solidity, with Foundry tests).
- Monitoring service in TypeScript or Rust with event-based subscription and Redis.
- Integration with Flashbots for private mempool.
- Testing on a mainnet fork and dry-run on mainnet.
- Deployment and configuration of alerts (Telegram, Slack).
- Documentation and source code transfer with explanations.
- Support for one month after launch.
Timeline and Cost Estimates
A basic bot for Compound v3 on a single chain takes 2.5–3 weeks. A multi-protocol bot (Compound + Aave + Euler) with MEV optimization — 6–8 weeks. Implementation for Arbitrum/Base adds 1 week per chain. Cost is calculated individually; we provide a project estimate within 2 days.
Contact us for a preliminary estimate of your project — gain a competitive advantage in the liquidation market. We guarantee quality and adherence to deadlines. Get a consultation on configuring an MEV bot.