Bitcoin Fee Estimation: How Wallets Predict What You'll Pay

Bitcoin fee estimation determines how much you pay to get a transaction confirmed. Every wallet that builds Bitcoin transactions must answer the same question: what fee rate (measured in sat/vB) will get this transaction into a block within a reasonable timeframe? The answer depends on the algorithm behind the estimate, and different wallets use fundamentally different approaches. That is why two wallets can suggest fee rates that differ by 5x or more for the same transaction at the same moment.

Understanding how these algorithms work helps you avoid two costly outcomes: overpaying for block space you did not need to compete for, or underpaying and watching your transaction sit unconfirmed for hours or days. This article surveys the major fee estimation approaches, explains why they diverge, and examines what happens when they get it wrong.

Why Fee Estimation Is Hard

Bitcoin's fee market is a continuous auction for limited block space. Each block can hold roughly 4 million weight units (about 1 MB of non-witness data plus discounted witness data). When demand exceeds supply, transactions compete on fee rate. Miners select the highest-paying transactions first, so during congestion the minimum fee rate for next-block inclusion can jump from 1 sat/vB to hundreds of sat/vB within minutes.

The difficulty lies in prediction. A fee estimator must forecast what the mempool will look like when the next block is found, which could be anywhere from 1 minute to over an hour from now. New transactions arrive continuously, other transactions get replaced via RBF, and miners may have different mempool policies. No estimator has perfect information, and each approach makes different tradeoffs between responsiveness and stability.

Bitcoin Core: The Confirmation-Based Estimator

Bitcoin Core's CBlockPolicyEstimator is the oldest and most widely referenced fee estimation algorithm. It takes a purely historical approach: rather than looking at the current mempool, it tracks how long transactions at various fee rates actually took to confirm in past blocks.

How the Bucket System Works

The estimator organizes fee rates into exponentially spaced buckets with a spacing factor of 1.05x. These buckets range from 1,000 sat/kvB (1 sat/vB) up to 10,000,000 sat/kvB (10,000 sat/vB). When a transaction enters the mempool, Bitcoin Core records which fee rate bucket it falls into. When that transaction later confirms in a block, the estimator notes how many blocks elapsed between entry and confirmation.

For each bucket, the estimator maintains counters tracking how many transactions confirmed within various block targets (1 block, 2 blocks, and so on up to 1,008 blocks). To prevent stale data from dominating, all counters are multiplied by a decay factor of 0.998 with each new block. This means data from blocks received hundreds of blocks ago contributes negligibly to current estimates.

The estimatesmartfee RPC

Applications query Bitcoin Core's fee estimator through the estimatesmartfee RPC call, which accepts two parameters: a confirmation target (1 to 1,008 blocks) and an estimate mode. The two modes represent meaningfully different strategies:

• CONSERVATIVE: uses a longer historical window and returns higher fee rate estimates, prioritizing confirmation reliability over cost savings. This mode is less responsive to short-term drops in the fee market.
• ECONOMICAL: uses a shorter time horizon, responds faster to recent fee market changes, and tends to return lower estimates. This mode accepts slightly more risk of slower confirmation in exchange for lower fees.

As of Bitcoin Core v28, the default mode switched from CONSERVATIVE to ECONOMICAL, reflecting the widespread availability of replace-by-fee as a safety net for transactions that undershoot.

Key limitation: Bitcoin Core's estimator is backward-looking. It cannot react to a sudden surge of new transactions entering the mempool because it only learns from confirmed blocks. If the fee market shifts rapidly (as it does during inscription waves or token launches), the estimator can lag behind reality by several blocks.

Mempool-Based Estimation: The Real-Time Approach

Services like mempool.space take the opposite approach: instead of looking at historical confirmation data, they analyze the current state of the mempool in real time. This method treats the mempool like an order book, examining exactly which transactions are waiting and at what fee rates.

Block Template Projection

The core technique involves constructing a projected block template from the current mempool. The estimator sorts all unconfirmed transactions by fee rate (accounting for CPFP relationships), then fills virtual blocks from highest to lowest fee rate. The fee rate at the boundary of each projected block tells you the minimum rate needed to be included in that block position.

