Bitcoin Fee Prediction Services Compared

Bitcoin Fee Estimation Services Overview

Bitcoin fee estimation determines how much you pay to get a transaction confirmed within a target number of blocks. The difference between a good estimator and a bad one can mean paying 2x to 10x more than necessary, especially during volatile fee market conditions. Every wallet, exchange, and payment service depends on some form of fee prediction, yet the methodologies vary significantly across providers.

Fee estimators fall into two broad categories: mempool-based estimators that analyze the current pool of unconfirmed transactions in real time, and historical estimators that use past confirmation data to project future fee rates. Each approach has distinct tradeoffs in accuracy, responsiveness, and reliability.

How Mempool-Based Estimation Works

Mempool-based estimators examine the current state of the mempool to project which transactions miners will include in upcoming blocks. The algorithm sorts all pending transactions by fee rate (sat/vB), accounting for CPFP relationships, then simulates block construction: the highest-fee transactions fill the first projected block, the next tier fills the second, and so on. Your transaction needs a fee rate high enough to land in a projected block within your desired confirmation window.

mempool.space is the most widely used mempool-based estimator. It re-implements Bitcoin Core's transaction selection algorithm against the live mempool, constructing projected blocks every ~2 seconds using a Rust-based block template engine. Its API returns five fee tiers: fastestFee (median of projected block 0), halfHourFee (average of block 0 and block 1 medians), hourFee (average of halfHourFee and block 2 median), economyFee (low priority), and minimumFee (relay minimum).

Block's Augur library takes a different mempool-based approach: rather than projecting specific blocks, it builds probability distributions by modeling mempool weight by fee rate, transaction inflow rates, and block production probability. This lets users select a confidence level (50%, 80%, or 95%) rather than accepting a single point estimate. Augur powers fee estimation for Cash App's Bitcoin withdrawals and is available as an open-source library.

The primary advantage of mempool-based estimation is responsiveness. When a large batch of high-fee transactions floods the mempool, a mempool-based estimator reflects the new competitive reality immediately. When the mempool clears after a series of fast blocks, it drops its estimates just as quickly. The weakness is susceptibility to brief spikes that resolve before the next block is mined.

How Historical Estimation Works

Bitcoin Core's estimatesmartfee RPC takes the opposite approach. Rather than examining the mempool, it tracks the actual confirmation times of past transactions across exponentially spaced fee rate buckets. When a transaction confirms, the system records how many blocks it waited. Over time, this builds a statistical model: for each fee rate bucket and confirmation target, what fraction of transactions achieved confirmation?

The algorithm uses exponential decay to weight recent data more heavily, and it operates across three time horizons with different half-lives: short (~18 blocks, targets up to 12 blocks), medium (~144 blocks, targets up to 48), and long (~1,008 blocks, targets up to 1,008). It supports two modes: economical (the default since Bitcoin Core v28.0), which uses only the shortest applicable time horizon, and conservative, which requires confidence across all longer horizons.

Blockstream Esplora's fee estimation API proxies Bitcoin Core's estimatesmartfee under the hood. While Esplora presents a convenient REST API with sat/vB responses for multiple block targets, its estimates inherit the same historical methodology and conservative tendencies as Bitcoin Core. Strike's blended fee estimator explicitly uses mempool.space for 1 to 6 block targets and Esplora only for longer horizons, reflecting this limitation.

A critical limitation: estimatesmartfee requires observation time after node startup before it can produce estimates. The node must observe at least 2x the requested target in blocks before returning a valid estimate. The algorithm is also intentionally conservative: it would rather overestimate (causing overpayment) than underestimate (causing a stuck transaction).

API Comparison

Developers integrating fee estimation into wallets, exchanges, or payment services need to evaluate API availability, response format, and rate limits. The following table compares the technical details of each service's API.

mempool.space also provides a /api/v1/fees/mempool-blocks endpoint that returns projected mempool blocks with fee ranges at each percentile, giving developers granular visibility into block space competition. WebSocket support at wss://mempool.space/api/v1/ws enables real-time streaming without polling.

Accuracy Benchmarks

Fee estimation accuracy is measured along two axes: miss rate (how often the estimate is too low, causing delayed confirmation) and overpayment (how much extra the user pays above the minimum sufficient fee). Most estimators prioritize low miss rates, which is why overpayment is the more common problem.

Block published the most comprehensive public benchmarks alongside the Augur library release. The following data compares next-block estimation accuracy during May 2025:

*Blockstream data is from April 2024 halving-period volatility, not the May 2025 period. During that event, Blockstream recommended fees equivalent to ~$50 when ~$15 would have sufficed.

A separate analysis on Delving Bitcoin examined Bitcoin Core's modes across 7,822 estimates over 435 blocks. Conservative mode overpaid in 96.14% of estimates, with a worst case of 13x overpayment (505.7 sat/vB estimated vs. 38.7 sat/vB actual median). Economical mode overpaid in 77.55% of estimates but with much smaller margins, reflecting the change that led Bitcoin Core v28.0 to switch the default to economical.

For a deeper analysis of how fees respond to network congestion, see our research on Bitcoin mempool congestion economics. To explore historical fee patterns, use the Bitcoin fee rate history tool.

Choosing an Estimation Strategy

The right fee estimation approach depends on your use case and risk tolerance:

