Fee Estimation

What Is Fee Estimation?

Fee estimation is the process of predicting the minimum transaction fee rate needed for a Bitcoin transaction to be included in a block within a desired timeframe. Because Bitcoin blocks have a fixed capacity of 4,000,000 weight units (roughly 1,000,000 virtual bytes), transactions compete for space by offering higher fees. Miners prioritize transactions with the highest fee rates, so wallets must estimate what fee rate will be competitive enough for timely confirmation.

The challenge is fundamentally a prediction problem: the wallet must guess what the fee market will look like when the next blocks are mined, not just what it looks like right now. New transactions constantly enter the mempool, demand fluctuates unpredictably, and blocks arrive at irregular intervals. A fee rate that guarantees next-block confirmation during a quiet weekend might leave a transaction stranded for hours during a congestion spike.

How It Works

Fee estimation algorithms fall into three broad categories, each with different strengths depending on the confirmation target.

Mempool-Based Estimation

Mempool-based estimators analyze the current pool of unconfirmed transactions in real time. They project which transactions would fit into the next several blocks based on their fee rates and sizes, then determine the minimum fee rate needed to land within a target confirmation window. A small buffer is typically added to account for new transactions that arrive before the block is mined.

This approach excels at short-term predictions (1 to 6 blocks) because it reflects current demand directly. Its weakness is that the mempool differs across nodes: each node sees a slightly different set of pending transactions, and no node can predict future demand surges.

Historical Confirmation Tracking

Bitcoin Core's built-in estimator (CBlockPolicyEstimator) takes a historical approach. It tracks how long transactions at various fee rate levels actually took to confirm, grouping them into fee rate buckets and using exponentially decaying moving averages to weight recent data more heavily.

The estimator uses three time horizons, each with a different decay rate:

• Short history (decay 0.962, half-life of 18 blocks): used for targets up to 12 blocks
• Medium history (decay 0.9952, half-life of 144 blocks): used for targets up to 48 blocks
• Long history (decay 0.99931, half-life of 1,008 blocks): used for targets up to 1,008 blocks

For each target, the estimator checks multiple confidence thresholds: 60% confirmation probability at half the target, 85% at the target itself, and 95% at double the target. It returns the maximum fee rate across all applicable thresholds.

# Bitcoin Core RPC: estimate fee for confirmation within 6 blocks
bitcoin-cli estimatesmartfee 6 "economical"

# Response:
# {
#   "feerate": 0.00012500,   // BTC/kvB
#   "blocks": 6
# }

# Convert to sat/vB: 0.00012500 * 100000000 / 1000 = 12.5 sat/vB

Bitcoin Core offers two modes: "conservative" (uses longer history, higher fees, more reliable) and "economical" (uses shorter history, lower fees, assumes Replace-by-Fee is available). As of Bitcoin Core v30, the default was changed from conservative to economical, reflecting the philosophy of starting low and bumping fees if needed.

Blended Approaches

Modern fee estimators increasingly combine mempool analysis with historical data. For near-term targets, mempool-based estimates respond faster to current conditions. For longer-term targets, historical data provides a more stable baseline. Block's Augur library, open-sourced in 2025 and used in production at Cash App, takes this approach by analyzing current mempool composition, transaction inflow rates, and block production probability. It provides confidence-based estimates at 50% (optimistic), 80% (balanced), and 95% (conservative) levels.

Transaction Size and Fee Calculation

The total fee for a transaction is the product of its size in virtual bytes and the chosen fee rate:

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

// Example transaction sizes (1 input, 2 outputs, single-sig):
// Legacy P2PKH:         ~226 vB
// Native SegWit P2WPKH: ~141 vB
// Taproot P2TR:         ~154 vB

// A P2WPKH transaction at 10 sat/vB:
// 141 vB × 10 sat/vB = 1,410 sats (~$1.50 at $100k BTC)

Using SegWit or Taproot address formats reduces the virtual size of a transaction compared to legacy formats, directly lowering fees regardless of the fee rate.

