Why a "Faster" Bot Doesn't Win Liquidations
Everyone optimizing a liquidation bot starts in the wrong place: latency. I measured the actual contest on Aave V4 mainnet across weeks of live operation. Here's the mechanism nobody explains — and why a quicker VPS changes almost nothing.
The two-step contest
A liquidation is won in two distinct steps, and people conflate them constantly:
- Detection — noticing that a position has crossed below its liquidation threshold.
- Inclusion — getting your transaction into the block that acts on it.
Latency only touches the first step, and only barely. The money is decided in the second — and the second step is not a race in the sense you think it is.
Detection: cadence beats milliseconds
To "see it first" you don't need a faster machine, you need a better cadence and coverage:
- Streaming over polling. A bot subscribed to new blocks / oracle updates learns about a state change the moment it lands. A bot polling every N seconds is structurally behind no matter how fast its CPU is. The lever is the architecture of how you watch, not clock speed.
- Watching the right set. Most positions never get close to liquidation. Maintaining a small "hot set" of near-threshold accounts and re-checking those aggressively beats re-scanning the whole book slowly. On our stack this collapsed ~689 sequential reads per cycle into ~2 batched multicalls — a coverage/efficiency win, not a "we bought a faster server" win.
Once two bots both detect the event in the same block, detection is a tie — and the contest moves entirely to inclusion.
Inclusion: it's an auction, not a footrace
Here is the part that breaks the "fast bot wins" intuition. On Ethereum, the transactions in a block are ordered by the block builder, and the builder orders by priority fee (the bid), not by arrival time. You can send your transaction 500 ms earlier than a competitor and still lose to them because they bid 1 gwei more. Your packets racing across the internet 50 ms quicker are irrelevant if you lose the fee auction inside the block.
So the real levers for inclusion are:
- Your bid — the priority fee / builder tip you'll pay out of the liquidation bonus.
- Your orderflow path — sending privately to builders / via an auction so you're not just shouting into the public mempool where you get front-run anyway.
- Whether there's an inclusion race at all — the most important lever and the one almost nobody thinks about.
What the data actually showed
I ran this live on Aave V4 mainnet. The pattern was consistent:
- Leader share around 0.67 on the short windows. The entrenched, funded bots took roughly two-thirds of the fast 1–3 block opportunities.
- A smaller player only won the long-tail windows — the ones the leaders didn't bother contesting (too small, too awkward, or already cleared to a safe level).
Read that again: the small player didn't win by being faster. It won by being present in the windows nobody was fighting over. Speed never entered into it.
The actual strategy that follows
If inclusion is a fee/orderflow auction, then "make the bot faster" is optimizing the wrong variable. The strategies that actually change outcomes are:
- Bid intelligently out of the bonus — model the competitor's likely tip and the residual profit, and only pay up when the math survives.
- Use private orderflow so you're not leaking your intent to the mempool.
- Pick venues without an inclusion race. This is the big one. A Dutch-auction venue like Ajna has no inclusion race — the winner is whoever prices the strike best over a 72-hour window, not whoever lands a block first. OEV mechanisms similarly replace the latency/orderflow race with a sealed bid. The honest catch — which I measured separately — is that those venues are currently either thin on flow or recapture most of the value for the protocol.
The takeaway
"My bot is fast" is a vanity metric in liquidations. The contest is detection cadence (an architecture choice) plus inclusion economics (a bidding/orderflow choice) — and the single biggest win is choosing venues where the inclusion race doesn't exist at all. Anyone selling you a "low-latency liquidation bot" as the edge is selling you the wrong variable.