Bitcoin Fee Estimation APIs: Mempool.space vs Blockstream vs Others

Bitcoin Fee Estimation API Providers Compared

Accurate fee estimation is critical for any Bitcoin application. Overpaying wastes user funds; underpaying leads to stuck transactions and poor user experience. Developers building wallets, exchanges, and payment processors need reliable API access to current feerate data, but the available providers differ substantially in methodology, accuracy, rate limits, and cost.

This comparison covers the five most widely used fee estimation sources for Bitcoin developers: mempool.space, Blockstream Esplora, BitGo, BlockCypher, and Bitcoin Core's built-in estimatesmartfee RPC. Each takes a different approach to predicting what feerate will get a transaction confirmed within a target number of blocks.

Estimation Methodologies

The accuracy of a fee estimate depends on the methodology behind it. Providers use fundamentally different approaches, and understanding these differences helps developers choose the right data source for their use case.

mempool.space: Mempool-Based Projection

mempool.space takes the most sophisticated approach among hosted APIs. Rather than relying on historical confirmation data, it analyzes the current state of the mempool in real time. The API examines unconfirmed transactions sorted by feerate, projects which would be included in the next block template, and calculates percentile feerates by cumulative block weight. This method adapts within seconds to sudden fee spikes because it reflects what miners would actually select right now, not what worked in the past.

The /api/v1/fees/recommended endpoint returns five integer values in sat/vB: fastestFee (next block), halfHourFee (~3 blocks), hourFee (~6 blocks), economyFee (low priority), and minimumFee (the minimum relay fee accepted by nodes). For sub-satoshi precision, the /api/v1/fees/precise endpoint returns the same fields with up to 3 decimal places (useful when feerates drop below 1 sat/vB). For developers who need the most granular data, /api/v1/fees/mempool-blocks returns the projected feerate distribution across the next several block templates, enabling custom fee selection UIs similar to the mempool.space website.

Blockstream Esplora: Bitcoin Core Wrapper

Blockstream's Esplora API uses /api/fee-estimates to return a JSON object mapping confirmation targets (in blocks) to estimated feerates in sat/vB. The keys are block target numbers (e.g., "1", "6", "144", up to "1008"), and values are decimal feerates. Under the hood, Esplora wraps Bitcoin Core's estimatesmartfee RPC, so it inherits the same historical, confirmation-based methodology. The response format is straightforward and well-suited for applications that need a specific block target rather than named priority levels.

Bitcoin Core: Statistical Bucketing

Bitcoin Core's estimatesmartfee RPC uses a statistical approach that tracks historical confirmation times across exponentially spaced feerate buckets (5% intervals). It measures what percentage of transactions in each bucket confirmed within a given number of blocks, requiring 95% confidence before returning an estimate. The command accepts a conf_target parameter (1 to 1008 blocks) and an optional estimate_mode: ECONOMICAL (shorter time horizon with ~18 block half-life, more responsive to fee drops) or CONSERVATIVE (longer horizon with ~144 block half-life, less likely to underestimate).

