The Bitcoin mempool is a node’s collection of transactions it currently holds for possible inclusion in blocks. The blockchain is the chain of validated blocks that the node currently accepts. One is a changing local view of pending activity; the other records transactions in accepted blocks.
This distinction matters when two services disagree about a pending payment. A transaction appearing on one screen does not prove that every node has it. Its absence from another screen does not, by itself, prove that it was canceled or that its inputs are safe to spend again.
Rather than counting confirmations, this guide examines the waiting stage: whose queue you are viewing, which size and fee units you are comparing, and how dependencies change a transaction’s practical context.
The Bitcoin mempool is a local view
Bitcoin transactions are shared between peers before inclusion in blocks. Nodes apply their validation and local acceptance policies to what they receive. Different connections, arrival times, software settings, and resource limits can produce different pending sets.
The Bitcoin peer-to-peer developer guide explains transaction broadcasting and the role of the memory pool. Its broad distinction remains useful: observing an unconfirmed transaction is different from observing its inclusion in the accepted chain.
Think of a mempool display as a report from an observer, not a universal reservation book. To compare two observers, collect the transaction ID, network, time, and each service’s current chain tip. A delayed data feed or a lagging node can otherwise resemble a disagreement about the transaction itself.
It is also possible for a miner to receive transactions through routes that are not visible to a particular public dashboard. A block can therefore contain a transaction that your chosen observer never displayed as pending.
Acceptance, inclusion, and settlement are separate questions
A transaction can pass a node’s acceptance checks without being selected for the next block. Acceptance does not buy a fixed place in a first-in, first-out queue. New transactions and dependent transaction packages can change the set of candidates miners consider.
Likewise, consensus rules and relay policy serve different purposes. Consensus determines whether a block and its transactions are valid. Local policy helps a node decide which unconfirmed transactions to retain and relay. A transaction missing from one mempool is not automatically invalid under consensus rules.
A useful status note therefore avoids the vague label “processed.” Write “observed in node A’s mempool at 09:00 UTC” or “included in block with this hash.” For the next stage, the separate Bitcoin confirmations guide explains block depth after inclusion.
Read transaction size and fee rate together
Two transactions can pay the same total fee yet offer different fees relative to the block resources they consume. For a simple comparison, divide the fee in satoshis by virtual size in virtual bytes, abbreviated vB.
Suppose transaction A pays 3,000 satoshis and has a virtual size of 150 vB. Its fee rate is 20 sat/vB. Transaction B pays 4,000 satoshis but occupies 400 vB. Its fee rate is 10 sat/vB. B pays more in total while paying less per virtual byte.
Do not substitute the payment amount for transaction size. A larger BTC transfer does not necessarily need a larger transaction; inputs, outputs, and script structure matter. The amount sent and the resources consumed answer different questions.
Bitcoin Core’s getmempoolentry reference distinguishes virtual size, transaction weight, fees, and unconfirmed dependencies. It also identifies the entry time as local to the node, which is important when comparing “first seen” timestamps.
Worked example: a parent and child package
Now imagine an unconfirmed parent transaction P and a child transaction C that spends an output created by P. The child cannot be included ahead of its parent. For this fictional example, assume both are otherwise acceptable and there are no other dependencies.
- Parent P: 200 vB, fee of 400 satoshis, standalone rate of 2 sat/vB.
- Child C: 150 vB, fee of 6,600 satoshis, standalone rate of 44 sat/vB.
- Combined package: 350 vB and 7,000 satoshis, or 20 sat/vB.
The child’s 44 sat/vB label is not the whole economic picture because the parent must come with it. Dividing the combined fee by combined size produces 7,000 ÷ 350 = 20 sat/vB.
It would also be wrong to average 2 and 44 and report 23 sat/vB. The transactions have different sizes, so the package calculation is size-weighted. This is the same reason an average price should retain the quantities behind each observation.
The example explains the arithmetic behind child-pays-for-parent. It does not guarantee relay, acceptance, or mining. Actual software versions apply package and resource policies, and other ancestors or descendants may alter what a miner considers.
For research, save both the standalone rate and the dependency-adjusted calculation. If a dashboard shows a package estimate, identify what it included before comparing it with a plain transaction fee rate elsewhere.
A Bitcoin mempool size needs a unit
“The mempool is 200 MB” is incomplete without knowing what the service measured. It could refer to serialized data, summed virtual sizes, or the node’s actual memory use. These are not interchangeable.
The getmempoolinfo documentation provides separate fields for transaction count, summed virtual sizes, memory usage, and configured memory limits. It also reports the node’s minimum acceptance fee rate in BTC per kilovirtual byte.
For a unit conversion example, 0.00002000 BTC/kvB equals 2,000 satoshis per 1,000 vB, or 2 sat/vB. Copying the decimal directly into a sat/vB column would create a large error.
A falling queue count is also ambiguous. It might reflect inclusion in blocks, removal under local policy, replacement, or a changing observation set. Determine which event occurred before calling the decline “payments completed.”
Reconcile two Bitcoin mempool views
- Confirm identity. Match the full transaction ID and Bitcoin network, not just an address or a shortened label.
- Align the observation. Record timestamps and whether both services are synced to a comparable chain tip.
- Inspect inclusion separately. A transaction can disappear from pending results because it entered a block.
- Check dependencies and conflicts. A changed parent or a competing spend can matter more than the transaction’s standalone fee.
- Preserve uncertainty. If neither service explains the difference, record “not observed here” rather than “canceled everywhere.”
A blockchain explorer can help gather these fields, but its interface is still an observer’s presentation. Avoid repeatedly submitting new payments merely because one display has not caught up. First determine whether you are inspecting the same transaction and the same stage of its lifecycle.
Frequently asked questions
Is there one global Bitcoin mempool?
No. Each participating node maintains its own pending-transaction view. Public dashboards often present one node or an aggregation. Small differences can arise without any disagreement about already validated blocks, so the observer and timestamp belong beside the number.
Does being in a Bitcoin mempool mean a payment is complete?
It means that observer currently holds the transaction as pending. It does not establish block inclusion or final business settlement. A merchant or service may apply its own acceptance policy, which should be read separately from the network status.
Why does a high total fee not guarantee quick inclusion?
The fee must be assessed relative to virtual size and dependencies. A large transaction may pay more satoshis while offering a lower sat/vB rate. Miner selection, competing transactions, and local policy also prevent a universal completion guarantee.
Can a transaction vanish from a mempool without entering a block?
Yes. Local removal or replacement can change a node’s pending set. Absence from one service alone does not demonstrate global cancellation. Check the transaction, any competing spend, and the accepted chain before drawing a stronger conclusion.
What does first seen mean on a pending transaction?
It usually describes when a particular observer encountered the transaction. It is not necessarily the creation time or the earliest time any node received it. Compare first-seen values only after checking each service’s definition and clock.
Is virtual size the same as ordinary file size?
Not always. Virtual size reflects Bitcoin’s transaction-weight rules, including how witness data is treated. A serialized byte count can therefore differ. Use the size convention matching the fee-rate field instead of mixing figures from unrelated columns.
Can a child transaction help a low-fee parent?
A child can make the combined fee package more attractive because the parent must be included before its output can be spent. However, the relevant package must satisfy applicable policy and validity requirements; the arithmetic alone does not assure inclusion.
Does an empty dashboard mean nobody is sending Bitcoin?
No. The display may be stale, disconnected, narrowly scoped, or missing transactions delivered by other routes. Even an accurate low pending count is an observation at a moment, not proof that network transaction demand has disappeared.
Why might a fee estimate change before I send?
An estimate reflects an observed set of competing transactions and assumptions about future blocks. That evidence changes. Check its timestamp, target, and units; a previous estimate is not a reserved fee quote or a promise from miners.
Does deleting a pending entry from my wallet cancel it?
A local display or wallet action should not be treated as network-wide cancellation. Other nodes may still know the transaction. Determine what the wallet action actually does and verify the transaction’s network status before assuming the payment cannot confirm.
Explore the CrowdSent platform overview if you want to learn more about its approach to market research.
Educational information only. Examples are hypothetical and are not investment recommendations.