Many wallet interfaces still present Bitcoin fees as if the user were choosing among three moods: high, medium, or low. That simplification helps beginners get a transaction out the door, but it obscures what the fee market is actually doing.
A Bitcoin transaction is not paying for priority in an abstract sense. It is bidding for scarce blockspace inside a queue where miners select transactions and packages that maximize fee revenue under current policy and current mempool conditions. Bitcoin Optech defines the goal of fee estimation as translating a desired confirmation timeframe into the minimal feerate the transaction should pay. That framing is much more useful than a basic speed tier because it treats fee choice as a market-clearing problem rather than a generic urgency slider.
The key idea is that the right fee is not simply “high enough.” It is the approximate clearing price of the mempool for the confirmation target the user actually cares about.
The phrase mempool clearing price is not an official Bitcoin Core label, but it is the most practical way to think about what fee estimation is trying to find.
At any given moment, the mempool contains a stack of transactions competing for limited space in upcoming blocks. The transactions closest to the margin between “likely to fit soon” and “likely to wait longer” define the price the user effectively needs to beat for a chosen confirmation horizon. If the target is the next block or the next few blocks, that marginal feerate is usually higher. If the user can wait much longer, the relevant clearing threshold is lower.
Bitcoin Core’s fee estimator is designed around this general problem rather than around subjective labels. The estimator tracks fee-rate buckets and now includes a minimum tracked bucket down to 0.1 sat/vB, matching the node’s default minrelaytxfee. The same release notes say that for a given confirmation target, the estimator returns the average value of the minimum bucket with sufficient data.
That is not the same thing as a perfect real-time auction price, but it points to the same concept. Fee estimation is an attempt to infer the marginal price needed to clear the queue within a given window.
High, medium, and low are vague because they compress two different questions into one. The first question is how urgently the user wants confirmation. The second is what the mempool currently requires to satisfy that urgency. A three-tier interface often hides both the target and the market conditions behind one rough label.
The result is predictable. Some users overpay because the “high” setting is far above the current clearing threshold. Others underpay because a “medium” label sounds reasonable even though the mempool is currently much tighter than usual. Still others assume low means cheap and merely slower, when in reality it may mean falling below the likely clearing threshold for many blocks or even many days depending on the backlog.
The better mental model is that every confirmation target has its own relevant market-clearing range, and that range moves as the mempool changes.
One reason fee estimation is difficult is that block production is irregular. Even if a user expects a new block every ten minutes, actual confirmation timing is still probabilistic because one block can take much longer than average to arrive. That means a feerate that looks sufficient in expected-block terms can still disappoint on a real-world clock if blocks arrive slowly.
The second difficulty is that the mempool is not static. Transactions arrive continuously, priorities change, and some transactions later get fee-bumped. That means the queue the user sees at broadcast is not the exact queue miners will see when they build the next block.
The third difficulty is package logic. Bitcoin Core and miners do not always think only in terms of isolated transactions. CPFP, package relay, and related work mean that some low-fee transactions become economically attractive only because of their descendants. Cluster mempool work could improve fee estimation precisely because current fee estimation tracks individual transactions even though mining already supports CPFP-like package economics.
That is why a clean fee estimate is harder than “look at the top of the mempool and add a little.” The real queue is more dynamic and more package-aware than that simplistic picture suggests.
A common misunderstanding is to treat the node’s minimum relay fee as if it were close to the actual market-clearing fee. Those numbers are related only loosely.
Bitcoin Core’s policy define the default minimum relay transaction fee and the default incremental relay fee, and recent Optech discussion notes that the long-standing default minimum relay transaction feerate on many nodes has been around 1 sat/vB, although Core 31.0’s estimator now tracks as low as 0.1 sat/vB buckets for estimation purposes. The point is that relay minimum tells the user roughly what a node may be willing to accept into the relay network under policy, not what the next block or next few blocks are likely to require.
In a congested environment, the mempool clearing price for fast confirmation can sit far above the relay minimum. In a quiet environment, the clearing threshold can drift much closer to the low end. Using the relay floor as a confirmation target is therefore usually a category error.
Some users look only at what recently confirmed and assume they can copy the last block’s apparent minimum feerate. That works poorly because the next confirmation decision depends less on the last block than on the remaining queue ahead of the transaction.
A mempool with very little high-fee backlog may clear quickly even if the most recent block was relatively expensive. A mempool stacked with many high-fee or package-boosted transactions may remain tight even if one recent block happened to include some lower-fee data near its margin.
This is why the phrase clearing price is more helpful than the phrase average fee. What matters is not what fees were recently paid on average. What matters is what fee is likely to sit just high enough above the marginal cutoff for the user’s desired confirmation window.
Fee estimation used to be simpler to explain because individual transaction feerates were closer to the whole story. That is becoming less true.
Bitcoin Core introduced limited one-parent-one-child package behavior, allowing below-minimum-fee parents to be paired with children and accepted as a package in some cases. Meanwhile, cluster mempool work is explicitly intended to reason more intelligently about groups of related transactions and their combined mining value. Ccluster mempool divides groups of transactions into chunks that can be tracked together for mining and fee estimation.
The reason this matters for ordinary users is not that everyone now needs to become a mempool engineer. The point is that fee estimation is moving further away from crude one-transaction heuristics and closer to a package-aware view of miner incentives. As more fee-bumping and contract workflows use package-based logic, the mempool clearing price becomes a property of transaction sets, not only of standalone feerates.
Despite all the technical nuance, the most important input remains the user’s time preference. Bitcoin Optech’s explanation is still the cleanest framing: the purpose of fee estimation is to translate a target timeframe into a minimal feerate. That means the right fee begins with a human question, not a network question. How soon does the payment actually need to confirm.
If the answer is “as soon as reasonably possible,” the user is bidding against the near-term clearing threshold. If the answer is “sometime today,” the threshold can be lower. If the answer is “whenever the mempool cools,” the fee can be lower still. The mistake is not choosing a lower fee. The mistake is choosing a lower fee while mentally demanding a faster confirmation target than that fee is likely to buy.
A better reading process starts by ignoring generic labels and instead asking three questions. The first is the real confirmation deadline. The second is the current backlog ahead of that target. The third is whether the transaction can be fee-bumped later through RBF or CPFP if the initial estimate proves too conservative.
That last question matters because the ability to fee-bump changes how aggressive the user needs to be up front. A wallet that supports later adjustment can start closer to the current marginal clearing threshold and respond if the mempool moves. A wallet without good bumping support may need a wider safety margin.
This is also why wallet design matters almost as much as fee estimation itself. A perfect estimate is impossible. A good estimate combined with reliable fee-bumping is often the practical answer.
Bitcoin fee estimation is best understood as an attempt to find the mempool’s clearing price for a chosen confirmation target, not as a choice among vague speed settings. The user is bidding for scarce blockspace inside a moving queue, and the right bid depends on time preference, backlog, policy limits, and increasingly on package-aware mining logic rather than only on isolated transaction feerates. Bitcoin Core’s recent changes and Bitcoin Optech’s explanations both point in the same direction: the fee market is better modeled as a marginal clearing problem than as a static list of high, medium, and low options. Once that is clear, fee estimation becomes less mysterious and more honest. It is not about finding the “correct” fee in the abstract. It is about paying just enough to clear the queue on the timeframe the user actually cares about.
The post Bitcoin Fee Estimation: Mempool Clearing Price, Not Just ‘High, Medium, Low’ appeared first on Crypto Adventure.
