What Is a Mempool?

In brief

A mempool is a node’s local set of valid-looking transactions that are not yet in a block.

It is not a single global queue. Each full node keeps its own. Peers gossip transactions; nodes independently decide what to store, evict, or relay.

On Bitcoin, the mempool exists in memory while the node runs, but current Bitcoin Core saves it to disk on shutdown and reloads it by default. That corrects an outdated claim in the older developer guide that described the pool as non-persistent. SPV clients do not maintain a fully validated mempool because they do not track the complete UTXO set.

On Ethereum, an execution client checks a newly submitted transaction, then may add it to its local pool and gossip it. Some users instead send private order flow to builders or relays, so a proposer’s available transactions are not limited to the public gossip pool.

A transaction in the mempool is pending, not final. Inclusion depends on fees, validity, policy, and whoever builds the next block.

What sits in the pool

A mempool entry is a signed transaction that a node believes:

• is syntactically valid;
• pays enough, under that node’s policy, to be worth remembering;
• does not obviously conflict with the chain the node already has.

On Bitcoin, that means the inputs still look like unspent outputs, the scripts check out, and the fee rate is not below the node’s minimum. On Ethereum, the execution client checks the signature, the nonce (the sender’s next transaction number), and that the sender can cover value plus gas.

“Valid to this node” is not “will be mined.” Another node may reject the same transaction under a stricter policy. A later block may spend the same Bitcoin UTXO or increment the same Ethereum nonce first.

There is no one mempool

People say “the mempool” as if it were a shared bulletin board. It is closer to thousands of slightly different desks.

Gossip spreads transactions. Some never reach every peer. Some are evicted when memory is tight. Some are replaced under local policy: current Bitcoin Core uses full replace-by-fee without requiring the older BIP-125 opt-in signal, while Ethereum clients commonly accept a sufficiently higher-fee transaction with the same sender and nonce. Current Bitcoin Core normally persists its mempool across a clean restart.

That local view is why two explorers can show different “pending” sets. They are looking at their own nodes, plus whatever extra feeds they buy.

How a transaction gets in — and out

In. A wallet sends the signed bytes to a node (often a hosted RPC). The node validates, stores, and relays. ethereum.org: other nodes that hear it add it to their pools too.

Out, into a block. A Bitcoin miner or an Ethereum block builder selects a subset, often favoring profitable transactions subject to dependencies, validity, and block limits. Once a transaction appears in an accepted block, a node removes it and any now-conflicting entries from its pool.

Out, without settling.

• The sender replaces it.
• A conflicting transaction confirms.
• The node evicts it (low fee, expired, pool full).
• On Bitcoin, if a block that contained it later becomes stale, Bitcoin Core can put those transactions back in the pool, then remove them again if the replacement chain also includes them.

Fees are how you jump the line

Block space is scarce. Producers generally prefer higher-paying transactions.

On Bitcoin, selection commonly considers transaction-package fee rate in satoshis per virtual byte, not simply a first-in queue. On Ethereum under EIP-1559, a type-2 transaction specifies a max fee and max priority fee; the protocol burns the base fee and the proposer receives the effective priority fee. A higher tip can improve inclusion odds, but builders can also order transactions for other reasons.

A low fee can leave you pending for a long time. That is not a broken mempool. It is the market for the next block.

Why bots watch pending transactions

Because the pool is public on default gossip, anyone can see a large swap or a liquidation before it is confirmed. ethereum.org’s MEV page: searchers run bots on that data. A sandwich buys before your DEX trade and sells after. A generalized frontrunner copies a profitable pending transaction, swaps in its own address, and pays a higher gas price.

Flashbots and similar systems exist so searchers can send bundles to builders without putting them in the public mempool. That is a different trust model: you hide from frontrunners and depend on relays and builders.

Solana does not have a protocol-wide gossip mempool equivalent to Bitcoin’s or Ethereum’s. Transactions are forwarded toward current and upcoming leaders, which validate and schedule received packets through local queues. Those short-lived queues are not one shared public pool, so Ethereum public-mempool assumptions do not transfer cleanly to Solana.

What a pending status is not

Pending is not a guarantee. It is not a confirmation. It is not finality. It does not mean the recipient can safely treat the money as theirs.

Exchanges and merchants that credit on “0 confirmations” are taking a replacement and double-spend risk. That is a business policy, not a protocol promise.