The bitcoin mempool

The mempool, short for memory pool, is each node's waiting area for valid transactions that no block has confirmed yet. Every node keeps its own pool in RAM and sets its own limits. Those limits decide which transactions the node accepts, which it drops when space runs short, and how long it holds on to them. This page covers those rules. For a plain definition, see the mempool word page.

A transaction in the mempool is not yet a payment. It is only waiting. If it leaves the pool without being mined, the network acts as if it was never broadcast, so wait for a block before you treat a payment as settled.

How big can a node's mempool grow?

By default, a Bitcoin Core node caps its mempool at 300 MB. The setting is maxmempool, given in megabytes. A node with more RAM can raise the limit to keep more transactions in view.

The limit counts each transaction's metadata as well as its raw bytes, so the pool holds less raw transaction data than the number suggests. Even so, 300 MB holds more than one full block's worth of transactions.

Why is the pool kept in RAM?

A node checks new transactions against the pool many times a second. It also checks each new block against the pool, and most of a block's transactions are often already there. Miners sort the pool when they build a candidate block. Keeping the pool in memory makes all three jobs fast.

Disk would be much slower. RAM is also far smaller than disk on a typical computer, which is why the default size is modest.

How does a transaction enter the pool?

A transaction reaches a node's pool in one of three ways.

1. You broadcast it

Your wallet sends the transaction to your own node. The node checks it, adds it to its pool, and relays it to the peers it is connected to.

2. Another node relays it

Nodes tell their peers about the transactions they hold. If a peer announces one that your node lacks, your node requests it, checks it, and keeps it if it is valid. Only valid transactions enter the pool or get relayed.

3. A chain reorganization returns it

If a node switches to a different chain, transactions from the blocks it dropped can come back into the pool. They come back only if the new chain does not already include them. The node then relays them again.

What fee does a node require?

Every node also sets the lowest fee rate it accepts into its pool. The setting minrelaytxfee is the fixed floor. Since Bitcoin Core 29.1, its default is 0.1 sat/vB, or 100 sat/kvB. Older releases used 1 sat/vB, so an old guide may give that figure.

The effective minimum is never lower than minrelaytxfee, and it can be higher. When the pool fills, the node evicts its lowest-paying transactions, and the minimum rises to the rate of the last one it evicted. As the pool empties, the minimum falls again. It halves about every 12 hours, and it falls faster when the pool is under half or a quarter full. A node that is short on space therefore refuses cheap transactions for a while.

When does a transaction leave the pool?

A transaction leaves a node's pool for one of five reasons.

1. It is mined

This is the normal end. When a block arrives, its transactions move from the pool into the chain, and the node removes them from the pool.

2. It conflicts with a mined transaction

If a block contains a transaction that spends the same coins, the pool entry is a double spend and is removed. Every transaction that depends on it leaves too, because its parent is gone.

3. It is replaced

A new version that spends the same coins and pays a higher total fee can replace the original. Since Bitcoin Core 28.0, released in October 2024, a node accepts such a replacement even when the original did not signal replace-by-fee. Bitcoin Core 29.0 removed the option to turn this off. The replacement must also pay for its own extra size, at the node's incremental relay fee.

4. It expires

Each node holds a transaction only for a set time. The default mempoolexpiry is 336 hours, which is 14 days. Earlier releases used 3 days. Bitcoin Core 0.14.0 raised the default to two weeks in 2017. After expiry, the transaction leaves the pool, and you can always broadcast it again.

5. It is evicted for space

When the pool is full, the lowest-fee transactions leave first. The node does not judge a transaction on its own fee alone. It uses the descendant feerate, which is the average fee rate of the transaction and all the transactions that depend on it.

How does eviction choose what to drop?

Take a parent with a low fee rate and a child with a high fee rate that spends one of its outputs. The child cannot be mined without the parent, and the pair's average can be high enough to keep both. The node keeps them, which is the intended result.

If a transaction has a low fee rate and no higher-fee descendants, its descendant feerate is low too. The node can then drop it together with everything that depends on it. None of those descendants could be mined without it, so the node loses nothing that could confirm soon.

What are ancestors and descendants?

An ancestor is an unconfirmed transaction that another transaction spends from. A descendant is a transaction that spends from one in the pool. A transaction cannot be mined until all its unconfirmed ancestors are mined, so the pool tracks these families.

Bitcoin Core limits how large a family can get, so one transaction cannot pull the pool into a huge tree. Before version 31.0, the limits applied per transaction: at most 25 ancestors and 25 descendants, with each family capped at 101 kvB.

Bitcoin Core 31.0 replaced them with cluster limits. A cluster is a group of connected unconfirmed transactions, and by default it may hold 64 transactions and 101 kvB. These limits are policy, not consensus, so they can change between releases. Check the documentation for the version you run.

Ancestors also matter for mining. A miner judges a transaction by its ancestor feerate, the average rate of the transaction and its ancestors together. A high-fee child can lift its low-fee parent into the next block. That is child pays for parent, and it works because the parent cannot be mined alone anyway.

Do all nodes share the same pool?

No. There is no single memory pool that every transaction enters. Each node keeps its own, and the pools differ a little, because of different settings, the timing of relayed transactions, and conflicting transactions in circulation. The pools overlap so much that people talk about "the mempool" as one thing. That is a fair shorthand for the general state of the network.

Which commands show the pool?

Bitcoin Core has three commands for looking inside your pool.

• bitcoin-cli getmempoolinfo gives the summary: the number of transactions, their total size, the size limit, and the current minimum fee.
• bitcoin-cli getrawmempool lists the transaction IDs in the pool.
• bitcoin-cli getmempoolentry <txid> shows one transaction's size, fees, ancestor and descendant counts, and whether it can be replaced.

Each entry carries this metadata with it. The pool has no fixed structure beyond that: it is a set of unconfirmed transactions, each with its size, fee, time of entry, and links to its parents and children.

Our explorer reads the same kind of data from our own node. Search for a transaction ID to see whether it is confirmed or still waiting. If yours has not appeared, check whether it was dropped before you pay again.

What should you take from this?

The pool is a set of local rules, not a promise. Two nodes can disagree about a transaction for a while. If you are waiting for a payment, a confirmation in a block is the only settled result. Until then, the transaction is still waiting its turn. See confirmation for how many blocks to wait.