Mempool in simple terms: how transactions wait for confirmation on the blockchain

Every transaction goes through several stages before it is recorded on the blockchain permanently and can no longer be altered:

Initiation by the asset sender;
Signing and broadcasting to the network;
Waiting for confirmation in the mempool;
Independent verification by miners and, ultimately, inclusion in a block.

It is during the waiting stage — before confirmation — that the transaction enters a special local storage area known as the mempool.

What is a mempool?

A mempool is a queue of transactions that have already been broadcast to the network but have not yet been confirmed or included in a block. Essentially, the mempool is a local hub for such transactions maintained by each network participant (miner) that creates blocks. The mempool serves as an intermediate buffer through which every transaction must pass before being added to the blockchain.

The term "mempool" is a combination of two words: "memory" and "pool." Literally, "mempool" means "memory pool," which quite accurately reflects the nature of this transaction processing mechanism.

The mempool plays a key role in blockchain network performance: mempool congestion is one of the reasons transactions may experience long delays, as well as higher network fees.

The mempool is an integral component of blockchain protocols based on the Proof-of-Work (PoW) consensus mechanism, such as Bitcoin, Dogecoin, Litecoin, Bitcoin Cash, and others.

How does a mempool work?

After a user sends a transaction, it is not immediately recorded on the blockchain for security reasons.

First, the transaction is placed in the mempool, where it waits to be processed by miners according to the priority rules of the specific network.

However, simply entering the mempool does not guarantee that a transaction will be confirmed by miners and, consequently, recorded on the blockchain. A transaction may remain in the mempool for two reasons:

Transactions with higher fees are given priority. Miners select transactions from the mempool based on their fee size: transactions with higher fees are generally included in a block sooner;
A block has limited capacity, while the mempool may contain more transactions than can fit into a single block.

For example, the average Bitcoin block size is currently about 1.6 MB. However, its capacity is not directly limited by its size in bytes, but by what is known as block weight — up to 4 million weight units (WU). The number of transactions that can fit into a single block depends on their structure and size. On average, a Bitcoin block currently contains around 4,000–5,000 transactions.

For example, if there are 10,000 transactions in the mempool before a block is created, no more than 50% of them will be included in that block. The rest will only make it into the next block, provided they are not overtaken by new transactions that are continuously broadcast to the network.

Transactions do not necessarily move from the mempool to the blockchain in the same order in which they were sent. This is because users compete with one another to have their transactions recorded on the blockchain sooner.

For example, if Alice sent a transaction before Bob but paid a lower fee, her transaction will remain in the mempool for longer. Moreover, the more participants who pay higher fees, the longer Alice's transaction will have to wait for confirmation.

After a transaction moves from the mempool to independent verification by miners, it must reach a certain number of confirmations. For example, on the Bitcoin network, a transaction receives its first confirmation once it is included in a block. Subsequent blocks increase the number of confirmations and reduce the likelihood of the transaction being reversed. Six confirmations are traditionally considered a high level of reliability, although the required number is determined by the specific service or recipient.

Note: Some exchangers may require a greater number of confirmations to complete an exchange — up to 12. In this way, exchangers protect themselves against fraud, since unconfirmed transactions may be canceled by the sender.

During the confirmation stage, miners verify:

The validity of the sender's signature;
The availability of the required amount in the balance;
The absence of signs of double spending;
Whether the fee is appropriate for the current state of the network;

If the initial verification is successful, the transaction is moved to the local mempool and propagated further across the peer-to-peer network for subsequent confirmations.

Only after the required number of confirmations does the transaction leave the mempool, enter a new block, and then become recorded on the blockchain.

What should you do if a transaction is "stuck" in the mempool for a long time?

When the network is under heavy load, transactions may remain in the mempool unconfirmed for several hours and, in some cases, even several days. A transaction may also be rejected altogether if the fee paid is too low.

However, there are ways to speed up a "stuck" transaction while it is still in the mempool.

Replacing the transaction

A transaction that has remained in the mempool for a long time can be accelerated using special built-in wallet features such as Replace-By-Fee (RBF).

Wallets that support RBF allow users to speed up a transaction in just a couple of clicks by increasing the fee. Essentially, the wallet simply replaces the current transaction with a new one carrying a higher fee.

However, it is important to keep in mind that some wallets may require RBF to be enabled beforehand; otherwise, accelerating a transaction in the mempool will not be available.

The same method can also be used to cancel transactions, although it should be noted that a network fee will still be charged.

Sending a "child" transaction

Advanced Bitcoin wallets allow users to apply the Child Pays For Parent (CPFP) method to help a transaction leave the mempool faster.

If a user controls an output of the stuck transaction, they can create another transaction with a higher fee, which is referred to as the "child" transaction.

The "child" transaction is then linked to the original one, allowing the miner to collect fees from both transactions. More precisely, the two transactions remain separate, but it becomes profitable for the miner to include them in the same block: the child transaction cannot be confirmed before the parent transaction. Therefore, a sufficiently high fee on the child transaction compensates for the low fee of the original transaction.