Bitcoin mempool and fees: how to read network congestion

1. Start with the waiting room, not the price chart

A headline says Bitcoin's network is congested. Your first question should be what the source measured. A mempool, short for memory pool, is a node's collection of unconfirmed transactions. A node is a computer running Bitcoin software. Its pending transactions have not yet been included in a block in its current chain.

There is no single authoritative waiting list shared identically by every node. Bitcoin's developer reference explicitly describes a mempool response as one node's view, which may be incomplete. Two explorers can therefore report different counts without either count describing the entire network.

Open the original dashboard and record its observation time. Check that you are viewing Bitcoin's main network, rather than a test network. A screenshot without those labels is a weak basis for comparing today's conditions with an earlier episode.

Further reading: Bitcoin developer reference: a node's mempool view

2. Separate transaction count, virtual size and memory

Bitcoin Core reports transaction count, combined virtual transaction size and computer memory usage as separate fields. Virtual size, commonly shown in vB, accounts for the different weighting of transaction data. It is not simply the number of bytes stored in a file, nor the amount of RAM a node uses.

This distinction changes how you read a crowded dashboard. A thousand small transactions and a thousand large ones have the same count but different combined virtual sizes. A chart of memory usage answers another question again. Before saying the backlog doubled, check which quantity doubled.

For a comparison over time, keep the explorer, metric and units consistent. Read fee levels alongside the backlog: a count alone does not show how strongly pending transactions are competing for inclusion. Keep an unavailable measurement marked as unknown instead of substituting a different size field.

Further reading: Bitcoin Core: mempool count, virtual size and memory fields

3. Read the fee rate before the total fee

A fee rate expressed in sat/vB means satoshis per virtual byte. One bitcoin contains 100 million satoshis. Multiplying the transaction's virtual size by that rate gives its fee in satoshis. The size matters; the bitcoin amount being transferred is not the multiplier.

Bitcoin.org explains that transaction complexity can affect fees, including spending several previously received amounts. A large-value transfer is therefore not automatically more expensive than a small-value transfer. Keep any separate service charge out of a comparison intended to measure the network fee.

Further reading: Bitcoin.org: transaction fees and bitcoin unitsBitcoin Core: fee and virtual-size terminology

4. Treat confirmation estimates as estimates

Bitcoin Core's fee estimator targets confirmation within a number of blocks when it has enough observations. Its documentation distinguishes estimation modes and allows an error when the available history is insufficient. A missing estimate is not evidence that the appropriate fee is zero.

A block target is also different from a clock deadline. Bitcoin.org describes block discovery as probabilistic: the interval varies. Do not turn a dashboard's suggested confirmation window into a promise that a transaction will settle at an exact time.

When comparing two fee recommendations, record their timestamps, units and target urgency. Different assumptions can produce different suggestions. A later observation may reflect changed conditions, so preserve the original observation when checking an earlier news claim.

Further reading: Bitcoin Core: fee-estimation targets and limitationsBitcoin.org: why confirmation times vary

5. Do not turn network activity into a trade count

A Bitcoin transaction is not necessarily one purchase by one new investor. Transactions can have multiple outputs, including change returned to the sender. The developer guide explains that structure; a simple transaction count does not identify the people or economic purpose behind it.

For example, someone moving coins between their own wallets does not establish a new purchase. Treat that as a possible explanation, not a claim about any particular observed transfer. Network activity, exchange trading volume and available trading liquidity answer different questions. A busy mempool alone cannot tell you whether market participants are buying or selling.

Further reading: Bitcoin developer guide: transactions, outputs and change

6. Keep a short congestion research note

Save the source URL, network, timestamp, pending count, virtual-size measure and fee-rate units. Then write the narrow observation you can support: for example, this explorer showed a larger backlog than in your earlier saved reading. List any missing fields before comparing the snapshots.

Use SynthSignal's news-check worksheet to separate that observation from the headline's interpretation. Follow the volume-and-liquidity guide if the story also discusses trading. Keep the unresolved question explicit: what additional evidence would connect this network activity with the market claim?