Real-Time MEV Monitoring: Why It Matters and What to Track

Published on Sat Aug 22 2026 00:00:00 GMT+0000 (Coordinated Universal Time) by Jacob Cavazos

What Is MEV

Maximal Extractable Value, originally called Miner Extractable Value, is the profit that can be extracted by reordering, including, or censoring transactions within a block. The term was introduced in a 2019 paper by Philip Daian et al. titled “Flash Boys 2.0: Frontrunning in Decentralized Exchanges, Smart Contracts, and Blockchains.” The paper demonstrated that MEV is not a theoretical concern. It is a measurable, persistent phenomenon on every major blockchain.

MEV exists because block producers — miners in proof-of-work systems, validators in proof-of-stake systems — have the authority to choose which transactions to include in a block and in what order. This authority has economic value (see our guide on what MEV is and how to protect against it for the full taxonomy). If a large swap is pending in the mempool, a searcher can submit a transaction that front-runs the swap, buying the asset at the current price, then another transaction that back-runs the swap, selling the asset at the inflated price. The difference is profit. The original swap pays for it through worse execution.

The total MEV extracted from Ethereum alone is measured in the hundreds of millions of dollars annually. Public dashboards from EigenPhi, Flashbots, and other analytics providers track this in real time. The extraction is not slowing down. It is increasing as DeFi grows and as more sophisticated searchers enter the market.

Why Real-Time Monitoring Matters

MEV extraction happens in milliseconds. The window between a transaction entering the mempool and that transaction being included in a block is measured in seconds — sometimes less. On Base, where block times are 2 seconds, the window is extremely tight. On Ethereum, where block times are 12 seconds, the window is slightly longer but the competition is more intense.

If you are monitoring MEV after the fact — reviewing transactions at the end of the day, or analyzing weekly reports — you are monitoring history. You are documenting what happened. You are not preventing it. You are not responding to it. You are not adjusting your strategy in real time to minimize exposure.

Real-time monitoring matters because it gives you visibility while there is still time to act. If you can see that your pending swap is being targeted by a sandwich bot, you can cancel the transaction. If you can see that the mempool is congested with front-running activity, you can delay your swap until conditions improve. If you can see that a specific searcher is consistently extracting value from your transactions, you can adjust your routing, your slippage tolerance, or your execution venue.

The alternative is blind execution. You submit a transaction. It executes. You receive less than you expected. You check the block explorer. You see that your transaction was sandwiched. You cannot undo it. You can only note it and hope it does not happen again. This is the experience of most DeFi users. It does not have to be.

The Three Forms of MEV Extraction

To monitor MEV, you need to understand the three primary forms it takes. Each form has a different signature in the mempool and on-chain.

Sandwich attacks. This is the most common and most damaging form of MEV for retail and institutional traders. A sandwich attack involves two transactions that bracket the victim’s transaction. The attacker’s first transaction buys the asset before the victim, pushing the price up. The victim’s transaction executes at the inflated price. The attacker’s second transaction sells the asset at the inflated price, capturing the difference. The victim pays for the attacker’s profit through worse slippage. The signature is three transactions in the same block, in sequence: buy, victim swap, sell. The buy and sell are from the same address or related addresses. The victim swap is in the middle.

Front-running. This is a broader category. Front-running occurs when a searcher copies a pending transaction and submits a similar transaction with a higher gas price to ensure it executes first. The searcher benefits from the price movement that the original transaction would have caused. The original transaction executes at a worse price because the searcher’s transaction moved the market first. The signature is two transactions in the same block targeting the same pool, with the front-runner’s transaction ordered before the original.

Back-running. This is the least harmful form of MEV from the user’s perspective. Back-running occurs when a searcher submits a transaction immediately after a large swap to capture the price impact. The large swap moves the pool price. The back-runner arbitrage the price back toward the market price, capturing the difference. The original swap is not directly harmed — it already executed at its expected price. But the back-runner profits from the price impact that the original swap created. The signature is two transactions in the same block, with the back-runner’s transaction ordered after the original.

What to Track

Real-time MEV monitoring requires tracking several data streams. Each stream provides a different signal.

Mempool Transactions

The mempool is the pool of pending transactions that have been submitted to the network but not yet included in a block. On Ethereum, the public mempool is accessible through several endpoints. On Base, the mempool is more opaque because Base uses a centralized sequencer, but pending transactions can still be observed through sequencer feeds and RPC pending transaction methods.

What to track in the mempool: pending swap transactions targeting the same pools you are trading on. Large swaps that are likely to cause price impact. Transactions from known searcher addresses. Transactions with unusually high gas prices that suggest urgency — a common signal of front-running intent.

The mempool is your early warning system. If you see a transaction that looks like it is front-running your pending swap, you have seconds to react. Cancel your transaction. Resubmit with different parameters. Use a private mempool or a protected relay.

Pending Swap Details

