A Bitcoin fee dashboard can help with transaction timing, but only if you know what its numbers describe. The mempool is a node’s local collection of valid, unconfirmed transactions. It is not a single global queue. Two nodes can briefly show different contents because they receive transactions at different times and may enforce different relay or memory policies.
Start with fee rate and virtual size
A transaction pays an absolute fee, while miners and wallets often compare transactions by fee rate. Bitcoin Core reports virtual size, or vsize, which discounts witness data under BIP 141. The practical calculation uses the fee divided by vsize. That is why a payment moving a small amount of bitcoin can cost more than a larger payment: the number and type of inputs and outputs can make the first transaction larger.
The getmempoolentry response separates a transaction’s base fee from fee values associated with its unconfirmed ancestors and descendants. It also reports vsize, weight, dependencies and transactions that spend its outputs. Those package relationships matter when a child depends on an unconfirmed parent. Reading one transaction in isolation may miss the fee economics of the package miners evaluate.
Read node-wide figures as conditions, not promises
Bitcoin Core’s getmempoolinfo command reports the current transaction count, total virtual bytes, memory use and total fees in that node’s mempool. It also exposes the maximum mempool allocation, minimum relay fee and current minimum fee for acceptance. If memory pressure raises the acceptance floor, a low-fee transaction may disappear from some nodes even though another node still retains it.
These figures describe the node at the moment of the request. They do not reserve space in a future block or guarantee a confirmation time. A fresh wave of higher-fee transactions can change the queue before the next block. A dashboard that groups transactions into fee bands is therefore a snapshot of competition for blockspace, not a booking system.
Use estimates with a stated target
Bitcoin Core’s estimatesmartfee asks for a confirmation target measured in blocks. Its economical mode responds more quickly to short-term declines in prevailing fees and may return a lower estimate. Conservative mode uses a longer horizon and may return a higher one. The command can return an error when the node has not observed enough transactions and blocks, so a missing estimate should not be replaced with a confident guess.
Before sending, record the target, fee rate and transaction vsize shown by the wallet. Confirm that the wallet supports fee adjustment if timing matters. After broadcast, check whether the transaction remains in the mempool and whether it has unconfirmed parents. Avoid rebroadcasting a second payment merely because a block arrived without yours; confirmation is competitive, and an accidental duplicate can create a different problem.
A compact fee check
- Choose a confirmation target in blocks rather than asking for a generic “fast” fee.
- Compare fee rates in satoshis per virtual byte, not absolute fees alone.
- Check whether unconfirmed parents affect the transaction package.
- Treat mempool totals and fee bands as local, time-sensitive observations.
- Use the wallet’s supported fee-bump method instead of improvising another payment.
A useful fee decision records what the wallet and node showed when the transaction was built. That record explains the choice later, even after mempool conditions have changed.
Adapted from Bitcoin Transaction Fees and Mempool Data: How Fee Signals Reveal Blockspace Demand.