Is the mempool a single queue shared by everyone?

How does the mechanism work?

A node checks a transaction before admitting it to its mempool. Consensus validity and mempool policy are related but different: a transaction may satisfy block rules yet fail a particular node’s relay policy.

Nodes learn about transactions through peers. Transactions can be removed, replaced under applicable policies or included in blocks. A wallet’s pending status is therefore not evidence of a reserved position in a shared queue.

It is useful to describe a node’s knowledge explicitly. A missing transaction may mean it never arrived, failed policy, was removed, conflicted with newer information or became confirmed. Those possibilities are not interchangeable. The same displayed absence cannot tell you which occurred without more context. A block provides a new set of transaction data against which validation proceeds, while the resulting accepted state determines which outputs remain unspent. Follow that state transition when deciding whether an old pending transaction can still spend its inputs. A local waiting list is helpful information, but it is neither the ledger nor an irrevocable broadcast receipt.

How do dependencies change the waiting picture?

An unconfirmed transaction can spend an output created by another unconfirmed transaction. Call them parent and child. The child cannot be validated without knowing the parent’s output amount and script. A node’s local unconfirmed graph therefore contains dependencies, rather than a simple list sorted independently by each transaction’s fee rate.

Consider invented parent and child transactions, each measuring 100 vbytes. The parent pays 100 satoshis and the child pays 900. Individually their rates are 1 and 9 sat/vB. Together they pay 1,000 satoshis across 200 vbytes, or 5 sat/vB. This arithmetic illustrates why a child’s fee can matter to selection of its ancestor. It is not a promise that a particular package is relayed or mined.

Now suppose a node has never received the parent. Receiving the child alone does not supply the missing output’s full validation context. Another node with both transactions can have a different view. Limits on dependencies, memory use and admission vary with node policy and software version. This page deliberately does not turn one implementation’s default limits into permanent network-wide rules.

When a block arrives, validation uses the relevant confirmed state and earlier transactions in that block. A node can accept a valid block containing a transaction it did not previously retain in its mempool. Conversely, a transaction accepted locally into the mempool can conflict with a later accepted block and be removed. Local admission and confirmed inclusion are distinct events.