Two Wallets, One Mempool, Two Very Different Numbers
You paste a Bitcoin address, hit send, and your wallet suggests 42 sat/vbyte. Your friend, sending at the exact same moment from a different wallet, gets 11 sat/vbyte. Same network. Same block backlog. Completely different answers.
Not a glitch.
It's a window into one of the more quietly fascinating engineering disagreements in the Bitcoin ecosystem: fee estimation algorithms, and why they come apart the moment the mempool gets crowded.
No wallet actually knows what fee will get your transaction confirmed. They're all making educated guesses with different models, different data sources, and different assumptions about how long you're willing to sit on your hands. Under normal conditions those differences barely matter. Under congestion, they can separate a transaction that confirms in the next block from one that idles for six hours.
The Raw Material: What Wallets Are Actually Looking At
Every full node maintains its own local copy of the mempool, the holding pen of unconfirmed transactions waiting to be mined. Miners pick from that pool greedily, almost always taking the highest-fee transactions first. So in theory, fee estimation is simple: look at what's in the mempool, figure out how many vbytes of transactions sit ahead of your target confirmation window, and price yourself just above the cutoff.
Except the mempool is a moving target. New transactions arrive continuously. Miners pop off the top. And your local mempool might not match your neighbor's, because node operators set different `maxmempool` limits (Bitcoin Core defaults to 300 MB), and propagation across the peer-to-peer network isn't instantaneous.
This is the first divergence point. Wallets running their own full node are looking at one snapshot. Wallets querying a third-party API are looking at another. Lightweight SPV wallets are looking at whatever their backend provider decided to show them. Three wallets, three potentially different data inputs, before any estimation logic even runs.
The Two Main Families of Estimation Logic
Beyond data sources, wallets split into two broad philosophical camps on how to turn mempool data into a fee recommendation.
The historical confirmation approach is what Bitcoin Core's built-in `estimatesmartfee` uses. It doesn't primarily look at the current mempool state. Instead, it watches which fee rates actually got confirmed over recent blocks, buckets those observations by fee rate, and builds a probability distribution. Ask it for a 90% chance of confirming within six blocks and it returns the fee rate at which 90% of historically similar transactions made it through in that window. The logic is sound: past miner behavior is a reasonable proxy for near-future miner behavior.
The catch is lag. During a sudden congestion spike, the historical model is still partly weighted toward the quiet period that just preceded it, like a ship's compass that hasn't finished settling after you changed course. It takes several blocks of high-fee confirmations to update the distribution meaningfully. So Bitcoin Core can under-estimate during the first hour of a congestion event, and that first hour is usually when it matters most.
The mempool-projection approach is what wallets like Electrum (with certain backends), Sparrow, and fee APIs like mempool.space use. They look at the current mempool directly, sort transactions by fee rate, and calculate how many blocks' worth of transactions (each block being roughly 1 million vbytes) are sitting ahead of your target fee rate. If there are 3 vMB of higher-fee transactions queued, you're looking at roughly three blocks minimum. Price yourself just above that cutoff and you should get in on block four.
This approach reacts faster to sudden spikes. The tradeoff: it assumes the current mempool snapshot is stable, which it often isn't. A sudden wave of RBF replacements flooding in after a price move can render a projection stale in minutes.
Here's a concrete illustration. Two users, Marcus and Priya, both send transactions on a busy Saturday afternoon. Marcus uses a hardware wallet paired with Bitcoin Core. Priya uses a mobile wallet backed by a mempool-projection API. Marcus's wallet, drawing on historical data weighted toward the quieter preceding days, suggests 18 sat/vbyte. Priya's wallet, staring at a mempool that just swelled with a wave of inscription activity, suggests 55 sat/vbyte. Both transactions go out. Marcus waits four hours. Priya confirms in twenty minutes. Neither wallet was broken. They were solving different versions of the same problem.
Where Things Really Come Apart
Most wallets let you choose a confirmation target: next block, within an hour, low priority. The underlying definitions of those buckets vary substantially between implementations.
Bitcoin Core's `estimatesmartfee` with `CONSERVATIVE` mode adds an additional buffer on top of the `ECONOMICAL` estimate, specifically to handle sudden mempool spikes. Same call, same node, different numbers depending on which mode a wallet developer chose to expose. Most users have no idea this switch exists, and that's a genuine UX failure on the part of wallet teams who should surface it.
Then there's Replace-By-Fee. Wallets that mark transactions as RBF-capable can afford to suggest slightly lower initial fees, knowing the user can bump later if needed. Wallets that don't support RBF have to get it right the first time, so their algorithms often build in a larger safety margin. That margin shows up as a systematically higher suggestion even when the mempool looks identical to the one next door.
One more wrinkle: some wallets smooth their estimates over a rolling window of blocks to avoid thrashing (suggesting 45 sat/vbyte one second, 22 the next as mempool composition fluctuates). Others update in near-real-time. During a fast-moving congestion event, the smoothed wallet can look almost incompetently conservative. It isn't. It's optimizing for a different failure mode, and the smoothing is usually the right call for users who don't want to babysit a transaction.
A Calibration You Can Actually Do
If you want to understand where your wallet sits on this spectrum, pull up mempool.space's fee histogram during a period of moderate congestion. It shows the actual vbyte distribution of pending transactions by fee rate. Compare that visual to what your wallet is suggesting for next-block confirmation.
Where does your wallet land? If its suggestion sits at the very bottom of the next-block fee band, it's probably running a mempool-projection model with tight margins. If it's suggesting something that looks oddly low given the visible queue, it's likely drawing on historical data that hasn't caught up yet. Either way, you now have a diagnosis, not just a number.
No algorithm is universally superior here. Historical models are more stable over time; projection models are more responsive to sudden changes. The wallets that handle this best tend to combine both: mempool projection as the primary signal, historical confirmation rates as a sanity check, and a user-adjustable confirmation target on top. Anything less is one lens on an inherently uncertain problem. Treating any single wallet's estimate as authoritative during a congestion spike is exactly the kind of confidence the mempool will happily punish.