Best Bitcoin Fee Estimation API for Wallets and Exchange Withdrawals

Choosing a fee estimation API looks like a small integration decision and behaves like a pricing decision. Every withdrawal your platform sends pays whatever number that endpoint returns, and nobody on the team is checking whether the number was right, because the transaction confirmed and confirmation looks like success.

It is not success. A transaction that confirms in one block when you asked for six confirmed too expensively, and you paid for the difference. This is a comparison of what the main options actually return, measured rather than quoted from documentation.

Do Bitcoin fee estimation APIs agree with each other?

No, and the gap is much wider than most teams assume. We read three public estimators within the same second on 17 September 2026. All three providers reported the same chain tip, block 967,354, so they were answering an identical question about an identical chain.

Two details are worth pulling out of that table. BlockCypher's cheapest tier, low_fee_per_kb at 1,348 sat/kB, is 35 percent more expensive than mempool.space's most urgent tier. A team that picks the conservative vendor and then selects its economy setting still pays more than a team that picks the aggressive vendor and asks for the fastest confirmation on offer. The tier label tells you nothing across providers.

The other detail is that mempool.space returned exactly 1 for all five tiers, fastest through minimum, on two separate reads minutes apart. An estimator that cannot separate "fastest" from "economy" is not ranking anything. It has bottomed out on a floor.

We read the same three endpoints again the next day, because a single reading proves little. At 13:03 UTC on 18 September 2026, with all three on block 967,554, mempool.space quoted 5 sat/vB for its fastest tier, BlockCypher 2,856 sat/kB (2.856 per byte) and Esplora 1.069. The median fee rate paid across the thirty blocks 967,525 to 967,554 had risen to 1.02 sat/vB. The provider that quoted lowest on the 17th quoted highest on the 18th, at 4.9 times the going rate. No estimator held its position for a day, which is the case for auditing against confirmed blocks rather than picking one and trusting it. If you are weighing a multi-chain suite for fees, our Crypto APIs alternative page compares its fee endpoint and plans.

What fee rate is the Bitcoin network actually charging?

The only way to grade an estimator is against blocks. We took the fifteen consecutive blocks from 967,340 to 967,354 and compared the fee rate range in each one against the quotes above.

The median fee rate paid came in below Esplora's next-block estimate in fifteen blocks out of fifteen, and below BlockCypher's high tier in fifteen out of fifteen. The median of those fifteen block medians was 0.348 sat/vB. Fourteen of the fifteen blocks confirmed at least one transaction at or below 1 sat/vB, and the cheapest confirmed transaction in the sample paid 0.307 sat/vB.

One block in the sample, 967,343, held only 569 transactions and reported a median of zero, which is an outlier we are flagging rather than leaning on. Excluding it changes none of the conclusions above.

Is 1 sat/vB still the minimum Bitcoin fee?

No, and this is the stale fact underneath most fee guidance currently ranking for these queries. Several of the pages you will find searching for a good sat/vB rate still state that nodes enforce a 1 sat/vB relay floor.

Bitcoin Core pull request 33106 lowered the default minrelaytxfee and incrementalrelayfee from 1 sat/vB to 0.1 sat/vB, a 90 percent cut. Bitcoin Core 31.0, released 19 April 2026, then moved the estimator itself. Its release notes state that the fee estimator minimum fee rate bucket "was updated from 1 sat/vB to 0.1 sat/vB, which matches the node's default minrelaytxfee", and that estimates for a given confirmation target may now return sub-1 sat/vB values. The same upgrade invalidates previously saved estimates in fee_estimates.dat, so the estimator restarts its statistics.

That is the real story in the numbers above. Bitcoin Core moved the floor. On the evidence of these readings, the public REST estimators have not followed, and teams are paying the difference. For the mechanics of how a fee rate becomes a fee, our explainer on Bitcoin transaction fees covers the arithmetic.

How much does the wrong fee tier cost an exchange?

It is the gap between your tier and the market, multiplied by payout volume. A standard single-input, two-output native SegWit spend is about 141 vB. At the 0.348 sat/vB median actually paid, that is 49 satoshis, roughly 3.7 cents with bitcoin at 76,488 dollars. At BlockCypher's high tier it is 564 satoshis, about 43 cents.

The gap is 515 satoshis per withdrawal. A desk pushing a thousand unbatched withdrawals a day gives up about 0.005 BTC daily, around 394 dollars, and a little over 143,000 dollars across a year. Batch the payouts into one transaction with many outputs and most of that disappears, which is the same lesson payables teams learned years ago about scheduled disbursement runs beating hundreds of individual payments.

Which Bitcoin fee estimation API should you use?

Honest summary, including where each one wins.

Latency figures are from our own reads on 17 September 2026 and will vary by region. Every provider here is competent. The problem is not that any of them is broken, it is that a single number from any of them is one opinion about a queue, and none of them shows you the queue.

Should you run your own node for fee estimation?

Run one if fees are a material cost line, because estimatesmartfee is built from what your node observed confirming and owes nothing to a vendor's tier labels. It returns a rate in BTC per kilo-virtual-byte along with the number of blocks the estimate is actually valid for, which is more information than any of the REST endpoints give you.

The catch is that a node with no history has nothing to estimate from. Fee estimation failures are common on a node that recently finished syncing, one that was offline for a stretch, or one that just upgraded past 31.0 and had its saved estimates invalidated. We cover the economics of that decision in our breakdown of what it costs to run a Bitcoin node.

How do you build a fee policy that does not break?

Build the rule, not the constant. Everything measured here describes a quiet mempool, and when competition for block space returns, the conservative estimators will be closer to right and paying 0.3 sat/vB will strand your transaction for days.

A policy that survives both regimes has four parts. Read current mempool state rather than reusing a cached tier. Floor your rate at something you know will propagate, because a transaction that never reaches a miner is invisible rather than cheap. Cap it at an exposure you are willing to pay per payout. Then measure your realized fee rate, fee divided by virtual size, against the fee range of the block that actually confirmed you, and review that number monthly.

That last step is the one almost nobody does, and it is the one that catches a provider tier quietly costing you 500 satoshis a payout for a month. It needs fee and weight on every transaction plus the mempool alongside the confirmed chain, which is what a Bitcoin fee estimation API built on an indexed chain gives you. The same indexed mempool answers the other question that decides payment risk, whether a pending payment has been replaced before it confirms, and you can read live unconfirmed state directly through the Bitcoin mempool API.

Informational on-chain data only, not financial advice.