mempool.space's API returns recommended fee rates for four preset confirmation targets: fastest (next block), half-hour (within 3 blocks), hour (within 6 blocks), and economy (within 12+ blocks). Because these projections are derived from the actual transactions sitting in the mempool right now, they respond instantly to demand changes.

Strengths and Weaknesses

The real-time approach excels during fee market transitions. When a wave of high-fee transactions suddenly enters the mempool, a mempool-based estimator sees them immediately and adjusts upward. Conversely, when a block is found and clears the top of the mempool, the estimate drops right away. Bitcoin Core's historical estimator would not reflect either change until several more blocks confirm.

The weakness is the opposite: mempool-based estimation has no memory. It cannot account for cyclical patterns (like fee rate drops during weekend hours) or predict how the mempool will evolve between now and the next block. If you are targeting confirmation 12 blocks out (roughly two hours), the current mempool snapshot may be a poor predictor of conditions two hours from now.

Blended Estimation: Combining Both Approaches

Recognizing that neither pure approach is ideal, some services blend historical and mempool-based signals. Strike published their blended fee estimation methodology, which uses different strategies depending on the use case: mempool-based estimates for time-sensitive on-chain transactions (where next-block inclusion matters), and history-based estimates from Bitcoin Core for operations like Lightning channel opens where the target is further in the future.

The open-source bitcoin-blended-fee-estimator library (originally from the Zap wallet project) implements a similar concept. It fetches estimates from multiple sources, applies configurable multipliers, and caches results with a 15-second TTL to avoid excessive API calls.

Emerging work: Bitcoin Core itself is moving toward blended estimation. A proposal by ismaelsadeeq introduces a ForecasterManager that registers multiple fee rate forecasters: the existing CBlockPolicyEstimator becomes one forecaster alongside a new MemPoolForecaster that reacts to unconfirmed transactions in real time.

Comparing Fee Estimation Approaches

Why Wallet Fee Estimates Diverge

When you compare fee suggestions across wallets, the differences can be striking. One wallet might suggest 5 sat/vB while another recommends 25 sat/vB for the same confirmation target. Several factors drive this divergence:

Different Algorithms

The most fundamental cause is that wallets use different estimation algorithms entirely. A wallet querying Bitcoin Core's estimatesmartfee with CONSERVATIVE mode will return a higher number than one using mempool.space's real-time projection, especially when fees are falling. The historical estimator remembers the higher fees from recent blocks; the mempool estimator sees that the queue has cleared.

Different Mempool Views

No two Bitcoin nodes have identical mempools. Transactions propagate through the peer-to-peer network with varying latency, and nodes apply different mempool policies (minimum relay fees, maximum mempool size, package acceptance rules). A wallet whose backend node has a 300 MB mempool limit will see a different transaction set than one with a 1 GB limit.

Safety Margins and Multipliers

Many wallets add a safety margin on top of their raw estimate. Custodial services and exchanges tend to apply aggressive multipliers (sometimes 1.5x to 2x) because a stuck withdrawal creates support tickets. Self-custody wallets aimed at technical users often apply smaller margins, trusting users to bump fees via RBF if needed.

Coin Selection Effects

Fee estimation is only half the equation. The wallet's coin selection algorithm determines which UTXOs become inputs, directly affecting the transaction's virtual size. A wallet that selects three inputs where one would suffice creates a larger transaction, and a larger transaction at the same fee rate costs more in absolute terms.

When Fee Estimation Fails

Fee estimation failures have real financial consequences. They fall into two categories: overpayment (wasted money) and underpayment (stuck transactions).

The Overpayment Problem

During the May 2023 BRC-20 minting frenzy, high-priority fee rates spiked above 600 sat/vB. Wallets using backward-looking estimators continued recommending elevated rates even after the surge subsided, because their historical window was still dominated by high-fee blocks. Users who trusted these inflated estimates overpaid by 2x to 10x compared to what mempool-aware tools suggested.

The problem recurred in April 2024 when the Runes protocol launched alongside Bitcoin's fourth halving. Average transaction fees hit $91 per transaction, a 2,645% increase from $3.35 one month earlier. Wallets with stale estimates were particularly vulnerable during the cooldown period: they kept suggesting panic-level fee rates long after the mempool had cleared.

Stuck Transactions

