MEVDAO

How Liquidation Bots Work on Aave (and Why They're Hard to Win)

By Merunas Grincalaitis · · 5 min read · 1 view

Liquidation bots are the most "respectable" kind of MEV bot. Lending protocols literally need them. If nobody closes bad loans, the protocol ends up with debt that nobody will repay, and depositors lose money. So the protocol pays a bonus to whoever does the work.

That sounds like free money, and it's one of the first strategies people try when they get into MEV. In practice it's one of the most competitive. Let me explain how it works, using Aave as the example, and where the difficulty really is.

How a loan becomes liquidatable

On Aave you deposit collateral, say ETH, and borrow against it, say USDC. Each collateral asset has a liquidation threshold, and the protocol combines your collateral, those thresholds and your debt into a single number: the health factor.

  • Health factor above 1: you're fine.
  • Health factor below 1: anyone can liquidate you.

The health factor moves when prices move. If ETH drops, your collateral is worth less, the health factor falls, and when it crosses 1 your position is open for liquidation. It also moves slowly as interest accrues on the debt.

What the liquidator actually does

The liquidator repays some or all of the borrower's debt, and in return receives the borrower's collateral at a discount. That discount is the liquidation bonus.

In Aave's current liquidation docs (written for Aave v4), the flow is:

  1. Find a position with a health factor below 1.0.
  2. Choose which debt reserve to repay and which collateral reserve to receive.
  3. Approve the debt token and call liquidationCall on the Spoke contract.
spoke.liquidationCall(
  collateralReserveId,
  debtReserveId,
  targetUser,
  debtToCover
);

A few details from those docs matter for a bot:

  • The bonus is a Dutch auction. In v4, the lower the health factor, the bigger the bonus. So there's a trade-off between liquidating early with a small bonus and waiting for a bigger one while someone else takes it.
  • Dust rule. If the debt left in a reserve after your liquidation would be under $1,000, you have to liquidate the whole debt in that reserve.
  • Gas has to be worth it. The docs say it directly: make sure the bonus is more than your gas costs. Lots of small positions just aren't worth liquidating on mainnet.

Earlier Aave versions use the same basic idea with a different interface (liquidationCall on the Pool contract, with a close factor that limits how much you can repay in one go), so always check the docs for the exact market you're targeting.

The bot's pipeline

Every liquidation bot I've seen has the same four parts.

1. A database of positions

You need to know every borrower, what they deposited, what they borrowed, and their health factor. You build this by indexing the protocol's events (deposits, borrows, repays, withdrawals, liquidations) from the deployment block onwards, then keeping it updated block by block.

You can't call the protocol for every borrower every block. There are too many of them. So most bots keep their own copy of the math and only re-check positions that are close to 1.

2. A price trigger

Most liquidations happen because a price moved. Aave's prices come from oracles (Chainlink-based feeds on most markets), not from DEX prices. So the oracle update is the event that makes a position liquidatable on-chain.

That's why the serious bots focus on oracle updates. If you know a price update is coming and you can calculate which positions it pushes under 1, you can prepare the liquidation and try to land it right after the update, in the same block. That's a backrun on the oracle transaction, and it's where most of the competition is.

3. Funding the repayment

To liquidate, you need the debt token. You can hold inventory, but most bots don't. They use a flash loan: borrow the debt token, repay the borrower's debt, receive the collateral, swap enough collateral back into the debt token on a DEX, repay the flash loan, and keep the rest. All in one transaction. If any step doesn't work out, the whole transaction reverts and you only lose gas (or nothing, if you send it as a bundle).

Aave itself offers flash loans, and so do other protocols. Uniswap's flash swaps work too. The choice mostly comes down to fees and which pool has the liquidity you need.

4. Execution

The liquidation goes into a bundle, together with the payment to the builder. If you're backrunning an oracle update, you need the update transaction in your bundle first. I wrote about the mechanics, including why bundles fail to land, in Flashbots bundles explained.

Why it's hard to win

Here's the uncomfortable part. Liquidations are public information. Every bot sees the same positions, the same oracle updates and the same health factors. When everyone sees the same opportunity, the winner is decided by the builder bid. And the bids go up until most of the profit is gone. The ethereum.org MEV page describes exactly this: in competitive MEV, searchers end up paying most of their profit to validators.

On top of that:

  • Gas efficiency matters. A bot that uses 50,000 gas less can bid more and still profit.
  • Big liquidations attract everyone. The obvious ones during a crash have dozens of bots competing.
  • Swap slippage eats the bonus. On a large liquidation, selling the collateral can move the DEX price a lot. Your simulation has to include it.
  • Collateral can be weird. Some collateral tokens have low DEX liquidity, transfer fees or special mechanics. Others need an extra step to unwrap.
  • Bad debt. If the price falls fast enough, the collateral may not cover the debt plus bonus, and the trade loses money.

Where solo developers still have a chance

Just like with arbitrage, the edge is in the places the big bots don't bother with:

  • Smaller lending protocols and forks. Same mechanics, much less competition. But do your homework on the oracle and the code, since forks sometimes have bugs or weird liquidation rules.
  • New markets. When a protocol launches a new market or chain, the bot landscape takes time to catch up.
  • Combined transactions. A liquidation plus an arbitrage on the pool you're selling into, in one transaction.
  • Better collateral routing. Finding the best path to sell an unusual collateral token, which other bots get wrong.
  • Non-price triggers. Positions that cross 1 because of interest, or because the protocol changed a parameter, rather than because of an oracle update.

How I'd start

  1. Pick one protocol and read its liquidation code and docs fully. Not a blog post, the code.
  2. Index historical liquidations and look at them. Who did them, how much they paid the builder, how much they kept.
  3. Write the contract: flash loan, liquidate, swap, repay. Keep it minimal and gas-optimized.
  4. Test it on a mainnet fork at the block before a historical liquidation, and check if your bot would have found it and profited.
  5. Go live with small size, measure what you win and lose, and improve from there.

If you want a liquidation bot built properly, for a specific protocol or as part of a bigger strategy, that's the kind of custom work I do. Send me a message on Telegram.

For the tools I sell ready-made, the Sniper Bot, Premium Sniping Group and Token Rescue Bot, check the MEVDAO features and pricing. And join the MEV Secrets email list right below for more breakdowns like this one.

← All articles