Each node's mempool is a private queue, not a shared record

Inherited archive entry · retained from the earlier edition. Its factual, legal and policy claims have not all been reverified for 19 September 2026. Research scope.

Each node keeps its own list

There is no single, canonical queue of unconfirmed transactions. The developer guide's peer-to-peer network chapter describes it directly: full peers may keep track of unconfirmed transactions which are eligible for the next block, a store it calls the memory pool or mempool, and adds that when a peer shuts down, its memory pool is lost except for transactions stored by its own wallet. Nodes relay transactions to each other with inventory and data messages, but each mempool is a local, non-persistent view; two well-connected nodes will usually agree closely, but agreement is not guaranteed at every instant, and lightweight clients keep no mempool at all because they cannot independently verify that a transaction has not already been mined.

What a fee estimate is predicting

Fee levels are not published anywhere in advance; they emerge from what recent blocks actually included. The estimatesmartfee reference describes a command that estimates the approximate fee per kilobyte needed for a transaction to begin confirmation within a chosen target of between 1 and 1,008 blocks. It offers two modes: an economical estimate more responsive to short-term changes but less certain to confirm on time, and a conservative estimate, the default, that satisfies a longer history and is more likely to be sufficient for the desired target. Either way, the number returned is a prediction built from a sample of past blocks, expressed per virtual byte with segregated witness data discounted, not a posted price.

A stuck payment is a pricing outcome

The transactions guide notes that fees are based on a transaction's byte size and the gap between its input and output value. A transaction that sits unconfirmed for an extended period has, in almost every case, simply paid a fee below what recent blocks were accepting, in a queue that other participants are also bidding into. That is a market and estimation outcome, not evidence that the underlying ledger has failed or lost the transaction; the transaction remains valid and eligible for inclusion whenever it clears that bar, or is replaced with one that does.

Questions to carry forward

• Is a quoted current fee a live estimate against a stated confirmation target, or a stale figure from a different market moment?
• Does a stuck-transaction complaint describe a fee that was below the recent block-inclusion range at the time it was sent?
• Could two services disagree about mempool contents simply because they are different, imperfectly synchronised nodes?

The mempool is a local prediction feeding into another prediction, the fee estimate; neither is a record kept anywhere in particular, and both resolve only once a block is actually found.