Bitcoin Memory Pool

A Bitcoin transaction can remain unconfirmed while it waits for a miner to include it in a block. Nodes may store it in a mempool, a temporary collection of accepted, unconfirmed transactions.

Each node keeps its own changing mempool; the network has no shared one. Seeing a transaction in a wallet or explorer does not mean every node or a miner has received it. Mempools relay transactions and help estimate fees, but they do not guarantee that a miner will include a transaction in a block.

How Bitcoin transactions move

A Bitcoin transaction is broadcast to nodes, which check it against consensus rules and their own relay policies. Consensus rules determine whether a transaction is valid under Bitcoin’s shared rules. Relay policies add local conditions for accepting and forwarding unconfirmed transactions.

If a node accepts a transaction, it can store it in its mempool and pass it to peers. Because peers make their own decisions, a transaction can appear in some mempools and not others. A node’s rejection under its local policy does not, by itself, mean the transaction violates consensus rules.

Miners and mining pools build candidate blocks from transactions available to them. Once a block containing a transaction is accepted by the network, the transaction is confirmed and leaves the unconfirmed pool. A conflicting transaction can be confirmed instead, or a node can remove a transaction under its own limits and policies.

Why mempools affect fees

Block space is limited. When more transactions compete for space than upcoming blocks can include, miners have an incentive to choose transactions with higher fees. Wallets express fees as a fee rate, commonly measured in satoshis per virtual byte, or sat/vB. A satoshi is the smallest unit of bitcoin, and virtual size is a measure used to account for a transaction’s size under Bitcoin’s rules.

A node’s mempool shows some of the transactions competing for block space at that moment. Wallets use mempool information and past confirmations to estimate a fee, but no fee quote guarantees a particular confirmation time. Block timing varies, and miners choose which transactions to include. Other nodes may also have a different view of unconfirmed transactions.

Transactions can also depend on one another. If an unconfirmed transaction spends the output of another unconfirmed transaction, the first is its parent and the second its child. With child-pays-for-parent (CPFP), you create a child transaction with a fee high enough to make miners consider the parent and child together. Whether nodes pass along the package and miners include it depends on their policies and decisions.

You can also use replace-by-fee (RBF) to offer a higher-fee replacement for an unconfirmed transaction. Acceptance depends on the receiving node’s rules. Neither RBF nor CPFP guarantees that a miner will include the relevant transaction.

Why nodes keep different pools

Nodes receive transactions from different peers and apply local relay rules. They also have different settings and may remove transactions at different times. As a result, an explorer or wallet that shows pending transactions reflects the node or service it relies on, not a complete, official inventory of everything waiting across Bitcoin.

Mempools also help nodes receive blocks more efficiently. When a node already knows many of the transactions in a newly announced block, it can use that knowledge to rebuild the block from a short announcement instead of downloading every transaction in full. This helps nodes share and process blocks.

When a node removes a transaction

A node does not keep every transaction in its mempool forever. Bitcoin Core’s documented defaults include a maximum mempool size of 300 MB and an expiry time of 336 hours, or 14 days. These are Bitcoin Core settings, not rules that every Bitcoin node must follow. Operators can change settings, and other node software can use different policies.

When a Bitcoin Core mempool reaches its configured size limit, the node can evict transactions according to its fee-based policy. A transaction that disappears from one node may still be known to another. Its disappearance does not prove that it was confirmed or that every node removed it.

How Bitcoin Core groups mempool transactions

Bitcoin Core 31.0 introduced a cluster-based mempool design. It maps unconfirmed transactions and the links between transactions that spend each other’s outputs. A cluster is a group of transactions linked through those relationships. The design considers linked transactions together when choosing transactions for blocks or removing them from the mempool.

Bitcoin Core’s documented cluster limits are 64 transactions and 101 kB of virtual size per cluster. These limits describe Bitcoin Core policy, not consensus rules or limits that apply to all Bitcoin nodes. The design also changes how Core handles transaction replacement and related fee calculations, so older descriptions of its mempool rules may not match that version.

What to check when a payment is pending

If a transaction has not confirmed, check whether your wallet or node reports it as accepted and whether the status comes from a node you trust. An explorer’s listing is useful evidence that its service has seen the transaction, but it does not establish that the whole network has it.

For a delayed transaction, check the wallet’s fee guidance and whether it supports RBF or CPFP. Those options depend on the transaction and on node policies, and neither provides a fixed confirmation deadline. A low-fee transaction can wait while block space is busy, and a node can eventually remove it under its own rules.