This approach is reliable during periods of stable fee conditions but can lag behind rapid fee changes. Because it relies entirely on historical confirmation data and does not examine the current mempool state, it may recommend stale feerates during sudden congestion spikes. A proposed Bitcoin Core PR (#34075) would add mempool-based estimation and showed 81% accuracy in testing versus approximately 60% for the current historical approach, but has not yet been merged. Running estimatesmartfee requires a synced full node with ongoing bandwidth and storage.

BlockCypher: Proprietary Algorithm

BlockCypher returns fee estimates embedded in its chain info endpoint at /v1/btc/main. The response includes high_fee_per_kb, medium_fee_per_kb, and low_fee_per_kb (in satoshis per kilobyte, not per vByte). The estimation methodology is proprietary and not publicly documented. Note the unit difference: developers must divide by 1000 to convert from sat/kB to the sat/vB standard used by SegWit-aware wallets.

BitGo: Institutional-Grade Estimates

BitGo provides fee estimation at /api/v2/btc/tx/fee, which is publicly accessible without authentication. The response includes a feeByBlockTarget map with feerates in sat/kB for block targets 1 through 144, plus a confidence percentage. Because BitGo is primarily a custody and wallet platform, the fee API is most useful for teams already integrated with BitGo's SDK. The API enforces a global rate limit of 10 requests per second across all endpoints.

Response Format Comparison

How each API structures its response affects integration complexity. The table below compares the key format differences developers should know.

Note: Unit differences are a common source of bugs. mempool.space and Esplora return sat/vB (the standard for SegWit transactions). BlockCypher and BitGo return sat/kB. Bitcoin Core returns BTC/kvB. Failing to convert correctly can result in 1000x overpayment or transactions that never confirm.

Self-Hosting Options

For applications that need to eliminate third-party dependencies, two providers offer open-source self-hosting options. Running your own instance removes rate limits, avoids API downtime risk, and keeps transaction data private: your application never leaks user addresses or spending patterns to a hosted service.

mempool.space is fully open source (MIT license) and available on GitHub with Docker images. One-click installs are available on Umbrel, RaspiBlitz, RoninDojo, MyNode, and StartOS. The self-hosted instance requires a Bitcoin Core full node plus an Electrs (or Fulcrum) indexer. The setup is more resource-intensive than a standalone node but provides the full feature set of the hosted API, including the granular mempool-blocks fee projection data. Many enterprises and privacy-focused wallets run their own instances.

Blockstream's Esplora is also open source with Docker-based deployment. The resource requirements are heavier than mempool.space for the data store: the Esplora index can reach 1.3 TB before compacting to approximately 800 GB, and Blockstream recommends at least 16 CPU cores and 64 GB RAM. The tradeoff is more comprehensive data retrieval capabilities, including spent transaction output lookups useful for Lightning channel forensics.

Bitcoin Core itself is the simplest self-hosted option if you only need fee estimation. Running estimatesmartfee requires no additional indexer: just a synced full node with approximately 600 GB of SSD storage. The tradeoff is that Bitcoin Core's estimates can lag during rapid fee changes, and you lose the granular mempool visualization data that mempool.space provides.

Accuracy and Tradeoffs

No fee estimator is perfect. The fee market is inherently unpredictable: a single large transaction batch or mining pool going offline can shift feerates dramatically between blocks. Each estimation approach handles this uncertainty differently.

Independent benchmarks reveal the core tension: lower miss rates (where your transaction confirms within the target) often come at the cost of higher overpayment. Blockstream's conservative historical approach tends to overpay significantly during volatile periods to ensure confirmation, while mempool-based estimators like mempool.space offer lower overpayment but may miss the target more often during rapid fee shifts. For applications like interactive fee estimators that need real-time responsiveness, mempool-based data is generally superior.

Mempool-based estimates can overreact to temporary spikes. If a whale broadcasts a burst of high-fee transactions that clear in a single block, mempool.space will briefly recommend elevated feerates even though the spike is already resolving. Bitcoin Core's longer-horizon statistical approach smooths out these transients, making it more conservative but less volatile. For more on how the Bitcoin fee market behaves, see our research on fee market dynamics.

Integration Considerations for Developers

Choosing a fee estimation API involves tradeoffs beyond raw accuracy. Developers should consider these factors:

• Reliability: hosted APIs introduce a dependency. If mempool.space goes down, your wallet cannot estimate fees unless you have a fallback. Many production wallets query multiple providers and take the median.
• Privacy: every API request leaks information. A hosted fee API call from a mobile wallet reveals the user's IP address and the timing of their transaction. Self-hosting or using Tor mitigates this, as do APIs that serve static data without requiring per-transaction queries.
• Latency: for payment applications where users are waiting at a checkout screen, API response time matters. mempool.space and Esplora typically respond in under 100ms from their CDN-backed endpoints. Bitcoin Core RPC calls to a local node return in single-digit milliseconds.
• Cost: for most applications, free tiers are sufficient. mempool.space's unauthenticated rate limit of roughly 10 requests per second handles all but the highest-volume services. BlockCypher's free tier is more restrictive at 100 requests per hour without a key, which may not be enough for production use.

For Bitcoin Layer 2 applications built on protocols like Spark, on-chain fee estimation is still relevant for channel opens, closes, and fee bumping operations. Accurate feerate data ensures that on-chain anchor transactions confirm promptly without overpaying.

Simple Median vs. Feerate Distribution Estimates

Most fee APIs return a single number per priority level: the recommended feerate for a given confirmation target. This is simple to implement but loses nuance. mempool.space's /api/v1/fees/mempool-blocks endpoint takes a different approach: it returns the projected feerate distribution across the next eight block templates, showing the minimum and maximum feerates and the total weight of transactions at each level.

This granular data enables wallet developers to build more sophisticated fee selection UIs. Instead of offering three static choices (fast / medium / slow), a wallet can show users exactly where their transaction would fall in the next block template and let them choose their position on the feerate curve. This is the approach used by mempool.space's own transaction builder and by wallets like Sparrow. The tradeoff is implementation complexity: parsing and presenting the block template projection requires significantly more frontend work than consuming a simple recommended fee object.

Choosing the Right Provider

For most wallet developers: mempool.space's recommended fees endpoint is the best starting point. It requires no authentication, returns human-readable priority levels in sat/vB, updates in real time, and is backed by the most actively maintained open-source project in this space.

For privacy-sensitive applications: run your own instance of mempool.space or Esplora, or use Bitcoin Core's estimatesmartfee directly. This eliminates the need to leak any data to third parties.

For institutional or custodial platforms already using BitGo: the BitGo fee API integrates naturally with BitGo's wallet SDK and transaction building workflow. Adding a separate fee estimation provider would add unnecessary complexity.

For fault tolerance: query at least two independent sources (e.g., mempool.space and your own Bitcoin Core node) and use the higher estimate for time-sensitive transactions or the lower estimate for batched, delay-tolerant operations like UTXO consolidation.

Frequently Asked Questions

Which Bitcoin fee estimation API is most accurate?

No single provider is most accurate in all conditions. Mempool-based estimators like mempool.space tend to offer lower overpayment for next-block targets because they model the current mempool state directly. Historical estimators like Blockstream/Esplora tend to overpay more but miss the target less often during stable conditions. For longer confirmation targets (6+ blocks), Bitcoin Core's estimatesmartfee with CONSERVATIVE mode performs well. Accuracy depends on mempool volatility, block timing variance, and the specific confirmation target.

Is the mempool.space API free to use?

Yes. mempool.space offers its API without authentication at a rate limit of approximately 10 requests per second. This is sufficient for most wallets and applications. Enterprise users with higher volume requirements can purchase dedicated infrastructure starting at $1,499/month (Silver tier). Alternatively, you can self-host a mempool.space instance with no rate limits at all, since the entire project is open source under the MIT license.

How do I convert between sat/vB, sat/kB, and BTC/kvB?

1 sat/vB = 1000 sat/kB = 0.00001 BTC/kvB. To convert BlockCypher or BitGo responses (sat/kB) to sat/vB, divide by 1000. To convert Bitcoin Core responses (BTC/kvB) to sat/vB, multiply by 100,000 (10^5). Getting this conversion wrong is one of the most common integration bugs: a 10 sat/vB fee expressed as 10 BTC/kvB would result in a massively overpaid transaction.

Should I run my own Bitcoin node for fee estimation?

If your application is privacy-sensitive, handles significant transaction volume, or cannot tolerate third-party API downtime, running your own node is recommended. A synced Bitcoin Core node provides unlimited, zero-latency access to estimatesmartfee. Pair it with a self-hosted mempool.space or Esplora instance if you want richer mempool data. The infrastructure cost is a server with at least 600 GB of SSD storage, 2+ CPU cores, and 4+ GB of RAM. See our guide on Bitcoin node cost requirements for current estimates.

What happens if the fee estimate is too low?

A transaction with a feerate below what miners are currently selecting will remain unconfirmed in the mempool until feerates drop or the transaction is evicted (typically after 14 days with default mempool settings). Users can unstick transactions using Replace-by-Fee (RBF) to broadcast a replacement at a higher feerate, or Child-Pays-for-Parent (CPFP) to attach a high-fee child transaction. For a practical guide, see our fee bumping guide.

How often should my application refresh fee estimates?

For wallets showing a fee preview before the user confirms: refresh when a new block arrives (subscribe to the mempool.space WebSocket at /api/v1/ws for block notifications) and every 30 to 60 seconds between blocks. For automated systems broadcasting batched transactions: refreshing once per block (roughly every 10 minutes) is sufficient. Avoid polling more frequently than once per second, as feerates rarely change that fast and aggressive polling will trigger rate limits on hosted APIs.

Can fee estimation APIs predict fees hours or days in advance?

No. Fee estimation APIs reflect current mempool conditions, not future demand. The Bitcoin fee market is driven by unpredictable factors: exchange withdrawals, inscription waves, consolidation batches, and mining hash rate fluctuations. Historical feerate data (available from mempool.space and block explorers) can reveal patterns like lower weekend fees, but these are trends, not predictions. Applications that need to schedule future transactions should build in RBF capability so the feerate can be adjusted at broadcast time.

This tool is for informational purposes only and does not constitute financial advice. API rate limits, pricing, and features change over time. Always verify current documentation from each provider before building production integrations.