How the Mempool Works

Every Bitcoin transaction goes through a holding stage before it is final. The moment you hit send, your transaction does not jump straight into the blockchain. Instead it enters a waiting area where it sits alongside thousands of other pending transactions, all competing for a limited amount of space in the next block. That waiting area is the mempool, and understanding it is the difference between a transaction that confirms in minutes and one that lingers for hours.

This article looks closely at what the mempool is, why there is not really one single mempool at all, how miners decide which transactions to confirm, and what you can do when a transaction gets stuck. It builds on the ideas covered in how Bitcoin transactions are verified and goes one level deeper into the economics and mechanics of getting confirmed.

What Is the Mempool?

The word mempool is short for memory pool. You can picture it as a waiting room where valid transactions rest until a miner selects them for a block. When a transaction is broadcast to the network, it is not yet confirmed. It is simply pending, held in the memory of the nodes that have received it, waiting for its turn.

The mempool is tightly linked to mining. A miner who is assembling a candidate block does not invent transactions. They pull them out of the mempool. In that sense the mempool is the supply of work that miners draw from. The role of the miner in choosing and confirming these transactions is covered in detail in the role of miners in the Bitcoin network.

One important point sets the tone for everything that follows. The mempool is not the blockchain. It is temporary storage. A transaction that sits in the mempool has not happened in any final sense yet. It only becomes permanent when it is written into a block. Until then, it can be replaced, dropped, or out competed by transactions paying higher fees.

Why There Is No Single Mempool

It is tempting to imagine the mempool as one big shared list that everyone can see. That picture is wrong, and correcting it is key to understanding Bitcoin as a decentralized network.

Every node keeps its own mempool. When Alice sends Bitcoin to Bob, her transaction reaches one node first. That node checks it, and if it is valid, stores it in its own memory pool and passes it along to the nodes it is connected to. Those nodes do the same. The transaction ripples outward across the network, one hop at a time.

Because this spreading takes time, no two nodes hold exactly the same set of transactions at the same instant. Some nodes have already received a given transaction while others have not yet seen it. Each node therefore has its own slightly different copy of the mempool.

This is why it is more accurate to talk about the mempool as a concept rather than as one physical place. The overlap between nodes is very high, usually well above ninety nine percent, which is why explorers tend to agree with each other. But that small remaining difference explains why two mempool websites can report slightly different transaction counts, and why a transaction can sometimes behave in surprising ways.

Propagation across the network is fast but not instant. Nodes do not blindly forward raw transaction data to everyone. Instead they first announce that they know about a transaction by sending just its short identifier. A peer that has not seen it then requests the full transaction, and only then is the complete data sent. This handshake avoids flooding the network with duplicate data and adds small, deliberate delays that also help protect the privacy of where a transaction originated.

How a Node Decides Whether to Accept a Transaction

A node does not accept everything it is handed. Before a transaction enters its mempool, the node validates it against the rules of the network and the history recorded on the blockchain.

It checks several things. The coins being spent must actually exist and must still be unspent, which means there have to be sufficient funds behind the transaction. The digital signatures must be valid, proving that the sender is authorized to move those coins. And the transaction must not conflict with anything already in the mempool. If two transactions try to spend the same coins, that is a double spend attempt, and the node keeps the first valid one it saw while rejecting the second.

If any of these checks fail, the transaction is rejected outright and never enters the mempool. If everything passes, the node stores it and relays it onward. The cryptography that makes those signature checks possible is explained in what is cryptography, and the verification process as a whole is covered in how Bitcoin transactions are verified.

The Journey of a Transaction

It helps to trace the full path a transaction takes. First, your wallet creates and signs the transaction, then broadcasts it to a node. That node validates it and, if it is valid, places it in its mempool and shares it with its peers. The transaction now propagates across the network and waits.

A miner assembling the next block selects transactions from their mempool, usually starting with the ones paying the highest fee rate, and includes yours among them. Once that miner finds a valid block and the rest of the network accepts it, your transaction has one confirmation. It has now moved from temporary storage in the mempool to permanent storage on the blockchain. As more blocks are stacked on top, the number of confirmations grows and the transaction becomes harder and harder to reverse.

Block Space, Weight, and Virtual Bytes

Block space is scarce, and scarcity is exactly what creates competition. A new block is found on average about every ten minutes, and each block can only hold so much.

