Liquidation MEV

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.

清算MEVは実際どのように機能し、清算ボットは具体的にどう一般ユーザーに勝つのですか？

典型的な清算ボットの動作フローは次の通りである：複数の貸出プロトコルにわたる全てのポジションの健全性指標（通常は担保価値と負債価値の比率）を継続的に監視し、あるポジションの比率が清算閾値を下回ったことを検知した瞬間、直ちに自動的に清算取引を組み立てる。自身の清算取引が最初にブロックに組み込まれるようにするため、ボットは通常極めて高いガス代の優先度を設定するか、本シリーズで前述したプライベートトランザクションプールを通じて、ブロックビルダーと直接取引の優先順位を調整し、公開mempool内で他のボットに見られて先を越されることを避ける。

一般ユーザーがたまたま同じタイミングで清算条件を満たすポジションに気づいたとしても、機会を発見してから手動で取引を組み立て、ガス代を設定し、取引を送信するまでの全プロセスにかかる時間は、通常ボットの自動化された反応時間よりもはるかに長い。この速度のギャップはほぼ構造的なものであり、ユーザーが警戒心を高めたり操作に習熟したりすることで埋められるものではない。

清算MEVは一般ユーザーにどのような実際の影響を与えますか？DeFAI製品の評価と利用にどう応用すればいいですか？

もしあなたが貸出プロトコルの借り手であれば、清算MEVがあなたに与える最も直接的な影響は、「清算ボットの反応速度は極めて速い」という事実を自分のポジション管理の考慮に組み込む必要があることを思い出させてくれることである——「ポジションが清算されそうになったら手動で追加担保を入れる」という楽観的な期待を持たないことだ。なぜならあなたのポジションが清算閾値を下回ったその瞬間、清算ボットはほぼ確実にあなたより速く発見し清算を実行するからだ。あなたが本当に介入できる時間の窓は、通常想像よりもはるかに短い。

もしあなたが資金をDeFAIエージェントに委託して貸出戦略を実行させているユーザーであれば、このエージェント自体が清算保護機能を備えているか尋ねる価値がある——ポジションの健全性が閾値に近づいた際に事前に警告する、または本当に清算をトリガーすることを避けるために自動的に証拠金を追加するなど。このような能動的な防御設計は、事後に清算による損失に対処するよりもあなたの資金をよく保護してくれる。これも本シリーズで繰り返し強調してきた原則のここでの具体的な応用である：自分が参加できない競争が存在することを理解すること自体が、自分を守るための第一歩である。