Mempool

Overview

Why Mempool matters

After a wallet broadcasts a transaction, there is often a delay before a block producer includes it. The mempool lets nodes keep eligible transactions available for relay and potential selection. It also gives wallets and payment monitors an early indication that a sender attempted a transfer.

How it works

A Bitcoin node receives a signed transaction, checks format, basic spending conditions and its local relay policy, and may store and forward it. Miners often prioritize transactions by effective fee rate and other policy considerations when constructing blocks. Nodes impose memory limits, eviction rules and other restrictions, so a valid transaction can be absent from some mempools. A pending transaction may be replaced under applicable fee-bumping rules or fail to propagate widely. On other chains, pending transaction pools, nonces and fee markets work differently. No single explorer has an authoritative universal mempool view.

Why explorers can disagree about a pending transfer

A transaction may be broadcast to one node but not another because peers have different connectivity, fee thresholds or relay policies. An explorer can therefore report "not found" while a wallet displays "pending," and neither observation alone establishes the final outcome. In Bitcoin, replace-by-fee mechanisms and conflicting spends can alter which transaction a miner ultimately includes. On account-based chains, replacement rules around nonces and gas bidding create their own effects. For support teams, the safe workflow is to record all known transaction identifiers, poll reliable chain data, check the correct network and avoid refunding or requesting a replacement payment solely because one pending entry disappeared. The chain's eventual included state is stronger evidence than any individual node's pending pool.

A real-world payment example

A customer sends bitcoin for a $250 order; the store sees an unconfirmed transaction with the correct amount. The order interface can say "payment detected" without releasing an irreversible digital item yet. If fees spike and the transaction remains pending, the store tracks it until inclusion or an operational timeout. After a timeout, staff still check whether it confirms later before issuing conflicting instructions.

Limits and common misunderstandings

Seeing a transaction in a mempool is not finality. A zero-confirmation policy may be reasonable for particular low-risk flows, but it exposes double-spend and replacement risks. A dropped mempool entry is not conclusive proof that a transaction is impossible to confirm in the future.

How it differs from related concepts

Broadcast means the sender submitted a transaction; mempool means some nodes retain it pending inclusion; confirmation means it appears in the accepted chain.

Explore further

Official background: technical documentation.

Related glossary terms: Transaction Broadcast, Confirmation, Network Fee.