Estimated Confirmation Blocks

"Estimated confirmation blocks" is the other side of fee estimation: at a given fee rate, about how many blocks until a transaction confirms? Or, turned around, what fee rate does it take to confirm within a target number of blocks? Bitcoin aims for a block every 10 minutes on average, so a target of 3 blocks is roughly half an hour, and some fee tools show the target as a time. mempool.space's fee API, for example, names its rates fastest, half hour, hour, economy and minimum.

How the estimate is built:

• Bitcoin Core's estimatesmartfee RPC returns a fee rate that should get a transaction confirmed within a target of 1 to 1,008 blocks (it treats 1 as 2). It works from the node's own history. Core sorts the transactions it sees into fee-rate buckets, tracks how many blocks each one took to be mined, counting the ones still waiting too, and returns the lowest rate whose bucket confirmed often enough within the target. The answer is never below the node's current mempool minimum fee.
• Projected blocks. Sites like mempool.space sort the waiting transactions into the blocks they expect miners to build next, each up to the 4 million weight unit limit, and recommend fee rates from the medians of the first few.
• Wallets pick a target and look up the fee rate it needs. Bitcoin Core's own wallet, for example, aims for 6 blocks by default and asks its estimator what that takes.

What can throw off the estimate:

• Fee spikes. Miners fill blocks from the highest fee rate down, so a wave of better-paying transactions can push yours back. The estimate updates, but a transaction you've already broadcast keeps the fee it was sent with.
• Empty blocks. Now and then a block carries no transactions except the miner's own reward. Block 970,654, mined on October 9, 2026, was one. A block like that does nothing for the queue.
• History lags. Core's estimator gives recent blocks the most weight, but even its shortest window has a half-life of 18 blocks, about 3 hours, so a sudden rush or a sudden lull shows up in its numbers only after a while.

An estimate is a forecast, not a promise. If a transaction is taking longer than you want, fee bumping can speed it up. Replace-by-fee (RBF) swaps it for a version that pays more, and child-pays-for-parent (CPFP) spends one of its outputs in a new transaction that pays enough for both.