Antminer X9
Monero ASIC Miner
1000KH
HASHRATE
2.47W/KH
EFFICIENCY
2470W
POWER
£861.56
EST. MONTHLY
205
DAYS
EST. ROI
The Bitcoin mempool is a node's local collection of valid transactions that have not yet entered a block. It is often described as one waiting room, but there is no single global list. Every node builds its own view from transactions it receives and accepts under its policy.
A wallet saying pending usually means the payment has been broadcast and seen, not confirmed. It can be selected by a miner, replaced, evicted or forgotten by some nodes. Understanding that difference prevents a coloured status icon from being mistaken for final settlement.
Estimated reading time: 7 minutes
TL;DR
- Each node keeps its own Bitcoin mempool rather than consulting one central queue.
- Transactions compete mainly by fee rate and package value, not simply by the total fee paid.
- Unconfirmed payments can be replaced, evicted or delayed, so check their inputs and confirmation state.
What This Means in Simple English
The Bitcoin mempool is a node's temporary tray of checked but unconfirmed payments. Miners choose transactions from the trays they can see and try to put them into the next block. Different trays can hold slightly different payments.
Simple Example
Several post offices receive valid parcels during the day. Each office has its own shelf, space limit and arrival order. The delivery lorry chooses parcels that fit its route. A parcel on one shelf is not yet delivered and may not be on every shelf.
Key Terms in Plain English
| Unconfirmed: | Seen by software but not included in an accepted block. |
|---|---|
| Fee Rate: | Fee divided by transaction virtual size, usually shown in satoshis per virtual byte. |
| Eviction: | Removal from a node's mempool when policy or space requires it. |
| RBF: | A method for replacing a signalling unconfirmed transaction with a higher-fee version. |
| Package: | Related parent and child transactions assessed together in some policy decisions. |
How the Bitcoin Mempool Is Built
A node receives a transaction from a wallet or peer and checks its format, inputs, signatures, amounts and relevant policy. If it passes and does not conflict with accepted local data, the node may store and relay it.
Another node may never receive that transaction or may reject it under a different local limit. Mempool contents therefore converge often but are not guaranteed to match exactly.
Why a Valid Transaction Can Still Wait
Block space is limited and miners choose which valid transactions to include. When demand is high, transactions offering stronger fee rates and useful package value tend to be selected sooner.
A low-fee payment may wait through many blocks even though nothing is technically wrong. Time alone does not raise its fee or reserve space. Wallet fee-bumping features may help where their conditions are met.
Total Fee versus Fee Rate
The total fee is the difference between input value and output value. Miners also care about how much block weight the transaction uses, so the comparison is commonly expressed as satoshis per virtual byte.
A large consolidation can pay more satoshis overall yet offer a lower fee rate than a small payment. Wallets should estimate from current conditions rather than copying a total fee from somebody else's transaction.
Replacement and Conflicting Payments
Replace by fee allows a suitably signalling unconfirmed transaction to be replaced under node policy by another transaction paying enough additional fee. Wallet support and current rules matter.
Conflicting transactions try to spend the same output. Nodes normally keep one acceptable version under their policy. A merchant accepting an unconfirmed payment carries more replacement and propagation risk than one waiting for confirmations.
Eviction, Expiry and Restart Behaviour
A node limits memory use. When its mempool is full, lower-value transactions may be evicted as the minimum accepted fee rate rises. Transactions can also expire after the node's configured retention period.
Modern Bitcoin Core can persist mempool data across clean restarts, but this is local behaviour, not a permanent network record. A transaction forgotten by one node may still exist elsewhere and later return.
How Miners Use Mempool Data
A mining node or template provider selects transactions while respecting consensus, weight, dependencies and local policy. Package relationships matter because a high-fee child may make an otherwise low-fee parent valuable together.
A pool can omit transactions, use a different node or receive them at a different time. Comparing one public mempool website with a mined block does not by itself prove misconduct.
How to Check a Pending Payment
Record the transaction identifier, inputs, outputs, fee rate, replaceability and the time it was broadcast. Compare more than one node or use your own node when the payment matters.
Do not rebroadcast a different spend blindly or reveal a seed phrase to a fee-recovery site. Use documented wallet replacement or child-pays-for-parent tools and confirm which output remains under your control.
What a Mempool Chart Can and Cannot Say
Charts can show a site's observed transaction count, virtual size and fee-rate bands. They are helpful for seeing demand, but they display one observer's data and grouping choices.
A chart cannot guarantee the next block, identify every miner policy or promise a particular confirmation time. Save the source and timestamp when using it for an operational decision.
What the Current Data Can and Cannot Tell You
Bitcoin Core mempool policy changes between releases. Current package relay, replacement, minimum-fee and expiry behaviour must be checked against the installed version.
Public fee websites observe different peers and may update at different speeds. Small differences are expected rather than evidence that one site is false.
The mempool contains transaction data that may reveal patterns. Running a node improves control but does not automatically make wallet behaviour private.
Decision Table
| State | Meaning |
|---|---|
| In Mempool | Accepted locally but not confirmed |
| Evicted | Removed from a particular node's waiting set |
| Replaced | A conflicting version is preferred under policy |
| Confirmed | Included in a block accepted by the node |
A table is a starting point, not a promise. Verify current official sources and apply each detail to the decision you are actually making.
Frequently Asked Questions
Is There One Global Bitcoin Mempool?
No. Each node keeps its own local set.
Does Pending Mean the Payment Failed?
No. It may be valid but still waiting for block space.
Can a Mempool Transaction Disappear?
A node may evict or expire it, though another peer can still retain and rebroadcast it.
Do Miners Choose the Largest Total Fee?
They normally compare fee rate and package value within block rules, not total fee alone.
Can I Speed Up a Transaction?
Some wallets support replace by fee or child pays for parent when the transaction structure permits it.
Conclusion
The Bitcoin mempool is a local waiting set, not a central queue or a promise of confirmation. Nodes apply policy, miners choose valid packages and conditions change as demand moves. Check fee rate, replaceability, dependencies and the view of more than one node before acting on a pending payment.
Sources and Further Reading
- Bitcoin Developer Guide: P2P Network
- Bitcoin Core Mempool Policy Documentation
- Bitcoin Core BIP Implementation Notes
- Bitcoin Core 0.15 Fee And Mempool Notes
Build the full picture with our Bitcoin beginner guide, Bitcoin block guide and mempool and fee operations library.
Join the ASIC Mining Discussion
Members can read and join the discussion
Log in to read comments from other miners. Create a free account if you would like to ask a question or share your experience.
Membership helps us protect the discussion from spam and keep answers useful.