What Is the Ethereum Mempool? How Bots See Pending Transactions

By Merunas Grincalaitis, founder of MEV DAO and a developer who builds MEV, sniping and trading bots on Ethereum. Last updated: Oct 31, 2026.

TL;DR: The Ethereum mempool is the waiting room for transactions that have been broadcast but not yet included in a block. There isn't one mempool: every node keeps its own pool (Geth calls it the txpool, sized by default for 5,120 executable transactions) and shares new transactions with its peers. Because it's public, MEV bots watch it in real time, simulate what each pending swap will do, and place their own transactions around it. If you don't want bots to see your trade, you send it through a private RPC like Flashbots Protect or MEV Blocker instead.

Almost every MEV strategy I've built starts with the same line of code: subscribe to pending transactions. Sandwiching, backrunning, copy trading, liquidations and launch sniping all depend on seeing what other people are about to do, a few seconds before the chain does. So if you want to understand why your swap got sandwiched, or how a sniper bot works, the mempool is where to start.

What is the mempool in crypto?

The mempool (short for "memory pool") is the set of valid, signed transactions a node has received but not yet seen included in a block. The name comes from Bitcoin, and Ethereum uses the same idea.

When you click "Confirm" in your wallet, the wallet sends the signed transaction to an RPC node. That node checks it (valid signature, correct nonce, enough ETH for gas), adds it to its pool, and forwards it to its peers, which do the same. Within a second or two, most of the network has a copy. It sits there until a block builder includes it, until you replace it with a higher-fee version using the same nonce, or until nodes drop it.

On Ethereum the gossip layer is the execution clients' peer-to-peer network, described on ethereum.org's networking layer page.

Is there one global Ethereum mempool?

No. Each node has its own mempool, and they're mostly but not perfectly in sync. What one node sees depends on its peers, its size limits and its rules.

That's why two mempool explorers can disagree, and why your transaction can show up on one and not another. Pools also have limits. Geth's defaults, from its command-line docs, are:

Geth txpool setting	Default	What it means
`txpool.globalslots`	5,120	Executable ("pending") transactions kept across all accounts
`txpool.accountslots`	16	Executable transactions guaranteed per account
`txpool.globalqueue`	1,024	Non-executable ("queued") transactions, such as ones with a nonce gap
`txpool.lifetime`	3 hours	How long queued transactions are kept
`txpool.pricebump`	10%	Fee increase needed to replace a transaction with the same nonce

When the pool is full, the cheapest transactions get evicted first. Geth also keeps EIP-4844 blob transactions in a separate blob pool with its own rules.

What's the difference between pending and queued?

"Pending" transactions can be mined right now; "queued" ones can't yet, usually because an earlier nonce from the same address is missing. You can see both on your own node with Geth's txpool_content and txpool_status RPC methods.

This matters more than it sounds. A single stuck transaction with a low fee holds back every later transaction from that address. I wrote a separate guide on fixing a stuck pending transaction, including how speed-up and cancel actually work.

How do MEV bots read the mempool?

They connect to one or more nodes, stream every new pending transaction, decode it, and simulate how it changes on-chain state. If there's a profitable reaction, they send their own transaction or bundle within milliseconds.

The typical loop looks like this:

Stream. Subscribe to newPendingTransactions over a WebSocket connection (Geth supports it through eth_subscribe), ideally on your own node so you get transactions as early as possible.
Filter and decode. Throw away transfers you don't care about and decode the calldata of the rest, for example a call to a Uniswap router that swaps 50 ETH for a token with 3% slippage allowed.
Simulate. Run the pending transaction against the latest state, often on a local fork, to see the exact price impact. My guide on testing an MEV bot on a mainnet fork shows the setup.
React. Build a response: a backrun that arbitrages the price move, a sandwich that buys before and sells after, a copy trade, or a liquidation the price change unlocks.
Submit. Send the response as a Flashbots-style bundle to block builders, so it lands in the right order next to the target transaction or not at all.

Researchers documented this behavior early. The 2019 paper Flash Boys 2.0 (Daian et al.) described bots bidding up gas against each other to front-run DEX trades, and Paradigm's 2020 essay Ethereum is a Dark Forest told the story of a rescue attempt that a generalized front-running bot copied and stole. Both are still worth reading.

Why does the mempool matter for my trades?

Anything you broadcast publicly can be seen and acted on before it's final. For a normal ETH transfer that doesn't matter. For a swap, it can cost you money.

The classic example is the sandwich attack: a bot sees your swap with loose slippage, buys the token just before you, lets your trade push the price up, and sells right after. You get the worst price your slippage allows, and the bot keeps the difference. Similar logic powers front-running bots and the mempool sniper bots that watch for liquidity being added to a new token.

It cuts both ways. The same visibility is what lets a liquidation bot keep a lending market solvent, or an arbitrage bot pull a DEX price back in line with the rest of the market.

How do I keep my transaction out of the public mempool?

Use a private RPC that sends your transaction directly to block builders instead of gossiping it to the network. Bots watching the public mempool never see it before it's in a block.

Option	How it works	Good for
Flashbots Protect	RPC that sends transactions privately to builders, with optional refunds of MEV from your order flow	Swaps from any wallet
MEV Blocker	Private RPC run by CoW DAO and partners, with backrun rebates	Swaps from any wallet
Wallet-native protection	Some wallets route swaps privately by default	Users who don't want to change RPCs
Bundles	Searchers and bots send `eth_sendBundle` straight to builders	Bots, snipes, rescues

There's a tradeoff. Private transactions don't show on public explorers until they land, and if builders don't include them they just wait or expire. I compared the two main RPCs in Flashbots Protect vs MEV Blocker, and covered the basics in what is MEV protection.

Frequently asked questions

What does mempool stand for?

Memory pool. It's the in-memory set of transactions a node has received and validated but that haven't been included in a block yet.

Can I see the Ethereum mempool?

Yes. Etherscan has a pending transactions page, and if you run your own node you can query it with Geth's txpool RPC methods or subscribe to new pending transactions over WebSocket.

How long do transactions stay in the mempool?

Usually seconds, since a new block comes every 12 seconds. Underpriced ones can wait for hours until fees fall, they're replaced, or nodes evict them.

Is the mempool the same on every node?

No. Every node keeps its own pool with its own limits and peers, so pools are similar but never identical.

Do all Ethereum transactions go through the public mempool?

No. Transactions sent through private RPCs or as bundles go straight to block builders and only become public once they're in a block.

Why do bots watch the mempool?

To react to pending transactions before they're final, for arbitrage, backruns, liquidations, copy trading, sniping or sandwich attacks.

Reading the mempool is easy; reacting to it faster and more accurately than everyone else is the hard part. That's most of what we build at MEV DAO, and if you want a mempool-driven strategy built for you, here's how our custom MEV bot development works.