Mempool.space fee estimates: sat/vB and total cost
Mempool.space suggests Bitcoin mining fee rates for different confirmation priorities. The total mining cost also depends on a transaction’s virtual size, and a priority label does not guarantee a block or confirmation deadline.
Last updated:
Choosing a confirmation priority
The dashboard’s suggestions reflect competition for block space. High Priority is intended for confirmation as soon as possible. Medium Priority provides an intermediate suggestion, while Low Priority suits less urgent payments. No Priority is intended for transactions whose timing is flexible.
Mempool builds projected blocks from its view of pending transactions, accounting for fee rates, transaction sizes, and dependencies. Suggestions can be adjusted downward when projected blocks are not full. New transactions can change those projections, and miners may select a different set of transactions.
During congestion, the Purging figure indicates a rejection threshold observed on nodes with smaller mempool limits. A rate above that threshold helps with propagation, but it does not establish when a miner will include the transaction.
What determines the total mining fee?
A fee rate measures satoshis per virtual byte, written as sat/vB. Virtual size measures the transaction’s use of block space. The transaction size explanation identifies inputs, outputs, signatures, and transaction format as factors that determine size. The amount of bitcoin transferred does not by itself determine the mining fee.
Rate and size can change independently. Competing demand changes the suggested rate, while a wallet’s choice of inputs and outputs can change the virtual size. At an unchanged rate, a larger transaction costs more. At an unchanged size, choosing a higher rate increases the total fee proportionally.
Applying a rate to a transaction
When a wallet supports custom fee rates and reports transaction virtual size, the mining cost can be reviewed before broadcast.
| Stage | Fee information to use | Condition or limit |
|---|---|---|
| Read the suggestion | Compare the priority suggestions in sat/vB shortly before sending. | The rates reflect changing demand and do not reserve block space. |
| Prepare the transaction | Read the virtual size of the transaction that the wallet constructs. | Different inputs, outputs, or formats can change the size. |
| Review the mining fee |
fee (sat) = individual fee rate (sat/vB) * virtual size (vB)
|
Use the transaction’s own rate, rather than a package’s effective rate. |
| Broadcast the approved transaction | The sending wallet submits the transaction with its chosen fee. | A later dashboard estimate does not automatically change that fee. |
| Check confirmation status | The transaction record shows whether it has been included in a mined block. | Placement in a projected block remains a forecast. |
For a hypothetical transaction with a virtual size of 236 vB and an individual fee rate of 17 sat/vB, the mining fee is 17 × 236 = 4 012 satoshis. Keeping the size unchanged, a rate of 26 sat/vB produces a fee of 6 136 satoshis, an additional 2 124 satoshis. That difference buys a higher fee rate; the arithmetic cannot determine how much earlier the transaction will confirm.
Effective fee rates can include related transactions
Child pays for parent (CPFP) explains why a transaction’s own fee rate can be lower than the effective range displayed for its block. A child with a higher fee rate spends an unconfirmed output and raises the effective rate of the related package. The child’s fee must cover its own space as well as compensate for the parent’s lower rate.
A CPFP bump therefore adds a separate child transaction fee. It requires control of a spendable unconfirmed output and wallet support for the operation. The relevant combined fees and sizes determine the package rate, so a high rate on a small child can have a limited effect on a large parent.
For unconfirmed transactions, Mempool also accounts for adjusted virtual size, which can exceed ordinary virtual size when signature-operation requirements are high. Multiplying a displayed effective package rate by one transaction’s ordinary virtual size may therefore fail to reproduce that transaction’s individual fee. Where CPFP relationships are present, the transaction details can show the effective rate and links to the related transactions alongside its own fee information.