> ## 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.
# What Is the Mempool and How Do MEV Bots Use It?
> The mempool is where Ethereum transactions wait before confirmation — and where MEV bots go hunting. This guide explains what bots see, how they act on it, and why it changes how you should think about transaction execution.
Mar 4, 2026·
7 min read
·#MEV#Mempool#Ethereum
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:
| | Public mempool | Private channel |
| -------------- | ------------------- | -------------------------------- |
| Visibility | All nodes, all bots | Builder only |
| Front-run risk | High | Eliminated |
| Sandwich risk | High | Eliminated |
| Gas required | Competitive bid | Bundle bid to builder |
| Typical users | Retail, unprotected | Sophisticated traders, searchers |
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.
See the confirmed swap data behind this
Explore 1,000+ sample rows from BlockDB's swap and transaction datasets on Hugging Face — no account needed.
