Bitcoin mempool & fees

The first time I sent a Bitcoin transaction, in 2017, I overpaid the fee by what would today be around twelve dollars. I had no idea the mempool existed. I picked the wallet’s “high priority” preset, hit send, and the network politely took my coffee budget for the week. If you have ever overpaid in fees — or worse, watched a transaction get stuck for three days because you paid too little — this article is for you. The mempool is the most important live concept in Bitcoin for anyone who actually moves coins, and almost nobody explains it well.

What the mempool actually is

The word “mempool” is short for memory pool. It is the private waiting room of unconfirmed transactions inside every Bitcoin node — including mine, sitting in a closet in Bangkok. When you broadcast a transaction, it propagates to the peers your wallet is connected to, and each peer that accepts it adds it to its own mempool, then forwards it to its peers. Within a few seconds the transaction has reached most of the network.

Here is the part most explainers get wrong. There is no single global mempool. Every node maintains its own copy. Yours might differ from mine by a handful of transactions at any moment — because of timing, RBF races, or stricter relay policy. When you look at mempool.space, you are looking at one well-connected node’s view. It is a very good proxy for network state, but it is not authoritative. The mempool is fundamentally a local data structure — which is why, if you really want to know what miners see, you eventually have to run your own node.

How a transaction gets there

Broadcast → propagation → mempool. That is the whole journey. Your wallet hands signed transaction bytes to a node, the node validates it (signatures, no double-spend, fee above relay minimum), and if everything passes it goes into the mempool and gossips to peers. There is no central server. The transaction does not “go to” miners directly — miners run nodes too, and pick from their own mempool when assembling the next block.

This is why Bitcoin Core’s minrelaytxfee matters. It is the floor below which most nodes will not even accept your transaction. Set a fee below that and your transaction may not propagate at all — it will silently die.

Why miners pick the highest-fee transactions

Block space is finite. A Bitcoin block can hold roughly one megabyte of legacy transactions, or up to four million weight units with the SegWit discount. That is the entire budget the network has to confirm the world’s payments every ten minutes. Miners are economically rational — they sort candidate transactions by fee-per-byte and pack the most lucrative ones until the block is full. The reference here is the original Bitcoin whitepaper, which sketched out fee competition as the long-term security model after subsidies decline.

So when the network is congested, fees rise — not because some authority sets them, but because users are bidding against each other for the same scarce ~4 MB of space.

Fees in Bitcoin are not a percentage

This is the single biggest mental shift for newcomers. You are not paying a percentage of the amount you send. A Bitcoin fee is a flat charge per byte of transaction data. The unit you will see everywhere is sat/vB — satoshis per virtual byte.

A typical single-input single-output SegWit transaction is about 140 vB. So if the recommended fee is 10 sat/vB:

10 sat/vB  ×  140 vB  =  1,400 sats

At a Bitcoin price of $75,000, 1,400 sats is roughly $1.05. That fee is the same whether you are sending $50 or $5 million. This is one of Bitcoin’s most underrated properties — the cost of moving value does not scale with how much you move.

Reading the recommended fees

Most wallets and explorers surface four bands. They are predictions of what fee will get you confirmed within a target window:

• Fast (~10 min, next block). The fee level that the top of the next mined block is expected to clear.
• 30 min (~3 blocks). Comfortable middle ground for most payments.
• 1 hour (~6 blocks). Cheaper, still reliable.
• Economy / minimum. The bottom of the mempool. Confirms whenever space opens up — could be hours, could be days.

A counter-intuitive note: when the mempool is empty, “Fast” can be the same as “Economy.” If demand is low, paying 1 sat/vB will land you in the next block. The fee bands are dynamic — they reflect current bidding pressure, not a fixed price list.

Mempool size, in vMB

The total size of pending transactions is measured in virtual megabytes (vMB). I find these rough buckets useful as practical thresholds:

• Empty: under ~5 vMB. Fees are minimal. Good time to consolidate UTXOs.
• Normal: 5–50 vMB. Standard fees, predictable confirmation.
• Congested: 50+ vMB. Fees climb sharply. Non-urgent payments should wait.
• Spiking: 100+ vMB. Something is happening — an inscription wave, an exchange rebalance, holiday remittance. Sit it out unless you have to send.

Each block clears roughly 1.5–2 vMB. If the mempool is 100 vMB, the minimum time for it to drain — assuming no new transactions — is about 50 blocks, or eight hours. That never actually happens because new transactions arrive constantly, but it gives you a feel for how persistent congestion can be.

Projected blocks

The cleverest visualization on mempool.space is the projected-blocks view. It looks at every unconfirmed transaction in the mempool, sorts them by fee rate the way a miner would, and assembles the next six to eight theoretical blocks. You can see exactly which fee tier your transaction would land in. If your tx is in projected block 1, you confirm in the next ten minutes. If it is in block 6, you are looking at an hour.

This single feature replaces all the guesswork around fee estimation. Look at the chart, find the fee rate at the bottom of the projected block you want, set your transaction to that, and you are done. The mempool.space API exposes this data publicly — every fee widget on this site reads from it.

Bumping a stuck transaction

You will eventually underpay. When you do, you have two options.

Replace-By-Fee (RBF)

BIP-125 is the standard that lets you broadcast a new version of an unconfirmed transaction with a higher fee. The replacement uses the same inputs, pays a higher fee, and competes with the original for inclusion. Miners take whichever pays more, and the original gets dropped from mempools.

For RBF to work, the original transaction must signal it (most modern wallets do this by default — Sparrow, Bluewallet, Phoenix). Some merchant-facing wallets disable RBF because, before confirmation, an RBF-signaling tx can theoretically be replaced by one that pays the merchant nothing. In practice this is overblown — zero-conf was never safe to begin with — but the concern is real and you will see RBF turned off in some payment flows.

Child-Pays-For-Parent (CPFP)

If you are the receiver, or if your wallet did not signal RBF, you can do CPFP. You spend the unconfirmed output in a new transaction with a high enough fee that the combined fee rate of parent and child is attractive to a miner. Miners include both transactions because they cannot include the child without also including the parent. You are essentially paying extra to drag your own stuck transaction along with you.

CPFP is more expensive than RBF in absolute terms, but it works in cases where RBF is not available. For Bitcoin Core users, the official documentation walks through both.

When to send

Watch the mempool chart for a day and you will start to see the rhythm. Activity is highest during US business hours and Asian morning. The cheapest windows I have observed, consistently, are early Saturday and Sunday evenings UTC, and weekday mornings before US markets open. Holiday weeks — late December especially — are usually quiet on the network because exchanges throttle internal sweeps.

If your payment is not urgent, set a low fee and wait. Most of the world’s “I need to send this right now” payments do not actually need to confirm in the next ten minutes. An hour is fine. Six hours is often fine. The patient transactor is the cheap transactor.

Why fees fluctuate

Four forces drive most of the variance:

• Ordinals and inscriptions stuff arbitrary data into transactions at high fee rates.
• ETF inflows trigger institutional rebalancing — chunky transactions between cold storage and trading desks.
• USDT and stablecoin remittance through wrapped flows creates pulses around payroll cycles.
• Holiday and time-of-day patterns are remarkably consistent — humans send money on a schedule.

None of this requires speculation. The chart shows it.

Run a node, check your own mempool

I have to say it. Every dashboard you read, including this one, is showing you somebody else’s view of the network. If you are making a meaningful transaction, you should run a Bitcoin Core node and query its mempool directly. The getmempoolinfo and estimatesmartfee RPCs will tell you exactly what your node sees, with no third-party trust assumption.

Running a node used to be hard. Today, with Umbrel, Start9, or a plain Raspberry Pi, you can be syncing the chain in an afternoon. The book Mastering Bitcoin by Andreas Antonopoulos remains the best on-ramp for understanding what your node is doing. Once you have your own mempool, the rest of this article is no longer theoretical — you can verify all of it.

Don’t trust. Verify.