What Is the Bitcoin Mempool and How Does It Work?

The Bitcoin mempool (short for "memory pool") is the temporary holding area where unconfirmed transactions wait before a miner includes them in a block. Every full node on the network keeps its own mempool, and understanding how it fills and empties is the key to understanding why Bitcoin fees rise and fall.

How a transaction enters the mempool

When you broadcast a Bitcoin transaction, it doesn't go straight into a block. It first propagates across the peer-to-peer network, and each full node that receives it checks whether it follows Bitcoin's consensus rules: valid signatures, no double-spending of the same coins, correct format, and so on. If it passes these checks, the node adds it to its local mempool and relays it to its peers, who repeat the process. Within seconds, a valid transaction is typically sitting in the mempool of thousands of nodes worldwide.

Importantly, the mempool is not a single global list stored somewhere central — it's a loosely synchronized view held independently by each node. Most of the time, well-connected nodes have very similar mempools, but small differences can exist, especially during periods of high transaction volume.

Why transactions wait

Bitcoin produces a new block roughly every 10 minutes, and each block has limited capacity. When the mempool holds more transactions (measured in total vBytes) than a single block can fit, transactions must wait. Miners, trying to maximize the fees they earn from each block, sort the mempool by fee rate (sat/vByte, explained in detail in /blog/how-bitcoin-transaction-fees-work) and pick the highest-paying transactions first.

This means a transaction's wait time is relative, not fixed. The same transaction with the same fee could confirm in the very next block during a quiet period, or sit for hours during a congested one, because it's being compared against everyone else currently competing for space.

Reading mempool conditions

Several public tools visualize mempool state, typically showing:

• Mempool size — total data (in MB) waiting to be confirmed.
• Fee rate distribution — how many transactions are offering each sat/vByte rate, often shown as colored blocks representing "projected" future blocks.
• Pending transaction count — the raw number of unconfirmed transactions.

Reading these charts before broadcasting a transaction is the most reliable way to estimate what fee you'll need for a given confirmation target, more reliable than guessing based on past experience, since conditions change quickly.

Mempool size and network stress

Mempool condition	Typical experience
Small backlog (under ~5 MB)	Even low fees confirm within a block or two
Moderate backlog	Fee tiers matter; economy fees may take hours
Large backlog (sustained congestion)	Low fees can be stuck for many hours or days

During sustained congestion, some transactions with very low fees can remain unconfirmed for so long that wallets eventually drop them from the mempool (a process sometimes called "eviction" or "expiry"), especially if they haven't been included after roughly two weeks in most node implementations.

What happens to stuck transactions

If your transaction is stuck in the mempool with too low a fee, you generally have three options: wait for congestion to clear, use Replace-By-Fee to rebroadcast with a higher fee (see /blog/replace-by-fee-rbf-explained), or use Child-Pays-For-Parent to have a follow-up transaction subsidize the stuck one's confirmation (see /blog/child-pays-for-parent-cpfp-explained). Both fee-bumping techniques exist specifically because of how mempool prioritization works.

Mempool differences and why they matter

Because each node maintains its own mempool independently, there can be subtle disagreements about which transactions are "valid and pending" at any given moment, particularly around edge cases like conflicting transactions attempting to spend the same coins (a double-spend attempt). This is one reason merchants and exchanges wait for a transaction to be confirmed in an actual block rather than trusting mempool presence alone — our article on /blog/bitcoin-transaction-confirmations-explained covers why confirmation counts matter for security.

Mempool versus the confirmed blockchain

It helps to think of the mempool as a waiting room and the blockchain as the permanent record. Transactions in the mempool haven't been finalized; they can be replaced, reordered, or dropped. Once a transaction is included in a block and that block is buried under subsequent blocks, reversing it becomes computationally impractical. You can inspect both the mempool and confirmed blocks using a /blog/what-is-a-bitcoin-block-explorer, which typically shows pending and confirmed transactions in separate views.

Mempool policy varies slightly by node

Not every node follows identical mempool acceptance rules. Node software has configurable minimum relay fees and policies (for example, around transaction replacement or non-standard scripts), so in rare cases a transaction accepted by one node's mempool might be rejected or delayed by another's. This is a normal part of Bitcoin's decentralized design rather than a bug, but it's worth knowing if you ever see conflicting information about whether a transaction has propagated.

Bottom line

The mempool is Bitcoin's fee market in action: a constantly shifting queue of unconfirmed transactions that miners sort by fee rate. Watching mempool conditions before you transact, rather than relying on a fixed fee habit, is the most practical way to avoid overpaying or getting stuck, and it's foundational to understanding topics like fee bumping, confirmations, and block exploration covered elsewhere on this site.