What Is the Mempool?

Between the moment you tap “confirm” and the moment a transaction is written into a block, it lives somewhere: the mempool. It is one of the most important yet least visible parts of a blockchain network, and it explains a surprising amount of everyday behaviour, from why fees spike during busy periods to why a trade can be sandwiched by bots. This article explains what the mempool is, how nodes organise it, and why it sits at the centre of fees and transaction ordering.

A waiting room for transactions

The mempool, short for “memory pool” and also called the transaction pool or txpool, is the dynamic, in-memory area where a node keeps pending transactions before they are included in a block. When you broadcast a transaction, your wallet sends it to a node, the node checks that it is well-formed and validly signed, and if it passes, the node holds it in the mempool and gossips it to its peers. From there it propagates across the network, node to node.

The key word is unconfirmed. A transaction in the mempool has not yet happened in any final sense. It is a validated proposal waiting to be picked up by whoever builds the next block. To see where this fits in the larger sequence, our explainer on how a transaction gets confirmed walks through the full path from signature to settled state.

A node does real work before it will accept a transaction into its pool. It checks that the signature is valid, that the sender has enough balance to cover the value plus the maximum fee, that the nonce is acceptable, and that the fee is not absurdly low. Transactions that fail these checks are simply not admitted, which keeps obvious junk out of the pool. What remains is a churning set of candidate transactions, constantly being added to as users broadcast and drained as validators build blocks.

There is no single global mempool

It is tempting to picture the mempool as one universal list every node reads from. It is not. Each node maintains its own mempool and synchronises with peers by relaying transactions. Because propagation takes time and nodes apply their own rules about what to accept and retain, no two nodes hold exactly the same set at exactly the same instant.

This matters in practice. A transaction can appear on one node’s mempool a moment before it reaches others. Nodes may also drop very old or persistently underpriced transactions to save memory. And, as we will see, some transactions are deliberately routed so that they never appear in any public mempool at all. Thinking of the mempool as a shared-but-fuzzy view, rather than a single source of truth, is closer to reality.

Pending versus queued

Within a node’s pool, an account’s waiting transactions fall into two categories. Pending transactions have a nonce that follows in sequence from the account’s last confirmed transaction, so they are eligible for the next block. Queued transactions have a nonce that is out of order, typically because an earlier-numbered transaction is still unconfirmed, so the node parks them until the missing nonce arrives.

This structure is why one stuck transaction can freeze everything an account sends afterwards. The relationship between sequencing and the pool is covered in depth in what is a transaction nonce. In short, the mempool respects nonce order strictly, and a gap leaves later transactions waiting in the queued bucket.

How validators choose from the pool

When it is time to build a block, a validator or block builder selects transactions from the mempool. Block space is limited, so not everything waiting can fit. The dominant selection signal is the fee: transactions offering a higher priority fee are generally more attractive because that tip goes to the validator. During calm periods almost everything gets included quickly; during congestion, low-fee transactions can wait a long time as higher bids keep jumping the queue.

This is the mechanism behind fee volatility. When demand for block space rises, users bid more to be chosen sooner, and the effective cost of getting confirmed climbs. The way fees are structured, and which part actually rewards the validator, is explained in gas limit vs gas price and in what gas fees actually pay for.

Selection is not always as simple as “highest tip wins.” Block builders solve a packing problem: they have limited space and want to maximise the total reward from the transactions they include, subject to each account’s nonce ordering and the transactions’ gas costs. In practice this usually means well-tipped transactions confirm quickly and stingy ones wait, but the exact set chosen depends on what else is competing at that moment. This is why the same fee can confirm instantly at a quiet hour and languish during a surge.

Why the mempool enables MEV and front-running

Because pending transactions are visible in public mempools before they are confirmed, anyone watching can see what is about to happen. If a large trade is waiting, a bot can try to place its own transaction just before or after it to profit from the price impact, or reorder transactions within a block. This broad category of profit extracted by controlling transaction inclusion and ordering is known as maximal extractable value (MEV).

The mempool’s transparency is a double-edged sword: it makes the network open and inspectable, but it also exposes users’ intentions. Common patterns include front-running (acting ahead of a visible transaction) and sandwich attacks (placing transactions on both sides of one). We cover the mechanics and defences in what is MEV and front-running.

Private mempools and order flow

To reduce exposure to this kind of activity, some users and applications route transactions through private channels that deliver them straight to block builders instead of broadcasting to the public mempool. A transaction sent this way is not visible to the wider network before it is included, which can protect against front-running.

The trade-off is trust. When you use a private relay, you rely on that party to include your transaction honestly and not to misuse the early sight of it. Private order flow is a live area of debate precisely because it shifts power over ordering toward a smaller set of intermediaries. For most everyday transfers, the public mempool remains the default and works fine.

Watching the mempool yourself

You do not need special access to observe the pool. Block explorers show pending transactions, and node software exposes methods to inspect the pending and queued sets directly. Watching the mempool is a useful way to understand congestion: if the pool is deep and fees are climbing, a low-fee transaction will likely wait. Reading these signals is part of the broader skill of reading a block explorer, which turns raw on-chain data into something you can act on.

There is a security angle here too. Because the mempool is public, it is a place attackers watch closely. Automated bots monitor pending transactions for opportunities, and some scams rely on tricking you into signing something whose consequences only become clear once it is broadcast. The pool does not create these risks, but its transparency is what makes them possible at scale. Being aware that anything you broadcast is visible before it settles is a healthy default mindset when interacting with unfamiliar applications.

If a transaction of yours is sitting in the mempool and not moving, the fix is usually to replace it with a higher fee, using the same nonce, so a validator picks it up. That connects the mempool directly back to the nonce mechanism and the fee market.

Transactions can also leave the pool unconfirmed

Not everything in the mempool ends up in a block. A node keeps only a finite amount of memory for pending transactions, so when the pool fills it evicts the least attractive entries, typically the lowest-fee ones. A transaction that is underpriced for a sustained busy period can therefore be dropped from a node’s pool entirely without ever confirming. Because there is no single global pool, it may be dropped from some nodes while lingering on others, which is why a transaction can occasionally reappear or seem to vanish depending on which node your wallet is talking to.

This has a practical upside: a stuck, underpriced transaction is rarely permanent. It either eventually confirms, gets replaced by you, or is aged out of the pools. What it does not do is silently execute much later at a random time, provided you have not left it sitting with a valid nonce and enough balance indefinitely. Understanding this churn removes a lot of anxiety about a transaction that appears frozen: it is waiting in a queue, not lost.

The takeaway

The mempool is the space between broadcasting a transaction and having it confirmed. It is not a single global list but a loosely synchronised view held by each node, split into pending and queued transactions, and drained by validators who favour higher fees. That same public visibility makes the network transparent and, at the same time, creates the conditions for MEV. Understanding the mempool turns confirmation delays and fee spikes from mysteries into predictable consequences of a crowded waiting room.

Sources

• Transactions — ethereum.org
• txpool Namespace — go-ethereum
• EVM transaction pool: pending vs queued — Chainstack Docs
• Maximal Extractable Value (MEV) — ethereum.org