Underpayment is the mirror problem. A wallet that estimates too low produces unconfirmed transactions that can sit in the mempool for hours or days. This is especially problematic for wallets that do not support fee bumping via RBF or CPFP. Without a mechanism to increase the fee after broadcast, users are stuck waiting for the mempool to drain or for the transaction to be evicted.

Mempool-based estimators can underestimate during rapidly rising fee markets. If a wave of high-fee transactions arrives between the time you broadcast and the next block, your transaction may have been competitive when sent but is no longer competitive when a miner builds the block template.

Fee Estimation Across Different Scenarios

The right estimation strategy depends on the transaction's urgency and the sender's ability to bump fees after broadcast.

The Role of RBF and CPFP as Safety Nets

Fee estimation does not need to be perfect if users have tools to correct mistakes after broadcast. Replace-by-fee lets the sender rebroadcast the same transaction with a higher fee rate, effectively updating their bid in the block space auction. Child-pays-for-parent lets the recipient (or sender) create a high-fee child transaction that incentivizes miners to confirm the parent alongside it.

The availability of full RBF across the network since Bitcoin Core v25 fundamentally changes the fee estimation calculus. When every transaction is replaceable, the optimal strategy shifts: start with a lower estimate and bump only if confirmation is taking too long. This is why Bitcoin Core switched its default from CONSERVATIVE to ECONOMICAL mode. Overpaying is waste; underpaying is correctable.

Fee Market Conditions: Calm vs. Chaos

The accuracy gap between estimation approaches varies dramatically depending on fee market conditions.

During calm periods (common throughout much of 2025 and into 2026), median fee rates have hovered between 1 and 20 sat/vB. At these levels, the choice of algorithm matters less because even a 3x overestimate translates to a few hundred extra satoshis on a typical transaction. All estimators tend to converge when the mempool is nearly empty.

During congestion events, the differences become dramatic. The mempool congestion driven by BRC-20 minting in May 2023 saw fee rates exceed 600 sat/vB. The Runes launch in April 2024 pushed average fees above $90. During these events, a wallet using a mempool-based estimator adapts within seconds, while a confirmation-based estimator may take 30+ blocks to reflect the new reality.

Cluster Mempool and the Future of Fee Estimation

Bitcoin Core's ongoing cluster mempool project will reshape fee estimation by changing how the mempool itself is organized. Under cluster mempool, transactions are grouped into clusters based on their dependency relationships, and each cluster is linearized into an optimal ordering for block inclusion.

This matters for fee estimation because it makes block template construction more predictable. Today, the mempool's CPFP handling can produce edge cases where the effective fee rate of a transaction group is difficult to compute. With cluster mempool, the fee rate diagram of the mempool becomes a clean, monotonically decreasing function, making mempool-based estimation more reliable.

Combined with the ForecasterManager proposal that adds a native mempool-aware forecaster alongside the existing historical estimator, Bitcoin Core is converging toward a blended approach that should narrow the accuracy gap between different wallet implementations.

Avoiding the Fee Market Entirely

All fee estimation approaches share the same fundamental limitation: they are trying to predict a volatile, adversarial auction. No matter how sophisticated the algorithm, users transacting on Bitcoin L1 are subject to fee market dynamics that can change within a single block interval.

Off-chain protocols sidestep this problem entirely. Spark, for example, settles transfers off-chain with predictable costs that do not fluctuate with mempool congestion. Users still interact with Bitcoin L1 when depositing or withdrawing, but day-to-day transfers between Spark balances avoid the fee market altogether. For applications where cost predictability matters (payroll, recurring payments, micropayments), moving value off-chain eliminates the need for fee estimation and the risk of getting it wrong.

If you want to experience predictable Bitcoin transaction costs without worrying about mempool dynamics, wallets like General Bread are built on Spark and offer fixed-cost transfers regardless of L1 congestion. For developers building on Bitcoin, the Spark SDK documentation covers integration patterns for off-chain payments. You can also explore how Bitcoin's fee market dynamics affect different transaction types in our deep dive on the topic.

This article is for educational purposes only. It does not constitute financial or investment advice. Bitcoin and Layer 2 protocols involve technical and financial risk. Always do your own research and understand the tradeoffs before using any protocol.