The Bitcoin Mempool Explained

Reviewed and updated September 19, 2026 by the SmartCryptoEarnings editorial team · editorial policy

The mempool — short for memory pool — is the set of valid, unconfirmed transactions a Bitcoin node is holding in memory. It is the waiting room between broadcast and block inclusion, and almost every 'why is my transaction stuck' question is really a question about it.

The most common misconception is that there is one mempool. There is not. Every node maintains its own, from its own view of the network and under its own configured policy, and those views differ.

From broadcast to confirmationWhere an unconfirmed Bitcoin transaction actually sits, and who decides what happens next.

1. Wallet broadcastsThe signed transaction is handed to the peers your wallet is connected to. Seconds, and it reserves nothing.
2. Node mempoolsEach node checks it against consensus rules and its own relay policy, stores it in its own mempool, and relays it onward. Views differ from node to node.
3. Miner block templateMiners build candidate blocks from their own mempool, generally selecting the highest fee rate per virtual byte first, because block space is limited.
4. Block inclusionA miner finds a valid block containing the transaction. This is the first confirmation, and the fee is paid at this moment — not before.
5. Confirmations accumulateEach later block adds depth. How much depth a recipient requires is their policy, not a protocol rule.

The detour most explanations leave out

Between stages 2 and 3 a transaction can be evicted when a node's mempool fills, or expire after long enough unconfirmed. Either way it simply stops being tracked by that node. Nothing has been spent on-chain, so the coins remain yours — and a different node may still be holding the same transaction.

What happens the moment you broadcast

Your wallet hands the signed transaction to the nodes it is connected to.
Each node checks it against consensus rules and against its own relay policy. Both must pass; they are not the same set of rules.
A node that accepts it stores it in its own mempool and relays it onward to its peers.
The transaction propagates outward across the network this way, reaching most nodes quickly but never instantaneously or universally.
Miners build candidate blocks from their own mempool, generally selecting the transactions that pay the most fee per unit of block space.

There is no single global mempool

Each node has its own copy, built from what it has received and accepted. Two nodes queried at the same second can legitimately show different contents.
Nodes run different software versions with different relay policies and different configured limits, so a transaction one node accepts another may simply refuse to relay.
Mempool size limits are local. When a node's mempool is full it evicts the lowest fee-rate transactions to make room, which means low-fee transactions disappear from some nodes and not others.
Nodes also expire transactions that have been unconfirmed for a long time, on a timer each node sets for itself.
'Mempool statistics' published by any explorer are therefore that provider's node's view — a good proxy for network conditions, not an authoritative global ledger of pending transactions.

This is why a transaction can 'disappear' from one explorer and still be perfectly visible on another. Dropping out of a node's mempool does not spend, cancel or invalidate anything; the funds were never deducted from the chain in the first place.

Consensus rules versus relay policy

Two different rule sets decide what happens to your transaction, and conflating them causes a lot of confusion.

Consensus rules define what is valid in a block. Every node must agree, or the network would split. These change only through very deliberate, network-wide processes.
Relay and mempool policy is each node's own choice about what it will accept into memory and pass on. Policy is deliberately stricter than consensus, and it protects nodes from resource exhaustion.
A transaction can be perfectly valid under consensus and still fail to relay because it does not satisfy some node's policy. That is not a bug, and it is why wallets build transactions in conventional shapes.

Fee versus fee rate — the distinction that matters here

The total fee is the number of satoshis a transaction pays. The fee rate is that total divided by the transaction's size in virtual bytes, written sat/vB.

Miners have a limited amount of block space and want the most value from it, so they rank by fee rate, not by total fee. A large transaction paying a big total fee can be less attractive than a small one paying less overall but more per byte.

Practical consequence: raising the amount you send changes nothing about your position in the queue. Raising the fee rate does.

What congestion actually changes

Congestion does not make blocks slower or smaller. Block space per block is essentially fixed, and blocks keep arriving at the same average rate.
What changes is the price of that space. When more fee-paying demand arrives than the next blocks can hold, the fee rate needed to be included in the near term rises.
The backlog is often described in 'blocks' — an estimate of how many blocks' worth of transactions are currently waiting. It is an estimate derived from a single node's view, not a schedule.
When demand falls, the backlog drains from the top down and previously underpriced transactions become competitive again without anyone doing anything.

Why a transaction can stay unconfirmed indefinitely

It pays a fee rate that has never become competitive, and demand has not fallen far enough for it to clear.
It was evicted from some nodes when their mempools filled, so fewer miners are even aware of it.
It expired from node mempools after being unconfirmed for a long period, at which point the funds are simply still yours and unspent.
It depends on an unconfirmed parent transaction that is itself stuck, so it cannot be mined before its parent.

What you can do about it

Nothing you do to the mempool affects it — it is not a queue you hold a ticket in. The only levers are on the transaction itself: replacing it with a higher-paying version, or attaching a child transaction that makes the pair worth mining. Both are covered in detail on their own pages, and both depend on wallet support and on who controls the transaction.

Frequently Asked Questions

What is the Bitcoin mempool?

It is the pool of valid but unconfirmed transactions that a Bitcoin node keeps in memory while waiting for them to be mined. Every node keeps its own, and miners draw candidate blocks from theirs.

Is there one global mempool?

No. Each node maintains its own mempool from its own view of the network and its own policy settings. They usually overlap heavily, but they are not identical, and no single node's view is authoritative.

Why did my transaction disappear from the mempool?

Nodes evict low fee-rate transactions when their mempool fills, and drop transactions that have been unconfirmed beyond their expiry setting. Nothing is lost when this happens: the coins were never spent on-chain, so they remain available in your wallet, though the wallet may need a rescan to show that.

Does the mempool decide which transactions get mined?

Miners decide, using their own mempool as the candidate set. They generally select the highest fee rate first because block space is limited, but transaction selection is ultimately each miner's choice.

Does a fuller mempool mean slower blocks?

No. Block production is driven by mining difficulty, not by how many transactions are waiting. Congestion raises the fee rate needed for prompt inclusion; it does not change how often blocks appear.

Sources

Spotted something out of date? See our corrections policy and fact-checking policy.

Continue reading

Educational information only. Nothing here is financial, legal or tax advice.