How the mempool works: the waiting room for Bitcoin transactions before they are included in a block. Covers each node's independent mempool, miner transaction selection, fee competition, RBF and CPFP, and the risks of zero-confirmation transactions.
What happens when you press the send button in your Bitcoin wallet? The transaction is not immediately recorded in a block. Between the moment you press send and the moment the transaction is included in a block, there is always a waiting period. This waiting space is the mempool.
Mempool is short for Memory Pool. It is the temporary storage space on the Bitcoin network where unconfirmed transactions -- those not yet included in a block -- wait.
A new Bitcoin block is produced roughly every 10 minutes on average. All transactions that occur during those 10 minutes cannot be processed immediately; they wait in the mempool for their turn. When a miner constructs the next block, they pull transactions from the mempool and include them.
[Sent from wallet] -> [Broadcast to network] -> [Waiting in mempool] -> [Selected by miner] -> [Included in block] -> [Confirmed]People commonly refer to "the Bitcoin mempool" as if it were a single place, but in reality no single unified mempool exists. Each node participating in the Bitcoin network maintains its own mempool independently.
The mempool of a node in Seoul and the mempool of a node in New York are mostly similar, but not identical. The reasons include:
So when we say "the transaction is in the mempool," what we strictly mean is "the transaction is in a particular node's mempool." In most cases transactions spread across the entire network within seconds, so in practice the difference is negligible.
A transaction goes through the following stages from creation to inclusion in a block.
Step 1: Broadcast The wallet software sends the signed transaction to a connected Bitcoin node.
Step 2: Node Validation The node that receives the transaction validates it. Key validation checks include:
| Validation Check | Details |
|---|---|
| Signature validity | Was the transaction signed by the private key owner? |
| Double-spend check | Has the input UTXO already been spent? |
| Fee sufficiency | Does it meet the minimum relay fee? |
| Script validity | Are the locking/unlocking scripts correct? |
Step 3: Added to the Mempool If the transaction passes validation, the node adds it to its own mempool.
Step 4: Relayed to Neighboring Nodes The node notifies its connected peers about the new transaction. Each receiving node runs the same validation process, adds the transaction to its own mempool, and relays it further. This cycle repeats until the transaction has spread across the entire network.
Transactions that fail validation are neither added to the mempool nor relayed.
When constructing a new block, miners select transactions from the mempool. They cannot include all of them because blocks have a size limit.
Bitcoin's block size limit is 4 MB (4,000,000 weight units). A typical block contains roughly 2,000 to 4,000 transactions.
The miners' selection criterion is straightforward: transactions with the highest fee rate (sat/vbyte) are included first. A miner's revenue is the sum of the block reward and fees, so for the same block space it is rational to include the transactions that pay more in fees.
Transactions in the mempool (ordered by fee rate):
50 sat/vbyte ████████████ <- Included in next block
30 sat/vbyte ██████████ <- Included in next block
15 sat/vbyte ████████ <- Included in next block
─────────────────────────── Block size limit (4 MB weight)
8 sat/vbyte ██████ <- Waiting
3 sat/vbyte ████ <- Waiting
1 sat/vbyte ██ <- Waiting (extended)When the mempool fills with transactions, competition intensifies. Since the number of transactions that can fit in a block is limited, faster confirmation requires setting a higher fee rate.
Examples of fee rate variation with network congestion:
| Network State | Unconfirmed TXs | Next-Block Fee Rate | Expected Wait (1 sat/vbyte) |
|---|---|---|---|
| Light | Thousands | 1--2 sat/vbyte | 10--20 minutes |
| Normal | Tens of thousands | 5--15 sat/vbyte | Several hours |
| Congested | 100,000+ | 50--200 sat/vbyte | Days to indefinite |
Around the 2024 Bitcoin halving, fee rates surged to several hundred sat/vbyte. Conversely, on weekends or during the early morning hours in Korean time (morning UTC), the mempool tends to be relatively light.
Each node's mempool does not hold transactions indefinitely. Bitcoin Core's default maximum mempool size is 300 MB.
When the mempool reaches its limit, the node purges transactions with the lowest fee rates first. A purged transaction disappears from that node's mempool but has not necessarily vanished from the network -- it may still exist in other nodes' mempools.
Additionally, Bitcoin Core by default expires transactions that have remained in the mempool for more than 14 days (336 hours).
Mempool purging conditions:
1. Mempool size reaches 300 MB (default)
2. Lowest fee-rate transactions are removed first
3. Transactions below the minimum relay fee (minrelaytxfee) are rejected
4. Transactions unconfirmed for over 14 days expireA transaction removed from the mempool is not cancelled. The UTXO still belongs to the original owner, and they can create a new transaction to send it again.
If a transaction is stuck in the mempool because the fee was set too low, there are two methods to adjust the fee.
This method replaces the transaction with a new version that has a higher fee.
Original transaction: 5 sat/vbyte -> Waiting in mempool
RBF transaction: 25 sat/vbyte -> Replaces original TX -> Faster confirmationThe recipient creates a child transaction that spends an output of the unconfirmed transaction, attaching a high fee.
| Comparison | RBF | CPFP |
|---|---|---|
| Who acts | Sender | Recipient (or sender) |
| Mechanism | Replaces existing TX | Adds a new TX, raising aggregate fee |
| Prerequisite | RBF signal required | Unconfirmed output must exist |
| Efficiency | High (no additional data) | Lower (extra cost for child TX size) |
The home page of txid.uk shows the current state of the mempool in real time.
Information available:
If the unconfirmed TX count is high and the mempool size is large, the network is congested and a higher fee rate is needed. Conversely, if the mempool is nearly empty, even the minimum fee rate (1 sat/vbyte) may be enough to get into the next block. On stats.txid.uk, you can view trends such as mempool size and average fee rate on time-series charts, which helps predict when fees will be low.
A transaction that has entered the mempool but has not yet been included in a block is called 0-conf (zero-confirmation). Some merchants and services accept 0-conf transactions for faster payments, but this carries risks.
A transaction must be included in a block and receive at least 1 confirmation to be definitively valid. For high-value transactions, the convention is to wait for 6 confirmations (approximately 1 hour). Being in the mempool means "the network has been notified," not "the transaction is finalized."
The mempool is the temporary space where Bitcoin transactions wait before being included in a block. Each node independently maintains its own mempool, and miners prioritize transactions with higher fee rates when filling blocks. When the network is congested, fee competition intensifies, and fees can be adjusted after the fact using RBF and CPFP. Checking the mempool's state and setting an appropriate fee rate is the key to using Bitcoin efficiently. Make a habit of checking the real-time mempool status at txid.uk.
Related articles: