The Bitcoin Mempool: How Unconfirmed Transactions Work

The Bitcoin mempool is the decentralized waiting room where transactions sit before they are permanently recorded to the blockchain. Rather than a single, centralized queue, the mempool is a collection of individual memory pools maintained independently by thousands of computers, known as nodes, across the global network ¹. Understanding how this distributed waiting area operates is essential for navigating transaction speeds, fee estimation, and network congestion.

When a user broadcasts a transaction to the $BTC network, it does not immediately enter a block. Instead, it undergoes validation by a local node, which checks that the digital signatures are valid and that the inputs have not already been spent ¹. Once validated, the node stores the transaction in its local memory—its mempool—and forwards it to neighboring nodes, which repeat the process until the transaction has propagated across the entire network ¹.

The Decentralized Nature of the Mempool

There is no single, official "Bitcoin mempool" ¹. Because Bitcoin is a peer-to-peer network, each individual node maintains its own version of the mempool based on the transactions it has received and validated. If a node is offline when a transaction is broadcast, or if its configuration filters out certain transactions, its mempool will differ from that of its peers.

Nodes allocate a specific portion of their random-access memory (RAM) to store these unconfirmed transactions. By default, many Bitcoin Core nodes limit this memory to 300 megabytes ². If the volume of pending transactions exceeds this limit, a node will automatically begin evicting the transactions that pay the lowest fee rates to protect its system resources from exhaustion ². Consequently, a low-fee transaction might exist in the mempool of some nodes while being completely rejected or cleared from the memory of others.

How Fees and Block Space Dictate Priority

Because block space is strictly limited, miners must prioritize which transactions to include in the next block. Under the Segregated Witness (SegWit) upgrade, the maximum size of a block is limited to 4 million weight units, which corresponds to a theoretical maximum of roughly 4 megabytes of transaction data, or approximately 1 megabyte of non-witness base data ³. This physical constraint creates a competitive market for block space.

Miners are profit-maximizing entities. They select transactions from their local mempools and package them into blocks to maximize the total fee revenue they collect. To compare the value of different transactions, miners do not look at the absolute fee paid in dollars or satoshis (the smallest unit of Bitcoin, where 1 BTC equals 100 million satoshis). Instead, they look at the fee rate, which is measured in satoshis per virtual byte (sat/vB) ³.

Virtual bytes (vB) are a measure of the transaction's data size, adjusted for how the data is structured under SegWit rules ³. A complex transaction with multiple inputs and outputs requires more data to describe and verify, meaning it occupies more virtual bytes. A simple transaction with a single input and output occupies fewer virtual bytes.

To understand how this works, consider a numeric example. Suppose Alice and Bob both want their transactions included in the next block:

• Alice sends a complex transaction that utilizes multiple historical inputs. Her transaction size is 500 vB, and she attaches a total fee of 10,000 satoshis. Her fee rate is 20 sat/vB (10,000 satoshis divided by 500 vB).
• Bob sends a simple transaction that utilizes a single input. His transaction size is 150 vB, and he attaches a total fee of 4,500 satoshis. His fee rate is 30 sat/vB (4,500 satoshis divided by 150 vB).

Even though Alice is paying more total satoshis (10,000 versus 4,500), Bob's transaction has a higher fee rate (30 sat/vB versus 20 sat/vB). A miner seeking to maximize revenue per unit of block space will select Bob's transaction before Alice's because it yields more fee revenue per virtual byte.

Why Transactions Get Stuck

When network activity increases, the rate of incoming transactions can easily exceed the rate at which miners can clear them. Bitcoin blocks are discovered, on average, once every 10 minutes ¹. If thousands of users broadcast transactions simultaneously, the mempool swells.

During these periods of high congestion, the minimum fee rate required to get into the next block rises rapidly. If a user broadcasts a transaction with a fee rate of 10 sat/vB, but the lowest fee rate currently being accepted by miners is 50 sat/vB, that transaction will remain unconfirmed in the mempool. It is "stuck."

A transaction is never truly lost or destroyed while in this state; it simply waits in the memory of nodes. If the network congestion subsides, miners will eventually work their way down to the lower-fee transactions, and the stuck transaction will be processed. However, if the mempool remains congested for an extended period, individual nodes may eventually evict the transaction from their memory entirely, typically after a default period of two weeks (336 hours) in Bitcoin Core ². If evicted, the funds remain at the sender's address as if the transaction had never been initiated.

Unsticking Transactions: RBF and CPFP

If a transaction is stuck in the mempool and needs to be expedited, users have two primary technical mechanisms at their disposal: Replace-by-Fee (RBF) and Child-Pays-for-Parent (CPFP).

Replace-by-Fee (RBF) is a protocol rule that allows a sender to replace an unconfirmed transaction in the mempool with a new version that pays a higher fee ⁴. For RBF to work, the original transaction must have been flagged as replaceable when it was first broadcast ⁴. The sender constructs a new transaction utilizing the exact same inputs but increases the fee rate. When nodes receive the new transaction, they verify that the fee rate is sufficiently higher to justify replacing the old transaction in their mempool, thereby discarding the stuck version and prioritizing the new one.

Child-Pays-for-Parent (CPFP) is an alternative mechanism that can be initiated by either the sender or the recipient of a stuck transaction ⁵. This method relies on the rule that a transaction cannot be confirmed until all of its parent transactions (the transactions that created the inputs it spends) are also confirmed ⁵.

If a transaction (the "parent") is stuck because its fee rate is too low, the recipient can create a new transaction (the "child") that spends the unconfirmed output of the parent. The recipient attaches a very high fee rate to this child transaction. To collect the lucrative fee from the child transaction, a miner is forced to also include the low-fee parent transaction in the same block, effectively pulling the parent through the queue ⁵.

Common Misconceptions

• "There is one official mempool that dictates the state of pending transactions." As established, the mempool is entirely decentralized ¹. Each node maintains its own local mempool. What one node sees as a pending transaction, another node may have already evicted or never received.
• "A pending transaction means my Bitcoin is temporarily lost or locked." Bitcoin does not leave the sender's address until the transaction is confirmed in a block. A pending transaction in the mempool is merely a declared intent to move funds. Until it is mined, the sender technically still controls the private keys to those inputs, though attempting to spend them again without RBF will be flagged as a double-spend attempt by nodes.
• "Higher dollar-value transactions are processed faster by miners." Miners do not care about the fiat value or the absolute Bitcoin value of the transaction. A transaction transferring $10 million worth of BTC and a transaction transferring $10 worth of BTC are treated identically if they have the same virtual size and pay the same fee rate in sat/vB.

How the Mempool Connects to the Market

The state of the mempool serves as a real-time barometer for on-chain activity and network demand. During periods of high market volatility, panic selling, or intense speculation, the mempool often swells as users rush to move funds to exchanges or secure their assets. This drives up fee rates, making small transactions economically unfeasible and increasing the cost of interacting with the network.

For market participants, monitoring the mempool is crucial for optimizing transaction costs. By analyzing the distribution of fee rates in the current mempool, users can avoid overpaying for transactions during quiet periods or underpaying during sudden spikes in activity. Understanding these dynamics is a fundamental step in mastering the mechanics of decentralized digital scarcity ⁶.