Every Bitcoin transaction has to wait somewhere between the moment it is signed and the moment it is confirmed in a block. That waiting room is the mempool — memory pool, singular per node — and it is where the fee auction that determines confirmation time actually happens. Every wallet's "recommended fee" number is a guess about the mempool state at that moment. Reading the mempool yourself removes the guess.
What the mempool actually is
Each Bitcoin node keeps its own copy of the mempool: a set of valid, signed transactions it has heard about but not yet seen included in a mined block. When a transaction is broadcast, it propagates node-to-node across the network and lands in each node's mempool. When it appears in a mined block, every node removes it from its mempool. Simple lifecycle.
There is no global mempool. Each node's version can differ slightly based on what has reached it and when. Public block explorers (mempool.space, blockstream.info) present a merged view based on their own well-connected nodes, and their picture matches the miner-facing view closely enough for practical purposes.
The mempool has a size cap — 300 MB by default in Bitcoin Core — beyond which the lowest fee-rate transactions get evicted. On a busy day the mempool can grow to several gigabytes globally as fees skyrocket and low-fee transactions get purged.
Fee rate, not fee
Miners do not sort transactions by absolute fee. They sort by fee rate — satoshis paid per virtual byte (sat/vB). A large transaction paying a large fee can still land after a small transaction paying a smaller fee at a higher rate. This is why every mempool visualization is broken up into fee-rate bands: the horizontal or vertical axis you see is sat/vB, not sats.
Virtual bytes matter because SegWit and Taproot transactions get a size discount on witness data. A transaction's fee rate is calculated against its weight-adjusted size, not its raw bytes. Wallets handle the math; you just see the fee rate.
Reading the depth chart
The classic mempool visualization is a stacked histogram: sat/vB on one axis, unconfirmed transaction weight (in MB or MvB) on the other. Each fee-rate band is a color-coded slab. The size of each slab is the volume of transactions competing at that fee level.
Two things to read from the depth chart:
**The block-1 line.** Miners pack the next block with the highest fee-rate transactions available, roughly 4 MB of weight per block. If the top 4 MB of the depth chart is entirely one high fee band, everything at that band or above will make the next block. If block 1 spills into a lower band, transactions at the top of that lower band will confirm in block 1; transactions at the bottom won't.
**The block-2 and block-3 lines.** Same math, further down. If your desired fee lands above the block-3 line, you should confirm within 30-40 minutes barring unusual variance. If it lands below any modeled block, you are competing with everything that will pay to bump you.
Fee estimator sanity check
Every wallet has a fee estimator — usually "next block, ~10 minutes, ~30 minutes, ~1 hour" or similar. These are model outputs, not truth. They read the same mempool you can read, project miner behavior, and produce a suggestion.
Sanity check the estimator by looking at the actual mempool. If the estimator says 45 sat/vB for next block and the depth chart clearly has the top 4 MB starting at 30 sat/vB, the estimator is over-charging you. If the estimator says 20 sat/vB and the top 8 MB is over 25, the estimator is under-charging and you will wait longer than promised.
Where estimators fail most reliably is during rapid mempool changes — a memecoin drop hitting, an inscription wave landing, or a big exchange sweeping cold storage. The estimator's average lags the reality of the current minute.
Fee spikes: why and when
Fees spike when transaction demand exceeds block-space supply. Predictable causes: US market open (7-9 AM PT), stablecoin issuance events, exchange consolidations, NFT / Ordinals drops, memecoin activity peaks on chains that settle to Bitcoin.
Fees compress when demand drops: weekend nights UTC-5 to UTC+1, holiday periods, quiet market phases. Sending during compression can save 60-80% versus sending during a spike, for exactly the same transaction.
If you are not in a rush, watch the mempool for 30-60 minutes across a day. The floor tends to appear during a specific window per season; you can send then and pay a fraction of the peak rate.
Replace-by-fee: the correction mechanism
If you send a transaction at too low a fee and it stalls in the mempool for hours, Replace-by-Fee (RBF) lets you re-broadcast the same transaction with a higher fee, bumping the original. Most modern wallets support RBF as a checkbox during send.
RBF is what mempool-savvy senders do: broadcast at a low fee, see if it confirms in the natural window, bump if the mempool jumps. This costs slightly more in the cumulative fee if you have to bump, but it saves substantially if the low fee turns out to be enough.
Some exchanges disable RBF flagging on their outgoing transactions. Coinbase for example historically sent RBF-disabled transactions, which means the transaction cannot be bumped. If a Coinbase withdrawal stalls, you wait or ask support to re-broadcast.
Purges: when transactions vanish
If the mempool overflows and your transaction was at a low fee rate, your node — and probably many other nodes — will drop it. Your wallet may still show it as pending because your wallet only knows about your own submission, not about the network purge.
A purged transaction is not confirmed and it is not final. You can re-broadcast it from any node that still has it, or from your wallet, and eventually it will land or the funds will remain available in your wallet as unspent. If a transaction has been pending for more than 72 hours during a busy period, assume it was purged and either re-broadcast with a higher fee or use CPFP (Child-Pays-For-Parent) if it is a change output feeding another spend.
What to actually check before sending
Three things, in order:
1. Look at the depth chart at mempool.space — what is the minimum sat/vB for next-block inclusion right now? 2. Compare to your wallet's suggested fee — is the wallet over- or under-charging? 3. Decide urgency — pay for next-block confirmation only if the money is time-critical; pay for 30-60 minute confirmation for most cases; pay minimum for cold-storage housekeeping.
Do this three times and you will develop an intuition for what a "fair" fee looks like across mempool conditions. The wallet estimator becomes a starting point, not gospel.