For each pending swap, track the following: the input token, the output token, the input amount, the expected output amount, the slippage tolerance, the target pool or route, and the sender address. These details tell you whether the swap is likely to be targeted.

Large swaps are more likely to be targeted because the potential profit for a sandwich attacker is higher. Swaps with high slippage tolerance are more likely to be targeted because the attacker has more room to extract value before the swap reverts. Swaps on pools with thin liquidity are more likely to be targeted because the price impact is larger.

Slippage and Price Impact

Track the difference between the expected output and the actual output for every swap you execute. This is the realized slippage. Compare it to the slippage tolerance you set. If the realized slippage is consistently close to your tolerance limit, you are likely being targeted by MEV extraction.

Price impact is different from slippage. Price impact is the expected price movement caused by your swap based on the pool’s reserves. Slippage is the difference between the expected price and the executed price, which includes price impact plus any MEV extraction. If your realized slippage significantly exceeds the expected price impact, the difference is likely MEV.

Block Contents

Every block contains a sequence of transactions. By monitoring block contents in real time, you can detect MEV extraction as it happens. Look for the sandwich pattern: a buy transaction, your swap, a sell transaction, all in the same block, all targeting the same pool. Look for front-running: a transaction from a different address targeting the same pool, ordered before your swap.

Block contents are available through standard RPC calls. Ethereum and Base both support the eth_getBlockByNumber method with full transaction objects. By subscribing to new blocks via WebSocket, you can receive block contents as soon as blocks are produced.

Searcher Addresses

MEV searchers are not anonymous. They operate from specific addresses that can be identified and tracked. Some searcher addresses are publicly known. Others can be identified by analyzing on-chain patterns — addresses that frequently submit transactions in sandwich patterns, addresses that frequently transact with specific MEV relays, addresses that submit transactions with consistently high gas prices.

By maintaining a list of known searcher addresses, you can flag any interaction with your transactions. If a known searcher address transacts on the same pool in the same block as your swap, you are likely being targeted. This is a strong signal. It warrants investigation.

Public Tools for MEV Monitoring

Several public tools exist for MEV monitoring. These are not endorsements. They are the tools that are publicly available and widely used in the ecosystem.

EigenPhi. EigenPhi provides real-time MEV analytics. Their dashboard shows MEV extraction across multiple chains, including Ethereum and Layer-2s. They categorize MEV by type — sandwich, arbitrage, liquidation — and show the extracted value in real time. Their data is accessible through a public web interface and an API. EigenPhi is useful for understanding the MEV landscape and for tracking aggregate extraction over time.

Flashbots. Flashbots is a research and development organization that builds MEV infrastructure. They created the MEV-Boost relay system used by Ethereum validators. They provide the Flashbots Protect RPC, which allows users to submit transactions to a private mempool that is not visible to searchers. This is not monitoring per se, but it is a mitigation tool. Flashbots also publishes research and data on MEV extraction patterns.

mev-watch. mev-watch is a public tool that helps users understand whether their transactions have been affected by MEV. It analyzes past transactions and identifies sandwich attacks, front-running, and other forms of extraction. It is retrospective rather than real-time, but it is useful for understanding your historical exposure.

Dune Analytics. Dune provides a SQL-based analytics platform for blockchain data. Several public dashboards track MEV extraction. These dashboards are maintained by community members and can be customized. Dune is useful for building custom monitoring queries — for example, tracking MEV on specific pools or from specific searcher addresses.

Loki MEV. Loki is a public MEV explorer that shows real-time sandwich attacks and arbitrage transactions across multiple chains. It provides a visual interface for identifying MEV patterns and tracking specific searchers.

Building a Monitoring Pipeline

For teams that need real-time MEV monitoring beyond what public dashboards provide, the approach is to build a monitoring pipeline. The pipeline has several components.

A mempool listener. This is a process that connects to an Ethereum or Base node via WebSocket and subscribes to pending transactions. The listener filters for transactions that interact with DEX routers or liquidity pools. For each relevant transaction, it extracts the swap details — tokens, amounts, target pool, sender.

A block listener. This is a process that subscribes to new blocks. For each new block, it retrieves the full transaction list and checks for MEV patterns — sandwich attacks, front-running, back-running. It compares the block’s transactions against the mempool listener’s pending transactions to identify which pending swaps were targeted.

An alerting system. When the pipeline detects MEV activity — either in the mempool or in a confirmed block — it sends an alert. The alert can be a webhook, a Slack message, an email, or a custom notification. The alert should include the relevant transaction hashes, the detected MEV type, the estimated value extracted, and the affected swap.

A historical database. Every detected MEV event should be stored in a database for analysis. Over time, this database reveals patterns — which pools are most targeted, which times of day have the most MEV activity, which searcher addresses are most active. This data informs strategy adjustments.