• Wallets serving end users should prefer mempool-based estimators (mempool.space or Augur) for better cost efficiency, with Replace-by-Fee (RBF) enabled as a safety net for underestimates.
• Exchanges processing withdrawals often use Bitcoin Core's conservative mode or BitGo because stuck transactions create support tickets. Overpayment is an acceptable cost.
• High-volume services should combine mempool-based estimation with transaction batching, which reduces per-payment costs by 40% to 80% regardless of the fee rate chosen.
• A blended approach (mempool-based for 1 to 6 block targets, historical for longer horizons) offers the best of both worlds. Strike's open-source blended estimator implements this pattern.
• Self-hosting mempool.space eliminates rate limits and dependency on third-party uptime, but requires running a full Bitcoin node.
• For time-sensitive payments, pair a next-block mempool-based estimate with RBF opt-in. If the fee market shifts before confirmation, bump the fee using CPFP or RBF rather than overpaying upfront.

For practical strategies on reducing transaction costs, see our Bitcoin fee optimization strategies guide and the fee estimator tool.

Avoiding On-Chain Fees Entirely

Fee estimation matters because on-chain transaction fees are inherently unpredictable. During normal conditions, a standard transaction (1 input, 2 outputs, ~140 vBytes) might cost 700 sats at 5 sat/vB. During peak demand, the same transaction can cost 70,000 sats or more at 500 sat/vB. This volatility makes fee estimation a constant source of friction for users and developers.

Layer 2 protocols sidestep this problem. The Lightning Network moves payments off-chain, replacing the per-transaction fee auction with routing fees that typically total fractions of a cent: a median base fee of ~0.4 sats plus a proportional rate of ~143 ppm (0.014%). A 100,000 sat payment routed through three hops costs roughly 26 sats. Spark takes this further by enabling Bitcoin and stablecoin transfers with near-zero fees and instant settlement, completely bypassing the on-chain fee market. For applications where fee predictability matters (payments, commerce, remittances), Layer 2 solutions eliminate the need for fee estimation altogether.

For a comparison of Bitcoin's fee structure with other networks, see the chain fee comparison tool. For more on how fee market dynamics affect transaction costs, see our research coverage.

Frequently Asked Questions

Which Bitcoin fee estimator is the most accurate?

Mempool-based estimators like mempool.space and Block's Augur generally provide the best balance of confirmation reliability and cost efficiency. In published benchmarks, Augur achieved a 14.1% miss rate with only 15.9% average overpayment, while historical estimators like Blockstream Esplora had miss rates under 5% but overpayment exceeding 200% during volatile periods. For most users, a mempool-based estimator with RBF enabled offers the best outcome.

Why does Bitcoin Core overestimate transaction fees?

Bitcoin Core's fee estimator uses historical confirmation data rather than examining the current mempool. Its conservative mode applies long lookback windows and high confidence thresholds, overpaying in 96% of estimates according to a Delving Bitcoin analysis. Since v28.0, the default was changed to economical mode, which reduces but does not eliminate this bias. The design intentionally favors overpayment over stuck transactions.

How often should I poll a fee estimation API?

For most wallet implementations, polling every 30 to 60 seconds provides sufficient granularity. mempool.space also supports WebSocket connections for real-time updates without polling. Polling more frequently than every 10 seconds is unlikely to yield meaningfully different estimates and may trigger rate limits on public APIs. If your application constructs transactions in advance, re-check the fee rate immediately before broadcasting.

Can I avoid Bitcoin transaction fees altogether?

On-chain transactions always require a fee (though the minimum relay fee of 1 sat/vB costs very little during quiet periods). To avoid on-chain fees entirely, use a Layer 2 protocol. Lightning Network payments cost fractions of a cent in routing fees, and Spark enables near-zero-fee Bitcoin and stablecoin transfers with instant settlement.

What is the difference between sat/vB and BTC/kB in fee estimation?

Both units express the same concept (fee rate per unit of transaction weight) at different scales. Most modern tools use sat/vB (satoshis per virtual byte), which is more intuitive. Bitcoin Core's RPC returns fees in BTC/kvB (bitcoin per kilovirtual byte). To convert: sat/vB = BTC/kvB × 100,000. A fee of 0.0001 BTC/kvB equals 10 sat/vB. BitGo uses sat/kB, which is the legacy unit that does not account for the witness discount.

Should I use RBF instead of trying to estimate the perfect fee?

Replace-by-Fee is a practical complement to fee estimation, not a replacement. Start with a mempool-based estimate, opt in to RBF when constructing the transaction, and bump the fee if the transaction does not confirm within your target window. Full RBF is now standard in Bitcoin Core v29, meaning nodes relay replacements even without explicit opt-in signaling. For details on fee bumping techniques, see our research on RBF and CPFP fee bumping.

Is mempool.space free to use for production applications?

The public mempool.space API is free and unauthenticated, with informal rate limits of approximately 10 requests per second. For production applications with higher throughput, self-hosting a mempool.space instance (backed by your own Bitcoin node) removes all rate limits and eliminates third-party dependency. The project is AGPL-licensed, so modifications to the backend must be released as open source. Enterprise sponsorship tiers with higher rate limits are available.

This tool is for informational purposes only and does not constitute financial advice. Data is approximate and based on publicly available information. Fee estimation accuracy varies with network conditions. Always verify current fee rates before broadcasting transactions.