Sats per vByte (sat/vB)

What Is Sats per vByte?

Sats per vByte (abbreviated sat/vB or sats/vByte) is the unit used to measure Bitcoin transaction fee rates. It represents the number of satoshis a transaction pays for each virtual byte of data it occupies in a block. Since miners prioritize transactions with higher fee rates when assembling block templates, the sat/vB rate directly determines how quickly a transaction is likely to confirm.

This metric replaced the older "satoshis per byte" (sat/B) measurement after the SegWit upgrade activated in August 2017. SegWit introduced weight units and virtual bytes as a way to account for the witness discount, where signature data costs less block space than non-witness data. Using virtual bytes instead of raw bytes ensures that fee rate comparisons are fair across all transaction types: legacy, SegWit, and Taproot.

How It Works

Calculating a transaction's total fee from its sat/vB rate involves two values: the fee rate and the transaction's virtual size.

The Fee Formula

The calculation is straightforward:

Total Fee (satoshis) = Fee Rate (sat/vB) × Transaction Size (vBytes)

Example:
  Fee rate:          20 sat/vB
  Transaction size:  141 vB (typical native SegWit, 1 input, 2 outputs)
  Total fee:         20 × 141 = 2,820 satoshis

The amount being transferred has no effect on the fee. A transaction sending 0.001 BTC and one sending 100 BTC cost the same if they have identical virtual sizes. What determines virtual size is the number and type of inputs and outputs, not the value they carry.

From Bytes to Virtual Bytes

Virtual bytes are derived from a transaction's weight, which BIP 141 defines as:

Weight = (non-witness bytes × 4) + (witness bytes × 1)
vBytes = Weight ÷ 4  (rounded up)

Legacy transaction (no witness data):
  Total size: 226 bytes
  Weight:     226 × 4 = 904 WU
  vBytes:     904 ÷ 4 = 226 vB  (same as raw bytes)

Native SegWit transaction (P2WPKH, 1-in, 2-out):
  Non-witness: 82 bytes → 82 × 4 = 328 WU
  Witness:     109 bytes → 109 × 1 = 109 WU
  Weight:      328 + 109 = 437 WU
  vBytes:      437 ÷ 4 ≈ 110 vB

The witness discount means that signature data (stored in the witness section) contributes only one weight unit per byte instead of four. This is why SegWit and Taproot transactions have fewer virtual bytes than their raw byte count, making them cheaper at any given sat/vB rate.

Why vBytes Replaced Raw Bytes

Before SegWit, Bitcoin had a simple 1 MB block size limit. Every byte counted equally, so sat/byte was a sufficient metric. SegWit replaced the block size limit with a 4,000,000 weight unit limit (equivalent to roughly 1,000,000 virtual bytes). Because witness and non-witness data now carry different weights, raw byte counts no longer accurately reflect how much block space a transaction uses.

Virtual bytes normalize this difference into a single number. For legacy transactions, vBytes equal raw bytes exactly. For SegWit transactions, vBytes are smaller than raw bytes because witness data receives the discount. This ensures miners and wallets can compare fee rates across transaction types using a single, consistent metric.

Typical Fee Rate Ranges

Fee rates fluctuate based on mempool congestion. When demand for block space is low, transactions at 1 sat/vB confirm in the next block. During high-demand periods (such as ordinal minting waves or market volatility), rates can spike to hundreds of sat/vB.

As of mid-2026, the Bitcoin mempool has frequently sat at or near 1 sat/vB, with next-block confirmation available at 2 – 3 sat/vB. However, fee spikes remain common during periods of sudden demand, and historically, rates above 500 sat/vB have occurred during extreme congestion events.

Note that Bitcoin Core 29.1 (September 2025) reduced the default minimum relay fee from 1 sat/vB to 0.1 sat/vB, allowing lower-fee transactions to propagate across the network during quiet periods.

Fee Estimation

Wallets and applications use fee estimation services to recommend an appropriate sat/vB rate for the user's desired confirmation speed. The two primary approaches:

• Bitcoin Core's estimatesmartfee RPC: analyzes historical block data to predict the fee rate needed for confirmation within a target number of blocks. Supports ECONOMICAL and CONSERVATIVE modes. The node must have observed enough recent blocks to produce reliable estimates.
• Mempool-based APIs (such as mempool.space): inspect the current contents of the mempool to project what fee rate is needed for the next block. These are more responsive to sudden congestion changes but can be less stable when fees shift rapidly.