In the early years a block was capped at one megabyte of data. The SegWit upgrade in 2017 changed how this limit is measured. Instead of a flat size cap, blocks now have a maximum weight of 4,000,000 weight units. To make this easier to reason about, the network also uses virtual bytes. One virtual byte equals four weight units, so a block holds roughly 1,000,000 virtual bytes worth of transactions.

The reason for the change is subtle. SegWit gives a discount to a part of every transaction called the witness, which holds the signatures. Witness data is counted at a quarter of the weight of other data. This does not make a transaction physically smaller on disk or on the wire. A transaction that is three hundred bytes is still three hundred bytes. SegWit simply counts the signature portion at a reduced weight when deciding how much it fills a block. The practical effect is that a typical full block today lands somewhere around one and a half to two megabytes of actual data, even though the old one megabyte concept is gone.

Virtual bytes matter because they are the unit fees are measured in. When you compare what one transaction pays against another, you are comparing fee per virtual byte, not the total amount sent.

The Fee Market: Bidding for Block Space

Since block space is limited and demand varies, a market forms. The price of getting in is the fee rate, measured in satoshis per virtual byte, written as sat/vB. A satoshi is the smallest unit of Bitcoin, one hundred millionth of a whole coin.

Here is the part that surprises many people. The fee has nothing to do with how much money you are sending. Sending the equivalent of one Euro or Dollar can cost exactly the same fee as sending the equivalent of one million Euro or Dollar, because the fee depends on how much block space the transaction occupies, not on its value. A transaction with many inputs takes up more virtual bytes and therefore costs more to confirm at the same fee rate.

A useful way to picture the fee market is a bus station. Buses leave roughly every ten minutes, and each bus has a limited number of seats. The passengers are transactions waiting to board. Those willing to pay for a priority seat get on the next bus, while those paying less wait for a later, less crowded bus. When the station is packed, prices rise because everyone is bidding for the few seats available. When the station is quiet, you can board cheaply. Fees and the block reward together pay the miners for their work, an incentive structure also tied to the Bitcoin halving, which steadily reduces the block subsidy over time.

How to Estimate the Right Fee

The smart way to set a fee is to look at what the network actually needs right now rather than guessing. Mempool explorers exist precisely for this.

A tool such as mempool.space shows projected blocks built from the current mempool next to the blocks that have already been mined. The projected blocks are recalculated every couple of seconds, so they shift as new transactions arrive and as blocks are found. The site groups recommended fees into tiers such as no priority, low priority, medium priority, and high priority, each mapped to how soon you want to confirm. These suggestions are a guide, not a promise, because every miner has a slightly different view of the mempool and its own way of selecting transactions.

Another well known tool is Johoe's mempool statistics, which displays unconfirmed transactions as colored bands stacked by fee rate, with the lowest paying band at the bottom and higher paying bands on top. Each new block usually removes only the top slice of demand. If a band sits there for hours without shrinking, it means transactions at that fee rate are not getting confirmed because higher paying transactions keep taking precedence. To choose a fee, you aim at or above the bands that have been clearing recently.

The general rule of thumb is simple. When the network is quiet, there is no reason to overpay. When it is busy, a slightly higher fee saves you from a long, uncertain wait.

When a Transaction Gets Stuck

If you pay a fee that is too low, your transaction can sit in the mempool for a long time. It is not lost and it is not broken. It is simply waiting for a moment when demand drops far enough that miners are willing to include it.

There is a limit to how long it waits, though. By default, nodes drop a transaction that has been stuck for around two weeks. When a transaction leaves the mempool without being mined, it is as if it never happened. The coins it tried to spend become available again, and they were always under your control the entire time. You can then rebroadcast the same transaction or build a new one.

Eviction and the Minimum Fee

Each node has a memory limit for its mempool, commonly set to a few hundred megabytes by default. When the mempool fills up, the node has to make room. It does this by evicting the lowest fee rate transactions first and raising its own minimum fee to the level of what it just threw out. Transactions paying below that floor will not even be relayed.

This minimum then slowly drifts back down during quiet periods until the next surge pushes it up again. On a calm network the floor is usually around one satoshi per virtual byte, which functions as the practical baseline cost of getting a transaction relayed at all.

Rescuing a Stuck Transaction: RBF and CPFP

If you do not want to wait, there are two well established ways to give a stuck transaction a push.

