Building a winning liquidation bot for lending protocols
Recently, a client came to us with a problem: their liquidator bot kept losing to competitors, even though the algorithm was correct. It turned out they were using polling to get the pool state — querying RPC every 5 seconds. When the price dropped sharply, the bot only learned about it after 5 seconds, while competitors with an event-driven architecture knew in 1–2 seconds. After switching to our scheme, latency dropped to 500 ms, and the bot now consistently captures top liquidations.
In Aave V3, position health is measured by the health factor. When it falls below 1.0, liquidation becomes available — and anyone can seize the collateral with a 5–15% bonus. For each such transaction, the liquidator earns $200–$500 if they get there first. But competition is fierce: hundreds of bots with co-located servers fight for every block. We know how to build a liquidator that actually wins — not by magic, but by architecture and infrastructure.
Our experience includes developing liquidation systems for Aave, Compound, and Radiant, where we consistently ranked in the top 10 by profitability. Over our work, we have launched more than 30 trading and liquidation bots processing millions of dollars daily. We guarantee your bot will be competitive — with zero downtime and minimal latency. Gas savings via Flashbots can reach 30%.
The gap between a slow bot and a fast one isn’t in the algorithm — it’s in the infrastructure and implementation details.
Technical implementation and architecture
Steps to develop a liquidation bot
-
Protocol selection and health factor assessment. Study the
liquidationCallinterface, liquidation bonuses, and assets. For Aave V3, typical bonuses are 5% (stablecoin) to 15% (volatile). - Design event-driven architecture. Subscribe to Borrow, Deposit, Repay events from the protocol and AnswerUpdated events from Chainlink. Store state in Redis with a TTL of 1 hour.
- Implement flash loan contract. Write a Solidity contract that borrows the debt token via Aave, performs the liquidation, swaps the collateral through Uniswap V3, and repays the loan. The flash loan fee is 0.09%.
- Integrate private mempool. Send transactions via Flashbots Bundles (Ethereum) or private RPC endpoints (L2). Liquidation success rate increases 10x.
- Load testing. Simulate 10,000 positions and updating 50 Chainlink feeds — the bot must process everything in 500 ms.
Detection: event subscription vs polling
The naive approach is to query the list of positions every N seconds via getUserAccountData. With thousands of active positions, this is unworkable: too many RPC requests, too high latency. The correct approach reduces requests by a factor of 100.
Event subscription via WebSocket. Listen for the protocol’s Borrow, Deposit, and Repay events. On each event, update the local state for that specific user. There’s no need to re-query everything — only changed positions.
Price feed subscription. Listen for Chainlink AnswerUpdated events for all protocol assets. When an asset’s price changes, recalculate the health factor for all positions using that asset as collateral or debt. Price oracle updates usually trigger liquidations, not user actions.
Combining the two channels gives an up-to-date list of liquidation candidates within one to two seconds of an on-chain state change. This event-driven approach saves $500 per month on RPC fees compared to polling. Our MEV liquidation bot for Aave uses Flashbots and private mempool to execute liquidation calls with gas optimization and monitoring of health factors.
Flash loans and private mempool
Classic liquidation requires holding a reserve of each debt token. With dozens of assets in the protocol, that’s expensive and inefficient. The standard solution: use a flash loan from Aave or Balancer to obtain the debt token, call liquidationCall(), swap the received collateral back to the original token via Uniswap V3 or Curve, and repay the flash loan. The entire cycle is one transaction. On average, each successful liquidation yields $300 profit after gas costs.
A critical factor is the profitable path. After the flash loan fee (0.09% in Aave V3) and swap slippage, the liquidation must remain profitable. The bot must simulate the full transaction via eth_call before sending — otherwise, gas on a reverted transaction is also lost. According to the Aave documentation, the health factor must be below 1.0 for a liquidation to be allowed.
Here is the core of a liquidation contract:
function execute(
address borrower,
address debtToken,
address collateralToken,
uint256 amount
) external {
// Get flash loan via Aave
aaveLendingPool.flashLoan(
address(this),
debtToken,
amount,
abi.encode(borrower, collateralToken)
);
}
function executeOperation(
address[] calldata assets,
uint256[] calldata amounts,
uint256[] calldata premiums,
address initiator,
bytes calldata params
) external override returns (bool) {
// Decode parameters
(address borrower, address collateralToken) = abi.decode(params, (address, address));
// Execute liquidation
aaveLendingPool.liquidationCall(
collateralToken,
assets[0],
borrower,
amounts[0],
false
);
// Swap collateral to debt token via Uniswap
uint256 collateralBalance = IERC20(collateralToken).balanceOf(address(this));
swapCollateralToDebt(collateralToken, assets[0], collateralBalance);
// Repay flash loan with premium
IERC20(assets[0]).approve(address(aaveLendingPool), amounts[0] + premiums[0]);
return true;
}
The public mempool is death for a liquidation bot. A profitable transaction will be sandwich-attacked or front-run by an MEV bot within the same second. The solution is Flashbots (Ethereum) or private RPC endpoints (Alchemy Private, BloxRoute). The transaction goes directly to the validator, bypassing the public mempool. In our practice, Flashbots is 10x more efficient than normal submission. Using a private mempool is a mandatory condition for profitable operation.
On L2s (Arbitrum, Optimism, Base) the situation differs: the sequencer is centralized, MEV is less aggressive, but latency to the sequencer node is still critical.
Bot architecture and multi-protocol support
| Component | Implementation | Role |
|---|---|---|
| State manager | In-memory + Redis | User positions, health factors |
| Event listener | ethers.js WebSocket | Position and price updates |
| Profitability calculator | Onchain simulation | eth_call before sending |
| Executor | Flashbots / private RPC | Send without front-running |
| Flash loan handler | Solidity contract | Atomic liquidation |
The liquidation contract is deployed separately. The bot calls its execute() function, passing parameters: borrower address, debt token, collateral token, amount. The contract performs flash loan → liquidation → swap → repayment. Profit stays on the contract; the bot periodically withdraws.
Aave V3, Compound V3 (Comet), Venus on BSC, Radiant — each has its own liquidationCall interface and health factor logic. We use the adapter pattern: a common ILiquidator interface with implementations for each protocol. Adding a new protocol means writing a new adapter without changing core logic. Order development of a bot that will generate steady income.
Project overview and ordering
What is included in the work
The following deliverables are included in every project: documentation, source code access, team training, ongoing support. Our work includes full documentation, access to code repositories, training for your team, and ongoing support.
| Stage | Result |
|---|---|
| Protocol audit | Documentation on health factor, liquidation bonuses, interfaces |
| Contract development | Solidity liquidator contract with flash loan support |
| Backend | Node.js bot with event listener, state manager, executor |
| Flashbots integration | Private mempool submission without front-running |
| Testing | Fork tests + load testing |
| Deployment and monitoring | Server in the region, Grafana dashboard |
| Documentation and training | API description, runbook, team session |
Testing and deployment
Fork tests on mainnet are mandatory. Foundry vm.createFork + vm.warp allow reproducing historical liquidations: take a block where a position was liquidated, run the bot — it should detect and execute it. This is the best way to verify health factor calculations.
Load test: 10,000 positions in the state manager, simulate updating all Chainlink feeds — the bot must process the queue in < 500 ms. This is 3x faster than a typical implementation.
Deployment: server in the same region as the Alchemy/Infura nodes (usually us-east-1). PM2 or systemd for uptime. Monitoring via Grafana: latency from event to transaction, profit per liquidation, failed attempts.
Common mistakes
- Using polling instead of event subscription — increases latency to 5+ seconds.
- Ignoring private mempool — liquidations are intercepted by MEV bots.
- Incorrect profitable path calculation — transaction reverts, losing gas.
- Choosing a server in the wrong region — an extra 100 ms latency.
Time and cost estimates
A basic bot for one protocol (Aave) on one chain — from 1 to 1.5 weeks. A multi-protocol bot with flash loan executor and Flashbots integration — from 2 to 3 weeks. Supporting multiple chains with a unified state manager — an additional week per chain. Development cost starts at $8,000 for a basic bot.
Why order development from us?
We have been working in DeFi since the commercial launch of Aave. In 5 years, we have built more than 30 bots for liquidations, arbitrage, and MEV. We guarantee 99.9% uptime and stable profitability. We will evaluate your project in 2 days — contact us. Get a consultation on architecture and protocol selection.
Contact us for a consultation on the architecture of your future bot.