Mempool

The mempool ("memory pool") is the set of pending, unconfirmed

transactions a node has received but not yet included in a block. Every

full node keeps its own mempool. Block producers draw from it when they

build the next block, and explorers expose it so users can see what is

queued up.

How transactions enter and leave

A transaction's lifecycle through the mempool looks like this:

1. A wallet signs and broadcasts the transaction.
2. Nodes that hear about it run it through validity and policy checks (is

the signature valid, is the nonce correct, is the

fee high enough, does it conflict with anything already in the

mempool?).

1. If accepted, the transaction is added to the local mempool and gossiped

to peers.

1. A block producer picks transactions from its mempool, usually ordered

by gas fee or priority, and includes them in a

block.

1. Once a transaction is included, every node removes it from its mempool.

Until step 4 happens, the transaction hash

exists but no block number is associated with

it.

Where explorers surface the mempool

Different ecosystems surface pending transactions differently.

• bitcoin has the most explicit mempool tooling.

mempool.space (which tx.taxi routes Bitcoin lookups to) is built

entirely around visualising the mempool: pending tx counts, fee bands,

and projected block templates.

• EVM explorers such as the ones for ethereum,

bsc, and polygon typically expose a

"pending" view. Pending visibility is partial because each node's

mempool is private and propagation is imperfect; what one node sees as

pending another may not.

• solana and a few other chains do not have a

traditional gossiped mempool. Transactions are forwarded directly to

the current leader, which makes "pending" tooling chain-specific.

Why a transaction can disappear and reappear

A transaction can leave one node's mempool and come back. Common causes:

• Reorg of the tip block: if the block that included the transaction

is reorganised away, the transaction returns to the mempool for

re-inclusion in a later block. This is most visible on chains with

probabilistic finality.

• Eviction under memory pressure: nodes cap their mempool size. When

full, the lowest-fee transactions get dropped. A re-broadcast brings

them back.

• Replacement transactions: a wallet re-broadcasting the same

nonce at a higher fee can replace the earlier one in

the mempool. The earlier hash is now effectively dead; the new hash is

the live pending transaction.

• Peer-set differences: because the mempool is per-node and gossip is

not instantaneous, one explorer may show a transaction as pending while

another shows it as unknown.

What the mempool tells you

For users, the mempool is the answer to "why hasn't my transaction

landed?". Causes you will see, especially on EVM chains:

• Fee below the current base fee or below what block producers are

including.

• An earlier-nonce transaction from the same sender is stuck, blocking

later nonces from this sender.

• The transaction was replaced (so the original hash will never confirm).

For chain observers, the mempool is a leading indicator: high pending

volume implies upcoming congestion, and fee distributions across the

mempool feed wallet fee estimators.

Common gotchas

• A transaction that is not visible in your node's mempool is not

necessarily lost. It may be in other nodes' mempools.

• Pending pages on explorers are best-effort snapshots, not ground truth.
• "Mempool" is a loose term: some chains use words like "queue", "pool",

or "pending pool" with their own semantics. Always read the chain's

own documentation when reasoning about timing-critical scenarios.