How the queue works
How selection works
Every node keeps its own copy of the pending pool. When a validator or miner assembles the next block, it picks from that pool, and it picks by profit.
On Bitcoin the ranking is fee per byte: a small transaction paying a modest fee can outrank a large one paying more in total, because block space is measured in bytes rather than in transactions. On Ethereum the ranking is gas price, with the same underlying logic.
Block space is finite and demand is not, so this is an auction. When more people want in than fit, the clearing price rises and everybody pays the new level.
What it tells you about network conditions
The pool is public, which makes it a live congestion gauge.
For Bitcoin, mempool.space shows the queue by fee level and estimates how long each level waits. Checking it before sending is how you avoid the situation described above, and it takes about five seconds.
A large pool means fees are climbing and confirmation is slow. An empty one means anything reasonable confirms in the next block or two.
Why a transfer gets stuck
One cause explains almost all of them: the fee attached was below what the market is currently paying.
Wallets estimate fees from recent conditions, and conditions change. A transfer sent just before a surge carries a fee that made sense two minutes earlier and no longer clears the queue.
Two other causes appear occasionally. A transaction spending an output that is itself unconfirmed waits for its parent. And a transaction that no node relayed never entered the pool at all, which looks identical from the sender’s side and is a different problem.
Two ways to unstick one
Replace-by-fee
The sender rebroadcasts the same transaction with a higher fee, replacing the original. This works only if the transaction was flagged as replaceable when it was created, and most wallets now do that by default.
Child-pays-for-parent
The recipient spends the incoming output while attaching a high fee. Miners wanting the child have to include the parent, so both confirm together. Useful precisely when the sender has gone quiet.
If neither is used
If neither happens, the transaction eventually drops out of the pool. Nodes discard pending transactions after a timeout, commonly around two weeks on Bitcoin, and the funds were never anywhere except the sender’s wallet.
What a merchant needs to know
Two things, and both concern how orders are treated.
A payment sitting in the mempool is not a payment. Crediting an order on zero confirmations means crediting something that can still fail, and the thresholds exist for this reason.
And the most common support conversation in crypto payments resolves here. A customer says they paid, the merchant asks for the hash, and the explorer shows it pending with a low fee. Nobody did anything wrong, and the answer is to wait or to bump the fee. A payment gateway handles the watching automatically, which is covered in the setup guide.