What happened
On 21 August 2026 Bitcoin Core merged
pull request 34075, which gives a node a
second way to answer the question every wallet asks it: what fee should this transaction
pay. The
release note
sets out the arrangement. The estimatesmartfee RPC "now combines two fee rate
estimators: the existing block policy fee rate estimator and a new mempool fee rate
estimator", and it "returns the lower of the two fee rate estimators' results, so the
mempool fee rate estimator can only lower the block policy fee rate estimate." The work
is by ismaelsadeeq, who describes it as "another attempt to fix #27995 using a better
approach."
What it changes
The estimator Core already had answers from history. It watches what feerates confirmed, over how many blocks, and reports what has been working. That record is slow to notice when demand has gone, and the pull request names the case it is aimed at: the new estimate is "particularly useful in scenarios where the Block Policy Estimator recommends a high feerate while the mempool is empty."
The new estimator does not look backwards at all. Asked for a number, it builds the block a miner would build next out of what is sitting in the node's mempool, then takes a percentile of the feerates in that template: the 75th for an economical estimate, the 50th for a conservative one. Those two constants are measurements, not guesses. "Empirical data from both myself and Clara Shikhelman shows that the 75th percentile feerate for economical users and the 50th percentile feerate for conservative users provide positive confirmation guarantees."
The mempool is allowed to argue the fee down and never up. That asymmetry is the safety property, and the reason for it is that a mempool is something a miner can stuff. The pull request is explicit: "The Block Policy Estimator itself is not gameable in this way, so the combined estimate is not susceptible to this attack increasing the returned feerate."
There is a second guard. The mempool estimate is offered only when the last six blocks suggest the node is seeing what miners are seeing: the ratio of mempool weight removed by block connection to block weight has to be "greater than 75% across the tracked window", which the pull request offers as "rough confidence that the node's mempool matches that of the majority of the hashrate", while conceding that "the 75% threshold is arbitrary and can be adjusted."
Callers who want the old answer can still have it. estimatesmartfee takes a
fee_rate_estimator option of "none", "block_policy" or "mempool_policy", and
"users who want the previous behavior can select the block policy fee rate estimator
explicitly."
What it does not change
No consensus rule and no relay rule moved. This is advice a node gives a wallet, and a transaction paying any feerate is exactly as valid as it was before. The change is also in master rather than in a release, so no published binary behaves this way yet.
The error did not go away, it changed direction. The author's own measurement over historical data reports "a 73% success rate with 0% overestimation, and 26% underestimation", which is roughly a 29% cut in overestimation and a new failure mode where the number comes back too low. That trade is deliberate: "we now assume it is relatively easy to fee-bump later if a transaction does not confirm, whereas once a fee is overestimated there is no way to recover from that." The assumption holds only where bumping is actually available. If your wallet cannot replace or accelerate a pending transaction, an underestimate is paid in waiting instead of in sats.
Those are the author's figures on past data, not an independent replication, and the constants are provisional: the pull request says they "can be adjusted" and that parallel work is "running benchmarks across fee estimators to find a sweet spot." One more thing got narrower rather than wider. "The combined estimate requires both estimators to succeed", so a node still loading its mempool, or one that has not seen enough recent blocks, now returns an error where it used to return a number.
Context
Block space is an auction, and the bidding is visible: everything waiting is in the mempool, in the open. The estimator that shipped for years chose not to look at it, because reading a public queue is exactly the sort of thing an interested party can manipulate. What changed is the shape of the compromise rather than the risk, since the mempool now gets a vote in one direction only.
The case for reading it is easiest to see after a spike ends. When fees ran past the block subsidy in May 2023, the queue cleared in days while a history-based estimate was still describing the week before. The health check is the other half of the point: the node you run has its own mempool, not the mempool, and the new estimator declines to answer when its own view stops looking like everyone else's.