Fee Estimation Tools and APIs

Several services provide fee estimation through public APIs, each using different methodologies:

Wallets typically use one or more of these APIs to present users with preset fee tiers such as "fast," "medium," and "economy." Some wallets allow manual fee entry for advanced users, while others lock users into automatic estimates. For a deeper look at how fees interact with block space demand, see the research article on Bitcoin fee market dynamics.

Why It Matters

Fee estimation directly affects both cost and user experience. During quiet periods, fees can drop to 1 sat/vB (the minimum relay fee), making transactions nearly free. During congestion events like the April 2024 halving, average fees spiked above $90. A wallet with poor fee estimation might overpay by 10x during calm periods or underpay and leave transactions stuck for hours during spikes.

For applications building on Bitcoin, fee estimation quality determines operational costs. Exchanges processing thousands of withdrawals daily can save significant amounts by using accurate estimation combined with Replace-by-Fee for fee bumping. Payment processors need reliable confirmation within expected timeframes to maintain service quality.

Layer 2 solutions like Spark reduce reliance on fee estimation by moving most transactions off-chain. On Spark, transfers settle instantly without competing for block space, making on-chain fee volatility irrelevant for day-to-day payments.

Fee Bumping: When Estimation Falls Short

Because fee estimation is inherently imperfect, Bitcoin provides mechanisms to adjust fees after a transaction has been broadcast:

• Replace-by-Fee (RBF): the sender broadcasts a replacement transaction with a higher fee rate. As of Bitcoin Core v28, full RBF is enabled by default, meaning any unconfirmed transaction can be replaced regardless of signaling.
• Child-Pays-for-Parent (CPFP): the recipient creates a high-fee child transaction spending an output of the stuck parent. Miners evaluate the parent and child as a package, finding the combined fee rate attractive enough to include both.

These mechanisms make "economical" fee estimation practical: wallets can start with a lower fee and bump it only if confirmation takes too long, rather than always overpaying as insurance.

Lightning Network: Deterministic Fees

Fee estimation is primarily an on-chain concern. On the Lightning Network, routing fees follow a completely different model: each node advertises a fixed base fee (in millisatoshis) plus a proportional fee rate (in parts per million). The sender's wallet calculates the exact total cost before dispatching the payment:

Routing Fee = Base Fee + (Payment Amount × Fee Rate / 1,000,000)

// Example: sending 50,000 sats through a node charging
// 0 msat base fee + 100 ppm fee rate:
// Fee = 0 + (50,000 × 100 / 1,000,000) = 5 sats

Lightning fees are typically 100x to 10,000x cheaper than on-chain fees and are known exactly before the payment is sent. There is no probabilistic guessing, no competition for block space, and no risk of overpaying. The scarce resource on Lightning is channel liquidity rather than block space, which is why liquidity management matters more than fee estimation for Lightning node operators.

Risks and Considerations

Overpayment During Quiet Periods

Conservative fee estimators often suggest rates far higher than necessary when the mempool is nearly empty. A wallet suggesting 10 sat/vB when 1 sat/vB would confirm in the next block wastes user funds. This is especially costly for UTXO consolidation and batch transactions where even small per-transaction overpayments add up.

Underpayment During Congestion

Mempool-based estimators can underestimate fees if a sudden surge of high-fee transactions arrives after the estimate is generated but before the next block is mined. Transactions paying below the new competitive threshold may wait many blocks or require fee bumping via RBF.

Mempool Divergence

Each Bitcoin node maintains its own mempool, and not all nodes see the same set of unconfirmed transactions at the same time. An estimator based on one node's mempool view may not reflect what miners actually see. This is particularly relevant during rapid fee market shifts, when transaction propagation delays can cause meaningful differences between node mempools.

Fee Sniping Risk

Fee sniping is a theoretical attack where miners re-mine previous blocks to capture high-fee transactions. While not directly a fee estimation issue, extremely high fee rates during congestion events increase the incentive for this behavior. Wallets mitigate this by setting the nLockTime field to the current block height.

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.