A typical mempool-based API returns recommended rates for several confirmation targets: next block (fastest), 30 minutes, 1 hour, and economy. The response looks like:

// mempool.space fee recommendation API
GET /api/v1/fees/recommended

{
  "fastestFee": 12,     // sat/vB for next-block confirmation
  "halfHourFee": 8,     // sat/vB for ~30 minute confirmation
  "hourFee": 4,         // sat/vB for ~1 hour confirmation
  "economyFee": 2,      // sat/vB for low-priority
  "minimumFee": 1       // sat/vB network minimum
}

For a deeper comparison of estimation algorithms and their accuracy tradeoffs, see the research article on Bitcoin fee estimation algorithm comparison.

Sats per Byte vs. Sats per vByte

The older sat/byte metric measured fees against raw transaction size in bytes. After SegWit, this metric became misleading because it did not account for the witness discount. A SegWit transaction paying 10 sat/byte and a legacy transaction paying 10 sat/byte do not consume the same amount of block space, so comparing them directly would be inaccurate.

For legacy transactions that contain no witness data, the two metrics produce identical results. The distinction only matters for SegWit and Taproot transactions, where virtual bytes are smaller than raw bytes due to the witness discount. All modern wallets, block explorers, and fee market tools now display rates in sat/vB.

Use Cases

Setting Transaction Priority

Users adjust their sat/vB rate to control how quickly their transaction confirms. A user sending a time-sensitive payment during congestion might set 50 sat/vB for next-block inclusion, while a non-urgent UTXO consolidation can wait at 1 sat/vB during quiet periods.

Fee Bumping

If a transaction is stuck because its sat/vB rate is too low for current conditions, users can increase the effective fee rate using Replace-by-Fee (RBF) or Child-Pays-for-Parent (CPFP). RBF replaces the original transaction with a new version that has a higher sat/vB rate. CPFP creates a child transaction with a high enough fee rate to raise the aggregate effective fee rate of the parent-child package above the threshold for mining. For a practical guide, see the research article on Bitcoin fee bumping with RBF and CPFP.

Wallet UX and Coin Selection

Wallets use the sat/vB metric to estimate total fees before a user confirms a transaction. The virtual size depends on the number of inputs selected, so coin selection algorithms try to minimize the input count (and thus the vByte count) to reduce fees. A wallet spending ten small UTXOs at 20 sat/vB pays significantly more than one spending a single UTXO of equivalent value.

Layer 2 Fee Awareness

Layer 2 protocols interact with on-chain fee rates at critical moments. Lightning channel opens and closes are on-chain transactions priced in sat/vB. Features like anchor outputs allow channel participants to fee-bump commitment transactions after broadcast, adapting to whatever sat/vB rate the mempool demands at closing time. Spark avoids these on-chain fee concerns for everyday transfers by operating off-chain, but users still encounter sat/vB rates when entering or exiting the protocol on-chain.

Risks and Considerations

Fee Overpayment

During fee spikes, wallets may recommend high sat/vB rates based on transient congestion. If conditions calm before the transaction confirms, the user may have overpaid. Using RBF-enabled transactions allows users to start with a lower rate and bump only if needed.

Stuck Transactions

Setting a sat/vB rate that is too low can result in a transaction that sits in the mempool for hours or days without confirming. If the rate falls below the minimum relay fee, some nodes may not even propagate the transaction. Transactions that remain unconfirmed long enough may be evicted from the mempool entirely through mempool eviction.

Estimation Inaccuracy

Fee estimation is inherently imperfect. Historical methods (like estimatesmartfee) can lag behind rapidly changing conditions. Mempool-based estimators can overreact to short-lived spikes. No estimator can predict future transaction arrivals, so there is always some risk of paying too much or too little. Wallets that support RBF mitigate this by allowing fee adjustments after broadcast.

UTXO Size and Dust

At high sat/vB rates, small UTXOs can become uneconomical to spend: the fee required to include them as inputs exceeds their value. These are sometimes called stranded UTXOs or dust. Consolidating UTXOs during low-fee periods helps avoid this problem.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.