What is liquidation MEV, and how does it differ from the sandwich attack and just-in-time liquidity discussed earlier in this series?
The sandwich attack discussed earlier in this series involves an attacker actively intervening in a victim's execution price; just-in-time liquidity involves an extractor temporarily providing liquidity right before a large trade — both involve reacting to a specific about-to-happen transaction. Liquidation MEV addresses a completely different trigger scenario: not targeting a specific transaction, but a position that already meets liquidation conditions but hasn't yet been liquidated — anyone who submits the liquidation transaction first captures the protocol's designed liquidation reward (usually a percentage discount on the collateral).
This means liquidation MEV's competition isn't against a trade's originator — it's against every other potential liquidator simultaneously watching the same liquidatable position. This is a pure speed-and-gas-strategy race, different in complexity from the precise transaction-ordering skill a sandwich attack needs or the market-maker coordination just-in-time liquidity needs. Liquidation MEV's core logic is relatively simple: whoever's transaction gets packed first wins.
Why does liquidation MEV exist, and why do protocols design a liquidation reward mechanism at all?
A lending protocol needs a liquidation mechanism to promptly liquidate collateral and avoid the protocol bearing a bad-debt loss when a borrower's collateral value drops below what covers the debt — but the protocol itself usually doesn't proactively monitor every position and execute liquidations itself (which would require the protocol to bear extra operational and computational cost). Instead, it designs an economic incentive letting external participants voluntarily take on the monitoring and execution work, compensated with a liquidation reward.
This design itself is reasonable — using economic incentives to let decentralized third-party participants collectively maintain system health is a common mechanism-design approach in the DeFi ecosystem. But the side effect of this mechanism is giving rise to a highly specialized, highly automated liquidation bot industry — these bots monitor position status on every lending protocol around the clock, and once detecting any position falling below its liquidation threshold, can assemble and submit a liquidation transaction within an extremely short window. This level of specialization makes it nearly impossible for an ordinary user to compete manually.
How does liquidation MEV actually work, and specifically how do liquidation bots beat ordinary users?
A typical liquidation bot's workflow: continuously monitoring the health metric (usually the ratio of collateral value to debt value) of every position across multiple lending protocols, and the instant it detects a position's ratio has dropped below the liquidation threshold, immediately auto-assembling a liquidation transaction; to ensure its own liquidation transaction gets packed first, the bot typically sets an extremely high gas fee priority, or coordinates transaction ordering priority directly with a block builder through a private transaction pool discussed earlier in this series, avoiding being seen and overtaken by other bots in the public mempool.
Even if an ordinary user happens to notice a position meeting liquidation conditions at the same moment, the entire process from spotting the opportunity to manually assembling the transaction, setting the gas fee, and submitting it typically takes far longer than a bot's automated response time — this speed gap is nearly structural, not something a user can close through heightened vigilance or operational familiarity.
What's the practical impact of liquidation MEV for everyday users, and how should it apply to evaluating and using DeFAI products?
If you're a borrower on a lending protocol, liquidation MEV's most direct implication is a reminder that you need to factor liquidation bots' extremely fast response speed into your own position management — don't hold onto a false hope that you'll manually top up your position right before it gets liquidated, because the instant your position falls below the liquidation threshold, a liquidation bot will almost certainly discover and execute the liquidation faster than you can. The window you can genuinely intervene in is usually far shorter than you'd imagine.
If you're a user entrusting funds to a DeFAI agent to execute a lending strategy, it's worth asking whether this agent itself has liquidation-protection capability — proactively warning when position health approaches the threshold, or automatically adding margin to avoid genuinely triggering liquidation, for example. This kind of proactive defense design protects your funds far better than dealing with a liquidation loss after the fact. This is also a concrete application of a principle emphasized repeatedly throughout this series: understanding that a competition you can't participate in exists is itself the first step in protecting yourself.
Multiple public MEV data analytics platforms within the Ethereum ecosystem (dashboard services specifically tracking on-chain MEV activity, for example) have long publicly tracked the source of liquidation transactions on major lending protocols. This kind of public data has long shown that the vast majority of liquidation transactions are executed by a small number of continuously active automated addresses, rather than ordinary retail wallet addresses — a structural fact already openly discussed and widely recognized within the industry.
From an overall protocol-health perspective, liquidation MEV's existence lets lending protocols maintain a timely, reliable liquidation mechanism, avoiding accumulated bad debt harming every user's fund safety — a necessary positive effect of the mechanism's design; but this mechanism's side effect is that liquidation rewards are almost entirely monopolized by professional bots, with ordinary users unable to participate equally in this economic opportunity, meaning users must more proactively manage their own position health rather than relying on the chance to manually intervene and remedy things before liquidation happens.