What Is the Mempool and How Do MEV Bots Use It?

Documentation Index

Fetch the complete documentation index at: https://blog.blockdb.io/llms.txt

Use this file to discover all available pages before exploring further.

When you submit a transaction on Ethereum, it doesn’t land in a block immediately. For up to several seconds — sometimes longer — it sits in a public waiting room called the mempool, visible to every node on the network. That visibility is not a bug. It is how the P2P network works. But it is also what makes MEV extraction possible. MEV bots don’t exploit smart contract vulnerabilities. They exploit information. Specifically, they exploit the fact that your pending transaction is readable before it confirms, and that the actors who build blocks can choose what goes where inside them.

​

What is the mempool?

The mempool (memory pool) is the set of valid, unconfirmed transactions that have been broadcast to the Ethereum network but not yet included in a block. Every full node maintains its own view of the mempool, and transactions propagate across the network peer-to-peer until a block builder selects them for inclusion. Key properties:

• Public by default. Any node — including bots — can read every pending transaction’s sender, recipient, calldata, value, and gas parameters.
• Unordered. There is no official queue. Block builders select from the mempool using their own criteria, typically maximizing fees and MEV.
• Ephemeral. Transactions that aren’t included within a certain window are evicted. Senders must rebroadcast or increase their gas bid.
• Fast-propagating. Transactions reach roughly 95% of network participants within ~200 milliseconds of being broadcast, per P2P network research. Bots have access to your transaction almost as soon as you submit it.

In traditional finance, the closest analogy is a lit order book: every order is publicly visible before execution. The difference is that on a DEX, the “matching engine” — the block builder — is not neutral. It has financial incentives to structure the execution order in its favor.

​

What bots see when they watch the mempool

When a MEV bot monitors the mempool, it sees the full transaction payload. For a Uniswap swap, that includes:

• The token pair being swapped
• The input amount
• The minimum output amount (slippage tolerance)
• The deadline
• The sender’s address

From just these parameters, a bot can calculate:

1. The expected price impact of the pending swap on the pool’s reserves.
2. The slippage budget — how much worse than the quoted price the sender is willing to accept. This is the maximum the bot can extract from a sandwich attack.
3. Whether an arbitrage opportunity will open across other pools once this swap settles.

This is not speculation. The bot is reading confirmed inputs and simulating their output against the current on-chain state before the transaction confirms. By the time your transaction leaves your wallet, bots have already priced the opportunity.

​

The bot’s decision loop

MEV bots run a continuous cycle: 1. Scan. The bot subscribes to new mempool transactions via a node’s RPC endpoint or a dedicated mempool stream. On Ethereum with 12-second blocks, there is a sustained flow of hundreds to thousands of pending transactions at any moment. 2. Simulate. For each candidate transaction, the bot simulates execution against the current chain state to determine: is this profitable to front-run, sandwich, or back-run? What is the expected profit net of gas? 3. Construct. If an opportunity clears the profitability threshold, the bot constructs a response transaction (or bundle). For a sandwich attack, this is two transactions: one before the target, one after. For arbitrage, it is typically one transaction after the block is confirmed. 4. Submit. The bot submits its transaction to the network, either via the public mempool (with a high gas bid to ensure ordering priority) or via a private channel to a block builder (Flashbots, MEV-Boost). Private submission hides the bot’s intent from competing bots. 5. Compete. If the opportunity is visible to multiple bots, a Priority Gas Auction begins. Bots progressively raise their gas bids in the seconds before block finalization, each trying to secure the better position. These auctions can consume the majority of the expected profit in gas costs. The entire loop — scan, simulate, construct, submit — runs in milliseconds. Automated bots respond faster than any human could, particularly on faster chains like Avalanche (2-second blocks), but the 12-second Ethereum block time is slow enough that some manual searchers can still participate effectively.

​

The four main mempool exploitation patterns

​

Front-running

A bot detects a large pending swap that will move a pool’s price. It submits an identical directional trade before the target, paying a higher gas fee to secure earlier block position. When the target swap executes, it pushes the price in the bot’s favor. The bot sells immediately after. The target user receives worse execution than quoted — the bot consumed the favorable price before them.

​

Sandwich attack

An extension of front-running. The bot places a buy before the target swap and a sell after it, bracketing the target transaction in the block. The target’s slippage tolerance defines the maximum the bot can extract: the bot inflates the price up to that limit on entry, then captures the reversal on exit. Sandwich attacks are the most directly harmful mempool exploitation for retail participants. The attacker’s profit equals the target’s additional cost — it is pure value transfer with no market-efficiency justification.

​

Transaction sniping

When two or more bots identify the same opportunity simultaneously, they compete by bidding gas. Neither bot can guarantee the other won’t outbid them, so each escalates their gas price incrementally as the next block approaches. This Priority Gas Auction continues until the economic margin is depleted or one bot withdraws. The externality: gas spikes during high-MEV periods raise costs for all unrelated users transacting in the same blocks.

