Building an Aave Liquidation Bot: Net Profit and Execution Risk

Binance

19 October 2026

By 2026, it is already very hard to build a consistently profitable Aave liquidation bot on Ethereum mainnet by simply rushing into every liquidation opportunity. What really decides your net profit is not the liquidation bonus itself. It is how much of that bonus you can keep after paying the block builder. In one real on-chain liquidation, a bot covered about $11,800 of debt and earned a gross bonus of about $615, but ended up keeping almost nothing. If you enter this game only looking at the bonus number, you will most likely be working for the infrastructure.

Binance Exchange
The world's largest cryptocurrency exchange by trading volume,leading in security and liquidity.
New user benefit: Enjoy 20% off trading fees upon registration!

Do the math first: the bonus is not your income

Aave's liquidation bonus is the reward paid to the liquidator, but several layers are deducted before it actually reaches you. Take one liquidation with WETH collateral and USDT debt as an example. The data comes from a reproducible on-chain trace shared on the Aave governance forum:

Item	Amount
Debt covered	$11,809
Collateral seized (5.0502 WETH)	$12,424
Gross bonus	$614.56 (about 5.20% of debt)
Received after exit swap	$531.90
Paid to block builder	$530.10 (99.66% of post-execution value)
Final amount kept	$0.00

The part paid to the builder is essentially the bid for the right to liquidate. In this case, the winner won because its swap route was slightly cheaper, allowing it to bid about $10 more than the second-place competitor. The competition happens on post-execution value, not on the gross bonus. If your route is more expensive than your competitor's, you will not win even if you see the opportunity.

This structure means that atomic liquidation bots using flash loans have their profit margins compressed to nearly zero by bidding. Another comment on the Aave governance forum put it bluntly: using your own funds can squeeze out a small edge through cost advantages, but with flash loans plus swaps, after slippage and bidding eat the profit, "doing this every day is actually impossible to make money." Profitable windows are concentrated in periods of violent market volatility, when dozens or hundreds of liquidatable positions appear at the same time and large players cannot take them all. Only then is there room for small and medium bots.

The bonus ratio itself varies by asset and cannot be calculated with one number

Different collateral assets have different liquidation bonuses, and these can change through governance. Historical or current parameters for common assets on Aave V3 roughly include: wstETH about 6%, WETH about 5%, WBTC on Polygon was once proposed to increase from 7% to 8.5%. The cbBTC bonus on Base was once lowered from 7.5% to 6%.

For net profit calculations, these differences directly affect whether you can cover your costs. Using the 6% wstETH bonus as an example, the theoretical break-even slippage with no holding cost is about 6% / 1.06 ≈ 5.66%. That is before deducting protocol fees, gas, funding costs, and the builder bid. If your swap route slippage is close to that number, your actual profit is already gone.

Execution risk: more than just "not being faster than others"

Losing the bid does not mean losing money directly. It means wasting gas and reconnaissance costs. Your bot spends money scanning the chain, calculating health factors, and constructing transactions. If your bid loses to a competitor and the transaction reverts or the auction fails, those costs cannot be recovered. Under the SVR (Supplier Validator Rebate) mechanism, the bidding window is somewhat wider, reaching about 12 seconds on mainnet, but the nature of competition has not changed: you still need to decide how much to bid before knowing what others are bidding.

A position whose health factor has just fallen below 1 has a limited liquidation amount. Aave V3 rules state that when the health factor is between 0.95 and 1, a single liquidation can cover at most 50% of the debt. Only below 0.95 can you liquidate 100% at once. This means that for a position that has just crossed the line, the reward base you can receive is only half of the debt. If your fixed costs such as gas, infrastructure, and monitoring are estimated based on a full position, your actual profit margin will be cut in half. But if you wait until the position falls below 0.95, faster bots may beat you to it.

Oracle or configuration anomalies can create "fake opportunities" and also cause real losses. In March 2026, Aave experienced a misalignment in the snapshot parameters of the CAPO oracle module, causing wstETH to be systematically undervalued by about 2.85%. As a result, 34 accounts were liquidated without any market crash. For liquidation bots, this kind of event means many positions suddenly "become liquidatable," but if you bid or swap under wrong price assumptions, you may grab positions with negative returns. These anomalies cannot be predicted. You can only filter them out by setting price deviation checks and minimum profit thresholds.

If you still want to build one, where should you start

Step one: backtest with historical data instead of calculating with current parameters alone. Check recent liquidation records for Aave V3 on Ethereum mainnet on Dune or other on-chain data platforms. Look at the distribution of actual liquidated debt sizes, bonus amounts, and whether multiple liquidators competed in the same block. Bitquery analysis shows that in 2026 the median liquidated debt on Ethereum has fallen to about $80. Most small liquidations happen in old markets such as V1/V2 and Compound v2, while the median liquidation size in Aave's current market is still above $2,000. If your strategy targets small positions, gas costs will eat most of the bonus.

Step two: treat bidding cost as the first-priority variable, not as a deduction made afterward. Your net profit formula should be: gross bonus − swap slippage − gas − protocol fees if any − builder bid = retained value. In an atomic liquidation architecture, the builder bid will tend toward the post-execution value minus your cost advantage. You need to be clear about where your cost advantage lies: a cheaper swap route, more accurate gas estimation, or lower scanning latency. Without at least one of these advantages, your retained value will most likely be zero.

Step three: set hard skip conditions. At minimum, include: do not touch positions with health factor above 0.98 because the liquidation amount is too small and the borrower may repair it; do not touch positions whose estimated gross bonus is below a multiple of your fixed costs; manually review or skip positions where the oracle price deviates from the market price beyond a threshold. These conditions will reduce the number of "opportunities" you see, but they can prevent negative-return executions.

Step four: accept that this is not a stable income. The judgment given by practitioners in the Aave governance forum discussion is that it is basically impossible to make money on a daily basis. Profitable windows only appear when the market moves violently and liquidation opportunities appear in batches. If your expectation is to generate positive cash flow every day, that expectation itself needs to be adjusted. A more realistic approach is to treat it as a system that must respond quickly during event-driven moments. Maintain monitoring and infrastructure during normal times, and execute intensively when volatility arrives.

Completion standard: what counts as "worth continuing to invest"

It is not "the bot can successfully call liquidationCall." Instead, it is this: during a backtest period with real liquidations, after deducting gas and builder bids, the number and amount of positive retained-value outcomes must cover your infrastructure costs such as servers, RPC, monitoring, and development maintenance, and still leave a profit. If the backtest shows that the median retained value is close to zero or negative, the marginal return of continuing to optimize code is very low. At that point, it is more worth checking whether you have a verifiable cost advantage, rather than whether your liquidation logic itself is written correctly.