Bandwidth-Based Fee

What Is a Bandwidth-Based Fee?

A bandwidth-based fee is a transaction pricing model where the cost depends on the amount of data (measured in bytes or virtual bytes) that a transaction adds to a shared resource, rather than on the value being transferred or the computational work required. In Bitcoin, every transaction competes for limited block space, and miners rank transactions by their fee rate: the number of satoshis paid per virtual byte (sat/vB).

This model means a transaction sending 0.001 BTC costs the same as one sending 1,000 BTC, provided both consume the same number of virtual bytes. The fee is a function of data footprint, not economic value. This stands in contrast to percentage-based pricing common in traditional payment networks and to computation-based pricing used by Ethereum's gas fee model.

How It Works

Bitcoin's fee calculation follows a simple formula:

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

A typical native SegWit (P2WPKH) transaction with one input and two outputs is roughly 140 vBytes. At a fee rate of 10 sat/vB, that transaction costs 1,400 satoshis (approximately $1.40 at $100,000/BTC). Miners select transactions by fee rate rather than total fee because they want to maximize revenue per unit of block space consumed.

Weight Units and Virtual Bytes

Before SegWit, transaction size was measured in raw bytes and blocks were capped at 1 MB. SegWit (activated August 2017) replaced the raw byte limit with a weight unit system that differentiates between two types of transaction data:

• Non-witness data (inputs, outputs, transaction metadata): 4 weight units per byte
• Witness data (signatures, public keys): 1 weight unit per byte

The block limit became 4,000,000 weight units, which translates to approximately 1,000,000 virtual bytes. Virtual bytes are calculated by dividing weight by 4:

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

This witness discount means that signature data, which does not need to be stored permanently by all nodes after validation, costs 75% less than the rest of the transaction. The discount incentivized SegWit adoption without requiring a hard fork.

Transaction Size by Address Type

Different address formats produce different transaction sizes for the same operation. For a standard single-input, two-output transaction:

Upgrading from legacy to Taproot addresses reduces the per-input cost by over 60%, directly lowering fees. For multisig wallets, the savings are even more dramatic: MuSig2 key aggregation makes a Taproot multisig spend indistinguishable from (and the same size as) a single-signature spend.

Fee Estimation

Fee estimation algorithms analyze the mempool to recommend an appropriate fee rate. Bitcoin Core groups historical transactions into fee rate buckets and tracks how quickly transactions in each bucket confirm. For a given target (e.g., confirmation within 2 blocks), the algorithm finds the lowest fee rate at which at least 95% of past transactions confirmed within that window.

Third-party estimators like mempool.space offer real-time projections based on current mempool state. Most wallets present simplified tiers: fast (next block), medium (within a few blocks), and slow (within an hour or more).

Bitcoin vs. Ethereum: Bandwidth vs. Computation

The contrast between Bitcoin and Ethereum illustrates two fundamentally different approaches to transaction pricing:

In Ethereum, an ERC-20 token transfer costs 45,000 to 65,000 gas and a Uniswap swap costs 150,000 to 185,000 gas, even though both produce similar amounts of on-chain data. The difference reflects computational complexity. In Bitcoin, fees scale purely with data footprint: a transaction with a larger script costs more because it takes up more block space, not because the script is more computationally intensive.

Use Cases

Transaction Batching

Because fees are bandwidth-based, sending ten individual transactions is far more expensive than one batched transaction with ten outputs. Each individual transaction carries fixed overhead (version, locktime, SegWit marker, input data), while batching amortizes that overhead across all recipients. Ten individual native SegWit payments total roughly 1,400 vBytes, whereas one batched payment to ten recipients is approximately 420 vBytes: a 70% reduction. Exchanges and payment processors batch withdrawals to significantly reduce their on-chain fee burden.

UTXO Consolidation

UTXO consolidation combines many small UTXOs into fewer larger ones during periods of low fee rates. Since each input adds 57 to 148 vBytes depending on address type, a transaction with 50 inputs during high congestion could cost more in fees than some of the UTXOs are worth. Consolidating when fees drop to 1 to 5 sat/vB prepares wallets for future spending at a fraction of the cost. This is especially important for preventing dust accumulation.

