Ethereum Mempool Monitoring: How MEV Bots Decode Pending Transactions

Published February 5, 2026 · Updated March 7, 2026 · By JaredFromSubway

Every transaction on Ethereum passes through a critical but often overlooked stage before it is confirmed: the mempool. This public waiting room of unconfirmed transactions is the hunting ground for MEV bots, sophisticated programs that scan, decode, and act on pending transactions in milliseconds. Understanding how mempool monitoring works is essential for anyone building MEV infrastructure, researching DeFi security, or simply trying to understand why their swap executed at a worse price than expected.

In this guide, JaredFromSubway breaks down every layer of mempool monitoring — from subscribing to pending transactions over WebSocket, to decoding raw calldata, to identifying sandwich attack targets with sub-millisecond precision. Whether you are building your own MEV bot or defending against one, this is the technical foundation you need.

What Is the Ethereum Mempool?

The mempool — short for "memory pool" — is the set of all pending transactions that have been broadcast to the Ethereum network but have not yet been included in a block. When you submit a swap on Uniswap, your transaction does not execute immediately. It first propagates across the peer-to-peer network, landing in the mempool of every connected node. There it waits, typically for 12 seconds (one block interval) or longer, until a block builder selects it for inclusion.

Critically, the mempool is not a single centralized queue. Every Ethereum node maintains its own local version. A transaction might appear in one node's mempool 50 milliseconds before another, depending on network topology and geographic proximity. This propagation delay is one of the key variables that MEV bots optimize around. The faster a bot sees a pending transaction, the more time it has to analyze, simulate, and respond.

The mempool is fully transparent. Anyone running a full Ethereum node can inspect every pending transaction's sender, recipient, value, gas parameters, and raw calldata. This transparency is a fundamental design property of Ethereum — and the reason MEV extraction is possible at all.

Subscribing to Pending Transactions via WebSocket

The primary method for monitoring the mempool in real time is the eth_subscribe JSON-RPC method with the newPendingTransactions parameter. This establishes a persistent WebSocket connection to an Ethereum node. Whenever a new transaction enters the node's mempool, its hash is pushed to the subscriber in real time — no polling required.

With the basic subscription, you receive only transaction hashes. To get the full transaction object (including calldata, gas price, and value), you must follow up with an eth_getTransactionByHash call for each hash. Some node clients like Geth support a "full" subscription mode that returns the complete transaction object directly, eliminating this extra round-trip and shaving precious milliseconds off detection latency.

JaredFromSubway's infrastructure uses custom-patched Geth nodes that stream full transaction objects the instant they enter the mempool. Every millisecond matters: a bot that sees a transaction 5ms before a competitor has a significant edge in submitting a sandwich bundle to Flashbots before the next block is proposed.

Full Node vs. Third-Party Providers: Mempool Access Tiers

Not all mempool access is equal. There are three distinct tiers that determine the breadth and speed of the transaction data you receive:

Tier 1: Self-Hosted Full Node

Running your own Geth or Erigon node gives you direct, unfiltered access to the mempool. You see every transaction that propagates to your node through its peer connections. The more peers your node has, the broader your mempool coverage. Serious MEV operators run multiple nodes across different data centers to maximize coverage and minimize the chance of missing a transaction. This is the approach JaredFromSubway uses — a network of dedicated nodes optimized for mempool reception speed.

Tier 2: Premium RPC Providers

Services like Alchemy, QuickNode, and BloXroute offer mempool streaming through their infrastructure. BloXroute's BDN (Blockchain Distribution Network) is particularly popular among MEV searchers because it provides access to transactions propagating across a wide network of nodes before they reach the general peer-to-peer network. These services add latency compared to a self-hosted node but offer broader coverage than a single node could achieve.

Tier 3: Public RPC Endpoints

Free public RPCs from providers like Infura or Ankr typically do not support eth_subscribe for pending transactions, or they heavily rate-limit the feed. These endpoints are unsuitable for MEV extraction. If you are serious about mempool monitoring, you need at minimum a Tier 2 provider, and ideally your own infrastructure.

Decoding Transaction Calldata: Function Selectors and ABI Decoding

When a mempool scanner receives a pending transaction, the most critical field is the input (or calldata) — the raw bytes that tell the target smart contract what to do. The first 4 bytes of calldata are the function selector: a truncated Keccak-256 hash of the function signature. By matching these 4 bytes against a database of known selectors, the bot can instantly identify what type of operation the transaction performs.

For example, the function selector 0x38ed1739 corresponds to swapExactTokensForTokens(uint256,uint256,address[],address,uint256) on Uniswap V2's Router contract. On Uniswap V3, the exactInputSingle function uses selector 0x414bf389. MEV bots maintain lookup tables of hundreds of function selectors across all major DEX routers, aggregators, and DeFi protocols to classify transactions instantly.

Once the function is identified, the remaining calldata bytes are ABI-decoded according to the function's parameter types. For a Uniswap V2 swapExactTokensForTokens call, the bot extracts five parameters: amountIn (how many tokens the user is selling), amountOutMin (the minimum tokens they will accept), path (the array of token addresses defining the swap route), to (the recipient), and deadline (the timestamp after which the transaction reverts). Each of these parameters is essential for evaluating whether the transaction is a viable sandwich target.

Extracting Victim Data and Calculating Slippage Tolerance

The key to identifying a profitable sandwich attack target lies in two decoded parameters: amountIn and amountOutMin. The amountIn tells the bot how large the trade is — larger trades create more price impact on the AMM pool, meaning more extractable value. The amountOutMin reveals the user's slippage tolerance: the gap between the expected output and the minimum acceptable output.

Slippage tolerance is calculated as: (expectedOut - amountOutMin) / expectedOut * 100. A user who sets 5% slippage on a $10,000 swap is essentially telling the world they will accept receiving up to $500 less than the current market rate. That $500 gap is the maximum profit a sandwich bot can extract. JaredFromSubway's scanner filters for transactions where the slippage gap exceeds the gas cost of executing a sandwich bundle, ensuring every attack is profitable after all on-chain costs.

The path parameter is equally important. It reveals the exact token pair being traded and whether the swap routes through intermediate tokens. The bot uses the path to query the relevant AMM pool's reserves and simulate the price impact of the victim's trade. By running this simulation locally on a forked EVM state, the bot can calculate the exact profit from front-running the trade, the optimal front-run size, and the expected back-run output — all before submitting anything on-chain.

Private Mempools and Flashbots: The Invisible Transactions

Not every pending transaction is visible in the public mempool. A growing percentage of Ethereum transactions are submitted through private channels that bypass the peer-to-peer network entirely. Flashbots Protect, MEV Blocker, and direct builder submission endpoints allow users to send transactions straight to block builders without ever exposing them publicly. For a detailed explanation of how these systems work, see our guide on Flashbots and MEV-Boost.

For MEV bots, private transactions are a blind spot. If a transaction never enters the public mempool, no amount of monitoring will detect it. This is why front-running protection services like Flashbots Protect are effective: they remove the transaction from the bot's view entirely. Current estimates suggest that 20-30% of Ethereum transactions now use private submission channels, a figure that continues to grow.

JaredFromSubway adapts to this reality by focusing on the transactions that remain in the public mempool. Many users — especially those on mobile wallets, using default RPC settings, or trading on lesser-known DEXs — still submit transactions publicly. The volume of publicly visible, high-slippage transactions remains more than sufficient for profitable MEV extraction.

How JaredFromSubway's Mempool Scanner Identifies Sandwich Targets

JaredFromSubway's scanner processes every pending transaction through a multi-stage pipeline designed to go from raw transaction hash to submitted Flashbots bundle in under 5 milliseconds:

1. Reception: Custom-patched Geth nodes stream full transaction objects the moment they enter the local mempool. Multiple geographically distributed nodes ensure maximum coverage.
2. Classification: The first 4 bytes of calldata are matched against a lookup table of 500+ known DEX function selectors. Non-swap transactions are discarded immediately.
3. Decoding: The calldata is ABI-decoded to extract amountIn, amountOutMin, path, and deadline. The token pair and pool address are derived from the path.
4. Simulation: The bot forks the current chain state locally and simulates the victim's trade against the actual pool reserves. It calculates the exact price impact and the maximum extractable slippage.
5. Optimization: If the slippage gap exceeds gas costs, the bot calculates the optimal front-run trade size using binary search over simulated pool states. The goal is to push the price just enough that the victim's trade executes at their amountOutMin.
6. Submission: A three-transaction bundle (front-run, victim, back-run) is submitted to Flashbots' MEV-Share relay or directly to block builders. The bundle includes a payment to the builder calculated to outbid competing searchers.

This entire pipeline executes in under 5 milliseconds on JaredFromSubway's infrastructure. Speed is not optional — the same target transaction is visible to every competing MEV bot on the network. The first bot to submit a valid, profitable bundle to the winning block builder captures the opportunity.

Infrastructure Requirements for Competitive Mempool Monitoring

Building a mempool monitoring system that can compete with established MEV bots like JaredFromSubway requires significant infrastructure investment. The difference between a hobby project and a production MEV operation comes down to latency, reliability, and simulation throughput.

Dedicated Nodes

Production MEV operations run multiple Geth or Reth nodes with high peer counts (200+ peers) to maximize mempool coverage. These nodes are often patched to optimize transaction propagation speed, disable unnecessary processing, and stream transactions to the bot application layer with minimal overhead. A single node can miss 5-10% of mempool transactions due to network topology effects, so redundancy is essential.

Sub-Millisecond Latency

The time between receiving a transaction and submitting a bundle must be minimized to single-digit milliseconds. This requires the bot application to run on the same physical machine or local network as the Ethereum node, eliminating network round-trip time. Data structures are optimized for cache locality, and hot paths avoid memory allocation. Every microsecond of latency is a competitive disadvantage.

Co-Located Servers

Top MEV operators co-locate their servers in data centers with high concentrations of Ethereum nodes and block builder infrastructure. Locations like Frankfurt, Amsterdam, and Ashburn (Virginia) host significant Ethereum node density. Being physically closer to these nodes means receiving mempool transactions earlier and having bundles reach builders faster. Some operators maintain presence in multiple data centers simultaneously to cover different network regions.

EVM Simulation Engine

The bot must simulate transactions against a local fork of Ethereum state to evaluate profitability. This simulation engine needs to process hundreds of candidate transactions per second, each requiring a full EVM execution against current pool reserves. Tools like revm (a Rust-based EVM implementation) are popular in the MEV community for their raw execution speed. JaredFromSubway uses custom simulation infrastructure capable of evaluating thousands of potential sandwiches per block.

Frequently Asked Questions