​

Back-running (arbitrage)

After a large swap settles and pushes a pool’s price away from the broader market, a bot immediately submits an arbitrage transaction — buying on the now-cheaper pool and selling on a more expensive one — to capture the spread. This executes in the block after the price-moving swap. Back-running is considered benign for the target user (it happens after their trade settles) and price-stabilizing for the broader market. It is the form of MEV most analogous to classical statistical arbitrage.

​

Timing: Next Block vs. Zero Block MEV

The timing of a bot’s response relative to the target transaction determines which strategy is viable: Next Block MEV — the bot identifies an opportunity (often an arbitrage opened by a swap in the most recent block) and targets inclusion in the next block. The bot has a full block interval to construct and submit its transaction. Competition is primarily via gas bidding. Zero Block MEV — the bot reacts to a transaction currently in the mempool and must execute before that transaction confirms. This is the category that includes front-running and sandwiching. Timing is critical: the bot must submit its transaction early enough to win block position over the target, which in practice means submitting within the same mempool propagation window. Zero Block MEV is harder to execute and harder to defend against. The target transaction is already public, the bot already knows the exact parameters, and the block builder makes the final ordering decision.

​

The response: private mempools

The exposure created by public mempool visibility has driven a structural shift in how transactions are submitted. Flashbots and similar services provide a private transaction channel: users and searchers submit transactions directly to block builders, bypassing the public mempool entirely. A transaction in the private channel is not visible to competing bots — it appears in the block without ever being readable by the mempool. This created a two-tier system: Most of the largest block builders now receive the majority of their transaction flow through private channels. This means the public mempool increasingly reflects lower-value activity — smaller transactions, less sophisticated users, or transactions from protocols that don’t route through MEV-protection infrastructure. For searchers, private channels are also a competitive tool: a bundle submitted privately to a builder cannot be front-run by other searchers who would otherwise see it in the public mempool.

​

How many bots are actually doing this?

The searcher market is more concentrated than it appears. According to EigenPhi research from early 2023, at least 2,800 bots are active on Ethereum at any given time — but a significant proportion are single-use testing bots that never execute a profitable transaction. The active market is dominated by approximately 20 teams, with an estimated total of ~500 serious participants. The block building market is even more concentrated: roughly six builders control the majority of Ethereum block production, which means the competition to have a bundle included ultimately runs through a handful of entities. This concentration has implications for anyone studying MEV from data: the extractable signal is dominated by a small number of actors running well-defined playbooks. Their on-chain footprints are identifiable, repeatable, and measurable.

​

What this means for traders and protocol designers

For traders: slippage tolerance is a direct input to the sandwich bot’s profit calculation. A 0.5% slippage setting on a large swap is not just a preference — it is the maximum fee you are willing to pay a sandwich attacker. Tighter slippage reduces the attack surface but increases the chance of transaction failure during volatile periods. For protocol designers: any protocol whose state can be meaningfully front-run — AMMs, oracles, lending liquidations — needs to account for the mempool’s information transparency in its design. Commit-reveal schemes, batch auctions, and private submission routing are the main structural responses. For data analysts: the mempool is the starting state. What enters the block is the outcome. The gap between the two — which transactions were included, in what order, and at what gas prices — carries the full signal of who was extracting what, when.

​

Glossary

Mempool — The pool of valid, unconfirmed transactions broadcast to the network and waiting for block inclusion. Public by default; readable by all nodes. MEV bot — An automated program that continuously scans the mempool for profitable opportunities and submits transactions to exploit them, typically faster than any human actor. Front-running — Submitting a transaction before a known pending one to profit from the price impact the pending transaction will cause. Sandwich attack — Placing a buy transaction before a target swap and a sell after it, extracting value bounded by the target’s slippage tolerance. Back-running — Submitting an arbitrage transaction immediately after a price-moving event to capture the resulting cross-pool price discrepancy. Priority Gas Auction (PGA) — A competitive bidding process where multiple bots escalate gas prices to secure favorable block position for the same opportunity. Zero Block MEV — MEV captured by acting on a transaction currently in the mempool, before it confirms. Includes front-running and sandwich attacks. Next Block MEV — MEV captured by reacting to an event in the most recently confirmed block, targeting inclusion in the following block. Includes most arbitrage strategies. Private mempool — A transaction submission channel (e.g., Flashbots) that routes transactions directly to block builders, bypassing public mempool visibility. Slippage tolerance — The maximum price deviation a user accepts on a DEX swap. In the context of MEV, it defines the upper bound of what a sandwich attacker can extract.

---

Want the full history or production-volume access? Contact us — production schema, no commitment.