The pipeline does not need to be complex — for a forensic methodology on auditing DEX settlements, see our companion guide. The core components — mempool listener, block listener, alerting — can be built with standard Web3 libraries. ethers.js and viem both provide WebSocket subscription methods for pending transactions and new blocks. The filtering logic is straightforward: check whether a transaction interacts with a known DEX router address, decode the swap parameters, and compare against your pending swaps.

What Real-Time Monitoring Cannot Do

Real-time monitoring is not a silver bullet. It has limitations.

It cannot prevent MEV extraction on chains where the mempool is not publicly visible. Base’s sequencer does not expose a full public mempool in the same way Ethereum does. Pending transactions on Base are processed by the centralized sequencer, and the ordering is not fully transparent. This means mempool monitoring on Base is less effective than on Ethereum. You can still monitor block contents and detect MEV after it happens, but the early warning system is weaker.

It cannot prevent MEV extraction when transactions are submitted through private relays that you do not have access to. If a searcher submits transactions through a private mempool or a direct relationship with a block builder, those transactions are not visible in the public mempool. You will not see them until they are included in a block.

It cannot reverse MEV extraction that has already occurred. Once a sandwich attack is included in a block, it is final. Monitoring can detect it, document it, and inform future strategy. It cannot undo it.

Mitigation Strategies Informed by Monitoring

The value of real-time monitoring is that it informs mitigation. If you know you are being targeted, you can take action.

Use private mempools. Submit transactions through Flashbots Protect or similar private relay systems. This prevents your transactions from appearing in the public mempool where searchers can see them. The tradeoff is that private mempools may have slightly longer inclusion times.

Set tighter slippage tolerances. If your monitoring shows that you are consistently being sandwiched, reduce your slippage tolerance. A tighter tolerance means the swap will revert if the price moves too much, which limits the attacker’s profit. The tradeoff is that tighter tolerances increase the chance of your swap reverting during normal market volatility.

Split large swaps. If your monitoring shows that large swaps are being targeted, split them into smaller swaps executed over multiple blocks. Smaller swaps have less price impact and are less attractive to sandwich attackers. The tradeoff is that splitting increases gas costs and exposes you to market movement over a longer period.

Use intent-based execution. Intent-based execution systems — UniswapX, CoW Protocol, 1inch Fusion — allow you to sign an off-chain message describing what you want rather than submitting an on-chain transaction. Solvers compete to fill the order. This removes the mempool exposure entirely. The tradeoff is that you are relying on solvers to provide good execution, and the competitive dynamics are different from direct AMM swaps.

Conclusion

Real-time MEV monitoring is the practice of observing the mempool and block contents in real time to detect and respond to MEV extraction. It matters because MEV extraction happens in milliseconds, and post-hoc analysis is too late to prevent it. The key data streams to track are mempool transactions, pending swap details, realized slippage, block contents, and known searcher addresses.

Public tools like EigenPhi, Flashbots, mev-watch, Dune Analytics, and Loki provide varying levels of MEV visibility. For teams that need deeper monitoring, a custom pipeline built on standard Web3 libraries can provide real-time alerts and historical analysis.

Monitoring is not prevention. But monitoring is the prerequisite for prevention — and our guide on MEV detection tools and methods covers the forensic side. You cannot mitigate what you cannot see. You cannot adjust what you cannot measure — and detecting MEV after the fact is the first step to understanding your exposure. Real-time MEV monitoring is the first step toward reducing your exposure to value extraction in DeFi.

Orkid is building infrastructure that addresses MEV-related challenges. You can learn more at orkidlabs.xyz. The concepts described in this article are based on public research and documentation from the cited sources.

Frequently Asked Questions

Why does MEV monitoring matter?

MEV monitoring matters because it reveals hidden costs that traders pay without realizing it. Sandwich attacks and other forms of MEV extraction can significantly degrade trade execution prices. Without monitoring, traders cannot measure their losses, identify which pools or times are most affected, or evaluate whether protection measures are working.

What is real-time MEV detection?

Real-time MEV detection is the process of identifying MEV extraction as it happens by monitoring the mempool and incoming blocks. It involves detecting sandwich attack patterns, front-running, and arbitrage opportunities as transactions are submitted and included. Real-time detection enables faster response and better-informed trading decisions.

How do you monitor for sandwich attacks?

Sandwich attack monitoring involves watching the mempool for pending swaps and then checking whether those swaps are preceded and followed by transactions from the same address. Detection tools look for the characteristic buy-sell pattern around a victim transaction. Dashboards from EigenPhi and Flashbots visualize these attacks and quantify the value extracted.

What is a mempool observer?

A mempool observer is a tool or service that watches the pool of pending transactions before they are included in a block. It captures transaction submissions, timestamps, and ordering data. By observing the mempool, analysts can detect when transactions are being targeted by MEV bots and measure the delay between submission and inclusion.

What Is MEV

Why Real-Time Monitoring Matters

The Three Forms of MEV Extraction