What Is the Mempool?
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.
Definition of 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]There Is No Single Mempool
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:
- Propagation delay: It takes time for a transaction to reach every node.
- Different node settings: Minimum fee rate, maximum mempool size, and other settings vary from node to node.
- Connection state: Depending on which peers a node is connected to, it may receive different transactions.
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.
How a Transaction Enters the Mempool
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.
How Miners Select Transactions
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)Mempool Congestion and Fee Competition
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.
Mempool Purging
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.
RBF and CPFP: Two Ways to Adjust Fees
If a transaction is stuck in the mempool because the fee was set too low, there are two methods to adjust the fee.
RBF (Replace-By-Fee)
This method replaces the transaction with a new version that has a higher fee.
- How it works: Broadcast a new transaction that spends the same inputs (UTXOs) but with a higher fee rate. Nodes replace the old transaction with the new one.
- Requirement: The original transaction must include an RBF signal (BIP 125). RBF is enabled when the nSequence value is less than 0xfffffffe.
- Use case: You set the fee too low and now need faster confirmation.
Original transaction: 5 sat/vbyte -> Waiting in mempool
RBF transaction: 25 sat/vbyte -> Replaces original TX -> Faster confirmationCPFP (Child-Pays-For-Parent)
The recipient creates a child transaction that spends an output of the unconfirmed transaction, attaching a high fee.
- How it works: To include the child transaction, a miner must also include the parent transaction. The child’s high fee compensates for the parent’s low fee.
- Use case: The recipient wants faster confirmation, or the sender did not enable RBF.
| 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) |
Hands-On: Reading Mempool Status on txid.uk
The home page of txid.uk shows the current state of the mempool in real time.
Information available:
- Unconfirmed transaction count: The total number of transactions currently waiting in the mempool
- Mempool size: The total data size (in MB) of waiting transactions
- Recommended fee rates: Fee rates for target confirmation times (next block, 30 minutes, 1 hour, etc.)
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.
The Mempool and the Risks of 0-conf (Zero-Confirmation) Transactions
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.
- RBF double-spend: The sender can use RBF to replace the transaction with one that changes the recipient address.
- Miner collusion: A miner can include a different transaction in the block instead of the original one.
- Propagation race: If two transactions spending the same UTXO are broadcast simultaneously, different nodes may have received different ones first.
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.”
Summary
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: