Fee Estimation Algorithm

What Is a Fee Estimation Algorithm?

A fee estimation algorithm is a method used by Bitcoin wallets and nodes to predict how much a user should pay in transaction fees to get a transaction confirmed within a desired timeframe. Since Bitcoin blocks have limited space, miners prioritize transactions offering higher fees per unit of block weight. The algorithm's job is to suggest a fee rate, measured in satoshis per virtual byte, that is high enough to achieve timely confirmation without dramatically overpaying.

Fee estimation is necessary because the Bitcoin fee market is a continuous auction. Demand for block space fluctuates constantly: during quiet periods a 1 sat/vB transaction might confirm in the next block, while during congestion even 50 sat/vB may not be enough. Without estimation, users would have to manually guess an appropriate fee, risking either overpayment or stuck transactions.

How It Works

Fee estimation algorithms fall into two broad families: historical (confirmation-based) estimators and mempool-based (queue-based) estimators. Many wallets and services combine elements of both.

Historical Estimation: Bitcoin Core's CBlockPolicyEstimator

Bitcoin Core's built-in estimator, CBlockPolicyEstimator, is the most widely deployed historical fee estimator. Rather than examining the current mempool, it tracks how long transactions at various fee rates have historically taken to confirm. The algorithm works as follows:

1. When a transaction enters the node's mempool, the estimator records its fee rate bucket and the current block height
2. Fee rates are sorted into exponentially spaced buckets with roughly 5% spacing (a factor of approximately 1.05), ranging from 1 sat/kB to 10,000,000 sat/kB
3. When a transaction confirms, the estimator records how many blocks elapsed between entry and confirmation
4. These confirmation counts are aggregated using exponentially weighted moving averages, so recent data carries more weight than older observations
5. When asked for an estimate, the algorithm walks from the highest bucket downward and returns the lowest fee rate bucket whose historical success ratio meets a confidence threshold

Three Estimation Horizons

CBlockPolicyEstimator maintains three separate time horizons, each with its own decay rate:

This multi-horizon approach lets the estimator balance responsiveness to recent conditions against the stability that comes from longer observation windows.

Conservative vs. Economical Mode

Bitcoin Core's estimatesmartfee RPC offers two modes:

• Economical (the default since Bitcoin Core v28.0): uses only the shortest applicable horizon and requires an 85% success threshold, producing lower fee suggestions
• Conservative: requires confidence across all longer horizons as well, using a 95% success threshold applied at twice the requested target, which guards against sudden fee increases but tends to overpay

# Request a fee estimate for confirmation within 6 blocks
bitcoin-cli estimatesmartfee 6

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

# Request a conservative estimate
bitcoin-cli estimatesmartfee 6 "conservative"

One important limitation: the estimator requires the node to have been running and observing transactions for at least twice the requested confirmation target in blocks before it can return an estimate.

Mempool-Based Estimation

Mempool-based estimators take a fundamentally different approach. Instead of looking at historical confirmations, they examine the current queue of unconfirmed transactions in the mempool and simulate what a miner would include in upcoming blocks.

The most widely used mempool-based estimator is mempool.space, which re-implements Bitcoin Core's transaction selection algorithm against the live mempool. It rebuilds projected blocks approximately every two seconds and returns fee rates for multiple confirmation tiers:

// mempool.space fee estimate response
{
  "fastestFee": 12,    // sat/vB - next block
  "halfHourFee": 8,    // ~3 blocks
  "hourFee": 5,        // ~6 blocks
  "economyFee": 2,     // no rush
  "minimumFee": 1      // mempool minimum
}

Mempool-based estimators react much faster to changing conditions. When a large batch of high-fee transactions suddenly enters the mempool, a mempool-based estimator immediately adjusts its recommendations upward. A historical estimator, by contrast, would not reflect the change until those transactions start confirming (or failing to confirm at lower fee rates).

Blended Approaches

Some wallets and services combine both methods. The LN-Zap bitcoin-blended-fee-estimator project, for example, uses mempool.space data for near-term targets (next few blocks) where real-time accuracy matters most, and falls back to Bitcoin Core's historical estimator for longer confirmation horizons where the mempool's current state is less predictive.

Why Estimation Is Hard

Fee estimation is an inherently difficult prediction problem for several reasons:

• The mempool is not global: each node sees a slightly different set of unconfirmed transactions depending on its peers, relay policies, and mempool policy settings
• Fee spikes are sudden and unpredictable: a popular NFT mint, an exchange consolidation, or a protocol event can flood the mempool with high-fee transactions in seconds
• Block times vary: while Bitcoin targets one block every 10 minutes, actual intervals can range from seconds to over an hour due to the probabilistic nature of mining
• Miners may not follow default selection rules: out-of-band fee payments, transaction acceleration services, and custom block templates can all deviate from the standard greedy algorithm
• Other users' fee-bumping behavior is unknown: transactions using RBF or CPFP can change the competitive landscape after you broadcast

For a deeper analysis of how these dynamics play out, see the research article on Bitcoin fee market dynamics.

Use Cases

Wallet Fee Selection

The most common use case is helping users choose an appropriate fee when sending Bitcoin. Most wallets present two or three tiers (fast, medium, economy) derived from a fee estimation algorithm. The coin selection algorithm then uses the chosen fee rate to construct the transaction.

Lightning Channel Management

Lightning Network nodes rely heavily on fee estimation for on-chain operations: opening channels, closing channels (especially force closes where timelocks create urgency), and posting anchor output fee bumps. Poor fee estimation can leave a channel close unconfirmed during a critical timelock window.

Exchange and Payment Processing

Exchanges processing thousands of withdrawals use fee estimation to balance user experience against cost. Many use transaction batching combined with conservative fee estimates and then bump fees via RBF if confirmation takes too long.

Layer 2 Protocols

Layer 2 systems like Spark benefit from advancements in fee estimation because they reduce users' exposure to on-chain fee volatility entirely. By moving transactions off-chain, users avoid the fee estimation problem for routine payments while still relying on accurate estimates for the less frequent on-chain anchoring transactions. For a comparison of different fee estimation approaches, see the research article on Bitcoin fee estimation algorithm comparison.

RBF as a Fee Estimation Safety Net

Because no estimation algorithm can perfectly predict fees, Replace-by-Fee (RBF) serves as a crucial fallback mechanism. Rather than trying to guess the perfect fee upfront, users can adopt a "start low, bump if needed" strategy:

1. Broadcast the transaction with an economical fee estimate and the RBF signal enabled
2. Monitor confirmation progress
3. If the transaction is not confirming within the desired timeframe, use fee bumping to replace it with a higher-fee version

Bitcoin Core's bumpfee RPC automates this process. The replacement transaction must pay at least 1 sat/vB more than the original fee rate to satisfy relay rules. When the original transaction's change output is insufficient to cover the bump, newer Bitcoin Core versions can add inputs automatically.

When RBF is not available (for instance, if the original transaction did not signal replaceability), Child-Pays-for-Parent (CPFP) offers an alternative: the recipient creates a high-fee child transaction that spends an output of the stuck parent, incentivizing miners to confirm both together. For a practical guide to both techniques, see Bitcoin fee bumping: RBF and CPFP guide.

Risks and Considerations

Overpayment

Conservative fee estimates protect against stuck transactions but can lead to significant overpayment, especially during quiet fee periods. Over thousands of transactions, even small overestimates add up. This is particularly costly for high-volume senders like exchanges.

Stuck Transactions

Underestimation leaves transactions unconfirmed, potentially for hours or days during congestion events. While RBF and CPFP provide remedies, they add complexity and cost. Transactions that fall below the minimum relay fee may be dropped from mempools entirely via mempool eviction.

Cold Start Problem

Historical estimators like Bitcoin Core's require a warm-up period: the node must observe enough transactions confirming at various fee rates before it can produce reliable estimates. A freshly started node returns no estimates until it has seen at least twice the target number of blocks. This makes historical estimation impractical for lightweight or mobile clients, which typically rely on external fee estimation APIs instead.

Manipulation

Fee estimators can theoretically be manipulated. An attacker could flood the mempool with high-fee transactions to inflate mempool-based estimates, or broadcast and then replace transactions to skew historical data. Bitcoin Core's use of exponential decay and multiple horizons provides some resistance to manipulation, but no estimator is immune.

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.