The first is Replace By Fee, or RBF. This replaces your unconfirmed transaction with a new version that pays a higher fee. The replacement reuses at least one of the same inputs, which guarantees a conflict with the original, so only one of the two can ever confirm. Most modern wallets expose this as a bump fee button. Since late 2024, the default behavior of Bitcoin Core treats transactions as replaceable even without an explicit signal, which has made fee bumping more reliable across the network. You can also use RBF to effectively cancel a payment by replacing it with a new transaction that sends the same coins back to yourself.

The second is Child Pays For Parent, or CPFP. Here you leave the stuck transaction alone and instead create a new transaction that spends one of its unconfirmed outputs while attaching a high fee. A miner who wants the generous fee on the child transaction has to include the parent as well, because the child cannot be valid without it. The two confirm together as a package. This is especially useful when you cannot use RBF, for example when you are the receiver rather than the sender. CPFP usually costs a little more overall, since you end up paying for the block space of both transactions.

Both techniques rely on the same core idea. Miners follow the money, so raising the effective fee rate makes your transaction more attractive to include. The conditions that have to be met for one transaction to spend the output of another come down to Bitcoin's scripting rules, explored in understanding Bitcoin Script.

Reading a Mempool Explorer

Block and mempool explorers turn the abstract idea of a waiting room into something you can actually look at. For any transaction, an explorer typically shows its identifier, called the TxID, which acts like a fingerprint for that transaction and is itself the output of a hash function. It also shows the number of inputs and outputs, the total amount moved, the fee rate in sat/vB, the total fee paid, and the size of the transaction in virtual bytes.

Some explorers go further and animate the mempool itself. Visualizers represent each pending transaction as a colored block, sized by value or by virtual bytes and colored by age or fee rate, then show those blocks dropping into each newly mined block as it is found. These views make the competition for space genuinely visible, and they are a good way to develop an intuition for how the blockchain grows one block at a time.

Mempool Policy vs Consensus Rules

There is a distinction here that trips up even experienced users, and getting it straight is one of the most clarifying ideas in all of Bitcoin.

Consensus rules are the network wide rules that define what makes a block or a transaction valid. No double spends, valid signatures, the supply cap, the block weight limit, and so on. Break a consensus rule and you fork yourself off the network, because no one else will accept your block.

Mempool policy is different. It is the local set of rules a node uses to decide which valid transactions it is willing to store and relay. The minimum fee, the kinds of scripts it considers standard, and the size of its mempool are all matters of policy. Two honest nodes can run slightly different policies without disagreeing about the blockchain at all. A transaction that one node refuses to relay because of its policy can still be perfectly valid, and it can still end up in a block if a miner chooses to include it directly. When that block arrives, the node will accept it without complaint.

In short, consensus rules decide what is true. Policy decides what a given node bothers to pass along.

Zero Confirmations

A transaction sitting in the mempool has zero confirmations. It is visible and it is valid, but it is not yet protected by any proof of work. That distinction has real consequences.

Until a transaction is mined, it can in principle be replaced by a conflicting version or double spent. This is why accepting a payment with zero confirmations carries risk, especially for anything of significant value. A merchant taking zero confirmation payments for a small, instant purchase is making a calculated bet that no one will bother to reverse a tiny amount. For larger sums, the safe approach is to wait for confirmations. A widely used guideline is to wait for six confirmations, roughly one hour, after which the chance of a reversal becomes vanishingly small. This is the practical meaning of the phrase that the mempool is not the blockchain.

The Mempool as a Security Layer

The mempool does more than buffer pending payments. It also helps defend the network.

Imagine an attacker trying to flood every node with an endless stream of tiny transactions in order to exhaust memory and bandwidth, a denial of service style attack. The combination of a minimum relay fee and a capped mempool size makes this expensive and self limiting. As the mempool fills, the fee floor rises, so each additional spam transaction costs more than the last. The cheapest, dustiest transactions are the first to be evicted. Flooding the network at scale therefore becomes economically painful rather than free, which is exactly the kind of incentive design that keeps Bitcoin robust without any central operator policing it.

Conclusion

The mempool is where Bitcoin's economics become tangible. It is the waiting room between hitting send and being confirmed, a per node memory of pending transactions rather than one shared list. Miners draw from it and prioritize by fee rate, because block space is genuinely scarce and the market for it is real.

Understanding this gives you practical control. You can read an explorer to set a sensible fee, recognize why a transaction is stuck, and use Replace By Fee or Child Pays For Parent to unstick it. And you can keep the most important rule in view at all times. A transaction in the mempool has not truly happened yet. Confirmation in a block is what makes it final, and that is the line that separates a waiting room from a permanent record.