Address Format Selection

Choosing modern address formats is a direct fee optimization. Migrating from legacy P2PKH to native SegWit P2WPKH reduces input size from 148 to 68 vBytes: a 54% reduction. Taproot P2TR further shrinks inputs to 57 vBytes. For applications processing many transactions, this difference compounds into significant savings over time.

Fee Bumping

When transactions are stuck in a congested mempool, bandwidth-based fees interact with two fee bumping mechanisms: Replace-By-Fee (RBF) replaces the original transaction with a higher-fee version, while Child-Pays-For-Parent (CPFP) creates a child transaction that raises the effective fee rate of the entire package. Both strategies require understanding the bandwidth cost of the additional or replacement data. See the fee bumping guide for a detailed comparison.

Why It Matters

Bitcoin's bandwidth-based fee model has several important implications for users, developers, and the network as a whole:

• Value neutrality: a $10 payment and a $10 million payment cost the same if they consume the same block space, making Bitcoin attractive for high-value settlement
• Predictable optimization: since fees depend on data size, developers can calculate exact costs at design time and choose address formats, signature schemes, and transaction structures accordingly
• Incentive alignment: the fee market naturally prices block space as a scarce resource, encouraging efficient use through batching, consolidation, and modern address formats
• Layer 2 motivation: high on-chain fees during congestion make off-chain solutions like the Lightning Network and Spark economically compelling, since they amortize on-chain costs across many off-chain transactions

For a deeper analysis of how fee dynamics shape block space demand, see the research article on Bitcoin fee market dynamics.

Recent Developments

Minimum Relay Fee Reduction

Bitcoin Core 29.1 (September 2025) lowered the default minimum relay fee from 1 sat/vB to 0.1 sat/vB: a 90% reduction. This policy change (not a consensus rule) reflects the fact that Bitcoin's rising price means a lower BTC-denominated threshold still provides adequate DoS protection.

Cluster Mempool

Cluster mempool, merged in November 2025 and expected to ship with Bitcoin Core 31.0, replaces the legacy ancestor-feerate transaction sorting with a cluster-based framework. Related unconfirmed transactions are grouped into clusters (capped at 64 transactions), enabling more accurate fee rate evaluation and better block template construction. The change is estimated to recover 2% to 5% of previously missed miner revenue through improved transaction ordering.

Package Relay

Package relay allows nodes to evaluate groups of related transactions by their aggregate fee rate rather than individually. This solves a critical problem for CPFP fee bumping: previously, a low-fee parent transaction could be rejected by the mempool before its high-fee child could reference it. With package relay, a parent can even have a fee rate below the minimum relay fee as long as the parent-child package meets the threshold.

Risks and Considerations

Fee Volatility

Because the fee market is a pure auction, fee rates can spike dramatically during periods of high demand. Events like new token protocol launches, exchange outflows during market volatility, or inscription waves have historically pushed fee rates above 500 sat/vB. Users who do not monitor mempool conditions may overpay, while those who set fees too low may wait hours or days for confirmation.

Dust Economics

Bandwidth-based fees create a floor below which UTXOs become uneconomical to spend. If the fee to include an input exceeds the input's value, that UTXO is effectively dust. At 100 sat/vB, a legacy P2PKH input costs roughly 14,800 satoshis just in fees. Any UTXO smaller than that becomes stranded until fee rates drop. This dynamic makes UTXO management a practical necessity for frequent users.

Privacy Tradeoffs

Fee optimization techniques like batching and consolidation can compromise privacy. Batching reveals that all inputs belong to the same entity, and all recipients in a batch can observe each other's output amounts. Consolidation links multiple addresses to a single owner. Users must weigh cost savings against the privacy implications of these bandwidth-efficient strategies.

Estimation Uncertainty

Fee estimation algorithms extrapolate from historical data and current mempool state, but cannot predict sudden demand spikes. A fee rate that would have confirmed in the next block five minutes ago may now be stuck behind a wave of higher-paying transactions. Time-sensitive applications (such as Lightning force-close transactions) must account for this uncertainty by using generous fee rates or relying on fee bumping mechanisms.

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.