Fee Rate (sat/vB)

Fee rate, quoted in satoshis per virtual byte (sat/vB), is the price a sender offers for each unit of block space their transaction consumes. It is what miners actually rank transactions by: a transaction's total fee equals its size in virtual bytes multiplied by its fee rate, and because block space is strictly limited, miners fill their block templates with the highest-paying transactions first. Two transactions paying the same total fee are not equal in a miner's eyes — the smaller one pays more per byte and wins the slot.

What a virtual byte is

Since the SegWit upgrade, transaction size is measured in weight units, where one virtual byte equals four weight units. The virtual size (vsize) discounts witness data such as signatures, so SegWit and Taproot transactions occupy fewer virtual bytes than their raw byte count and cost proportionally less to confirm. Quoting fees in sat/vB lets everyone compare transactions on the same per-space basis regardless of their internal structure — it is the common currency of the fee market.

Choosing a fee rate

The right rate is whatever the current mempool demands. During quiet periods, a rate near the network's relay floor clears in the next block or two; when the mempool is congested, only transactions above the prevailing market rate get mined promptly, and underpaid ones can wait hours or days. Fee estimators read the mempool's composition — how many virtual bytes are queued at each rate — to suggest a bid for a target confirmation window. Two things are worth internalizing: paying more buys faster inclusion, not greater finality (a 1 sat/vB transaction is exactly as settled as a 500 sat/vB one once each is buried under the same number of blocks), and a mistake is recoverable — Replace-By-Fee lets the sender re-bid, while CPFP lets the recipient pull a stuck payment through.

Why fee rates matter to miners

For miners, sat/vB is revenue density. Block construction is a knapsack problem: pack 4 million weight units with the transaction set that maximizes total fees, which is why mining software sorts the mempool by effective fee rate (including ancestor packages) rather than by total fee. Every fee spike is a direct bump to hashprice, and as each halving shrinks the subsidy, the share of the block reward carried by fees grows in importance. A node-running miner watching the mempool sort itself into fee bands during congestion is watching their future revenue being negotiated in real time.

Estimating size before you bid

Since total cost is rate times vsize, knowing your transaction's approximate size turns fee selection from guesswork into arithmetic. The controlling variable is input count: each input contributes its outpoint and signature, so a payment consolidating many small UTXOs can cost several times more than one spending a single coin, at the same fee rate. Modern input types are lean — native SegWit and Taproot inputs are meaningfully smaller in virtual bytes than legacy ones — which is a durable argument for receiving to modern address types. The practical corollary is timing: because size is fixed but rate floats, batch your heavy transactions (consolidations, channel opens, wallet migrations) into quiet mempool periods when the market rate is at the floor, and reserve congested periods for payments that genuinely cannot wait. A miner sitting on months of small pool payouts, in particular, should watch for those low-fee windows: sweeping dozens of inputs at the floor rate can cost a tenth of what the same cleanup costs during a spike.

Fee rate is denominated in the network's base unit, so it builds directly on the satoshi (unit), and paying a competitive rate is what earns a transaction its first confirmation sooner.

See current fees in live network vitals (mempool fees).