Bitcoin Transaction Fees: sat/vB, Mempool Congestion and Fee Estimation

The unit that matters

A Bitcoin transaction does not carry a fee percentage. It carries a fee amount, and the network’s economy compares that amount to the space the transaction occupies. The comparison is expressed as a rate: satoshis per virtual byte, written sat/vB.

That is why two transfers of very different value can cost the same. A transaction with one input and two outputs has a shape, and the shape determines its size. The amount moved is a number inside an output; it does not change the number of bytes the transaction occupies.

Weight, vsize and the block budget

BIP141 defines the measurements that replaced a simple byte count:

The Bitcoin Developer Glossary states the same limit in the other unit: the current block size limit is 4 million weight units, or 1 million vbytes. A block is therefore a budget of about 1,000,000 virtual bytes, shared by every transaction a miner chooses to include.

The weight formula is what gives witness data its discount. If total size is base size plus witness size, then weight is four times base size plus witness size, and virtual size is base size plus a quarter of witness size. Non-witness bytes cost four weight units each; witness bytes cost one. A transaction’s vsize is therefore smaller than its raw byte length when it carries witness data, and the fee rate is quoted against the smaller number.

From BTC/kvB to sat/vB

Bitcoin Core’s estimatesmartfee RPC returns a fee rate in BTC per 1,000 virtual bytes. The source describes the result field as an estimate in BTC/kvB and the confirmation target as a value from 1 to 1,008 blocks. The RPC also exposes a choice of estimator: the default tries the mempool estimator first and falls back to the block-policy estimator, while block_policy and mempool_policy force one or the other.

Wallets usually display sat/vB, so the conversion is worth doing once and remembering:

1 BTC = 100,000,000 satoshis 1 kvB = 1,000 vB sat/vB = BTC/kvB × (100,000,000 ÷ 1,000) = BTC/kvB × 100,000

A Core estimate of 0.00001000 BTC/kvB is therefore 1 sat/vB. The arithmetic is not a market fact; it is a unit conversion, and it is the step most often skipped when someone compares an RPC output with a wallet screen and concludes the two disagree.

What the estimator is doing

The estimator answers a conditional question: what rate gives a reasonable chance of confirmation within a target number of blocks. The target is not a promise. It is an input to a model built from recently mined blocks and, depending on the estimator, from the current mempool.

The distinction between the two estimators is practical. A mempool-based estimate responds to what is waiting right now; a block-policy estimate is derived from the fee policy the node applies to blocks it would mine. When the mempool estimator cannot produce an answer, Core falls back to the block-policy estimate. Neither is a guarantee that a transaction will be mined by the target, because both are estimates of a competitive process rather than a reservation system.

A live snapshot

On 2026-10-26, the mempool.space recommended-fees endpoint returned:

The flat reading is itself informative. When every published tier returns the same number, the estimator is not finding a meaningful spread between faster and slower inclusion, and the minimum is the binding number. That describes a quiet mempool on that date, not a permanent floor. A snapshot is evidence of the moment it was taken, which is why the date belongs next to the number.

Congestion is a competition for a fixed budget

A block can hold about 1,000,000 virtual bytes. When the transactions offered to the network fit inside that budget, a low rate can be enough. When they do not, inclusion becomes a selection problem, and the selection is made from the transactions available to the miner, with the fee rate as the visible signal of what each one pays for its space.

This is why fee estimation is inherently backward-looking. The estimator reads recent blocks and the current queue, then projects. A sudden rise in demand can invalidate the projection before the next block arrives. The practical response is not to find a better estimator but to give the transaction a rate that is competitive with the queue it is actually in, and to check the queue rather than a remembered number.

A routine for setting a fee

1. Know the vsize before choosing a rate. The fee is rate × vsize, so a transaction with many inputs needs a higher absolute fee for the same rate. Consolidating small UTXOs is a fee decision made when you spend, not when you send.
2. Pick a confirmation target in blocks. A target of one block and a target of six are different products; the estimator will return different rates when the queue has a shape.
3. Read the rate in the unit you will sign with. Convert BTC/kvB to sat/vB before comparing it to a wallet display, and check that the wallet is not quoting sat/B against a vsize that already includes the witness discount.
4. Check the queue at the moment of sending. A rate that was competitive when the estimate was produced can be stale by the time the transaction is broadcast.
5. Do not confuse the fee with the amount. A 10 sat/vB rate on a 200 vB transaction is 2,000 satoshis, whatever the output values are.

The fee is a price for a measurable resource. Once the resource is measured in virtual bytes and the price in satoshis per virtual byte, the rest of the fee conversation becomes arithmetic plus a reading of the queue.

Risk note. The definitions in this article were read from BIP141, the Bitcoin Developer Glossary and the Bitcoin Core fee RPC source on 2026-10-26. The live fee snapshot was taken from mempool.space on the same date and is not a forecast. Nothing here is investment advice.