Choose a Bitcoin fee by deciding how urgent the payment is, reading the current mempool clearing price in satoshis per virtual byte (sat/vB), then picking a rate that matches both. Urgent payments target the next-block band; non-urgent payments can sit at the economy band and still confirm within a day. Confirmation is probabilistic, not timed.
Today's live fee snapshot (May 8, 2026)
As of May 8, 2026, mempool.space shows a calm network: the recommended next-block fee is 1 sat/vB while half-hour, hour, and economy all sit at 1 sat/vB, with the mempool holding about 49,300 unconfirmed transactions at roughly 179 MB out of the Bitcoin Core default 300 MB ceiling (source: Mempool.space). This is a quiet window: almost any fee at or above 3 sat/vB will clear in the next few blocks. A spike day looks very different; the rest of this guide teaches the choice logic that works in either regime.
This guide is written for retail users sending BTC from a self-custody wallet or withdrawing from an exchange who need to pick a fee rate with confidence, not guess. It does not cover miner block-template construction, Lightning channel fees, or altchain fee markets. Every protocol constant is cited; every volatile number carries a May 8, 2026 date-stamp.
What you will learn:
Why sat/vB is the number that matters, not total fee
How urgency should drive the sat/vB choice, not wallet labels
How to read mempool.space and match a band to a real decision
When a wallet preset is trustworthy and when it is stale
What to do when your fee was too low: wait, RBF, or CPFP
How to avoid the five fee mistakes that generate most support tickets
What number you are actually choosing: sat/vB
When a wallet asks you to set a Bitcoin fee, the knob is the fee rate, measured in satoshis per virtual byte (sat/vB). That number tells the network what you are offering per unit of block space your transaction consumes. Total fee is the result: sat/vB multiplied by transaction size in virtual bytes.
This matters because Bitcoin fees are not mainly driven by how much BTC you are sending. A 0.01 BTC payment from a single clean UTXO can confirm cheaper than a 0.001 BTC payment sweeping twenty small UTXOs, even though the second sends ten times less value. Miners auction off each block's 4-million-weight-unit capacity to the highest bidders by fee rate (source: GitHub), so the unit of competition is block space, not BTC amount.
Bitcoin Core's block-building algorithm confirms the mechanic directly. It "selects transactions in descending order of fee rate measured in satoshis per adjusted vsize" (source: Mempool.space). Pay a competitive sat/vB and your transaction gets near the front of the queue. Underpay and it sits. For the full transaction lifecycle this sits inside, see how bitcoin transactions work.
Why two equal payments can pay different fees
Two users sending 0.05 BTC on the same afternoon can pay different total fees because their transactions occupy different amounts of block space. Three factors drive virtual size:
Inputs: each UTXO you spend adds script data. One input is compact; twenty small inputs swell the transaction.
Outputs: each recipient and each change output adds data, though outputs are cheaper than inputs.
Address type: legacy P2PKH inputs are largest, nested SegWit (P2SH-wrapped) smaller, native SegWit (bc1q...) smaller still, Taproot (bc1p...) comparable to native SegWit for simple spends.
A 1-input, 2-output native SegWit transaction runs about 141 vB. A 20-input UTXO sweep can exceed 1,300 vB. At identical sat/vB, the second pays roughly ten times the total fee. UTXO hygiene matters more than estimator cleverness over the long run. For the primer, see UTXO management; for the address-type comparison, see legacy vs segwit vs taproot.
Start with urgency, not with the fee slider
The most useful question when choosing a fee is not "what is the cheapest rate I can get away with?" It is "how fast does this payment actually need to confirm?" A clean urgency frame makes every downstream choice easier.
Three urgency bands cover most retail sends:
Urgent: exchange deadline, time-sensitive payment, counterparty waiting. Target next-block inclusion.
Same-day: sending funds you want cleared today but there is no hard deadline. Target half-hour or hour band.
Low priority: consolidation, self-transfer, savings move, non-urgent bill. Target the economy band.
This framing protects against two common mistakes. The first is overpaying for sends that could wait. Users habitually pick the "priority" preset for every transaction and pay several times the rate they actually need. The second is underpaying on time-sensitive sends, where a stuck transaction turns a routine payment into a stressful afternoon.
Wallet estimators can improve the odds but cannot promise an exact confirmation time. Blocks do not arrive on a fixed timer. Bitcoin's 10-minute average is the mean of a probability distribution; single-block intervals of two minutes and forty minutes both occur regularly. When urgency truly matters, pay for it; when it does not, the economy band usually clears within a few hours. For the confirmation-count view of what happens after a transaction clears the mempool, see bitcoin confirmations.
From Blofin's deposit-engineering perspective, the asymmetry of urgency is the pattern worth internalizing: users rarely regret paying 2 sat/vB more on a transaction that mattered, but they often regret underpaying on one that got stuck. When we process outbound BTC movement internally, we weigh the wait-time cost against the fee delta explicitly rather than defaulting to the cheapest option. Retail users can mirror that discipline by asking "what would a six-hour delay on this cost me?" before picking a rate.
How to use mempool.space to pick a rate
A live estimator translates current network conditions into a practical sat/vB range. Mempool.space is the most widely used retail reference because it publishes both the fee-band recommendations and the raw mempool state they are derived from (source: Mempool.space).
Mempool.space calculates its four recommended bands as follows Mempool.space:
High Priority (next block): the median fee rate of transactions in the first mempool block
Medium Priority (half-hour): the average of the median fee rate of the first and second mempool blocks
Low Priority (one hour): the average of the medium-priority rate and the median of the third mempool block
No Priority (economy): either 2× the minimum relay fee or the low-priority rate, whichever is lower
The site explicitly warns its own estimates "do not guarantee transaction confirmation in any period of time," a useful reminder that even a live source is descriptive, not contractual.
A three-step method that works in any regime
Step 1: Open the recommended-fees widget and note all four bands. On May 8, 2026, the next-block bands read 0.2 to 1 sat/vB, a relatively calm snapshot with slight separation between priority and non-priority tiers (source: Mempool.space). During congestion these bands separate sharply: next-block might read 80 sat/vB while economy hangs at 6 sat/vB, which is the signal that patience is worth something.
Step 2: Check total mempool size and pending transaction count. A read under 150 MB and fewer than 40,000 pending is calm. A read above 250 MB or 150,000 pending is stressed; consider rescheduling non-urgent sends. The live 179 MB / 49,300 transaction snapshot on May 8, 2026 is mid-range calm.
Step 3: Match your urgency band to a live rate, add a small margin for propagation lag, and commit. If you are sending an urgent payment, pick the next-block rate or slightly above. For the same-day, pick the half-hour band. For low priority, the economy band is almost always sufficient.
Why estimators lag during regime shifts
Wallet fee estimators calibrate on recent block data and recent mempool trends. When network demand changes quickly (an inscription drop, exchange batching, coordinated on-chain activity), a wallet's model stays calibrated to pre-surge conditions for roughly 10 to 30 minutes before new data washes through. Users sending at the wallet's quoted rate during that window underpay relative to the live clearing price.
The defense is simple: open mempool.space in a browser tab during known-busy windows, compare your wallet's suggested rate against the live next-block band, and trust the live data when the two disagree by more than a factor of two. If your wallet is quoting 2 sat/vB for next-block when mempool.space shows 12 sat/vB, your wallet is behind and your transaction will likely get stuck.
For the broader retail deep-dive on fee pressure mechanics, see why are bitcoin fees so high; for the mempool concept itself, see Bitcoin mempool.
How wallet presets usually work (and when they don't)
Most beginner wallets do not ask for a raw sat/vB number. They present three presets, commonly labeled economy, standard, and priority, or slow, medium, fast. These labels are shortcuts, not universal specifications. One wallet's "standard" may target a different confirmation window than another wallet's "standard" because the two wallets use different estimators, different data sources, and different safety margins.
Bitcoin Core's own estimatesmartfee RPC gives wallets that use it a common backbone: it "estimates the approximate fee per kilobyte needed for a transaction to begin confirmation within conf_target blocks" using virtual transaction size per BIP-141 (source: Bitcoin Core). But wallets wrap this output in their own band labels, and not all wallets use Bitcoin Core's estimator; some pull from external APIs, some use their own node telemetry, some only present broad tiers without exposing the underlying sat/vB.
The practical read: presets are estimated urgency bands, not service levels. A priority preset can still confirm slower than advertised during a sudden surge, and an economy preset can sometimes clear within an hour if the mempool eases. Pair the preset with a live congestion view (mempool.space) when the payment is meaningful.
A wallet preset comparison you can actually use
When the mempool is calm (current next-block 3 sat/vB, other bands at 1 sat/vB), presets matter less because any reasonable rate confirms quickly. When the mempool is busy, these relationships hold in most retail wallets:
Preset | Usually targets | Typical sat/vB (calm) | Typical sat/vB (busy) | When to use |
|---|---|---|---|---|
Priority / Fast | Next block (10 min) | 1-5 | 40-150+ | Time-sensitive, deadline-bound |
Standard / Medium | Half-hour to hour | 1-3 | 15-50 | Same-day but no fixed deadline |
Economy / Slow | Within 6-24 hours | 1 | 5-20 | Low priority, self-transfers |
Custom | Whatever you set | Your choice | Your choice | When you are reading live data directly |
Numbers are indicative and shift with demand. The reliable rule is that your wallet's preset should be within a factor of two of mempool.space's equivalent band. Larger drift means one of them is stale.
What to do if your chosen fee was too low
A transaction whose fee rate is below the current clearing price is colloquially "stuck." It is valid, not cancelled, and sitting in at least one node's mempool waiting for either the clearing price to drop or user action to raise its effective rate. Three outcomes are available.
Option 1: Wait
If the transaction is not urgent and the rate is above the minimum relay fee, waiting is often the cleanest resolution. Mempool pressure oscillates with demand. A transaction broadcast at 5 sat/vB during a busy afternoon may sit five or six hours while the next-block band is at 20 sat/vB, then confirm overnight when exchange batching slows and the clearing rate drops. Most stuck retail transactions resolve by waiting.
One limit: Bitcoin Core nodes drop unconfirmed transactions after 336 hours (14 days) via the -mempoolexpiry default (source: GitHub). An expired transaction is not invalid; the UTXOs return to the sender's spendable balance and the wallet can rebroadcast at a higher rate.
Option 2: Replace-By-Fee (RBF)
RBF lets the sender broadcast a new version of the transaction at a higher fee. BIP-125 defines the rules (source: GitHub):
The original must signal replaceability (or the receiving node accepts full-RBF)
The replacement must pay a higher absolute fee than the original
The replacement must also cover its own bandwidth at or above the node's minimum relay fee, so a 500-byte replacement at 1 sat/byte minimum relay pays at least 500 satoshis more than the original
The replacement may not introduce new unconfirmed inputs
The total replaced-plus-evicted count must not exceed 100 transactions
In plain terms: RBF works when your wallet supports it, the original transaction was marked replaceable, and you bump the rate meaningfully (typically 25-50% above the current next-block band) to win re-inclusion.
Since Bitcoin Core 24.0.1 (December 2022), node operators have been able to set the -mempoolfullrbf option to accept replacement of any unconfirmed transaction regardless of BIP-125 signaling (source: GitHub). Full-RBF adoption has grown since, which also means a retail user often cannot rely on zero-confirmation transactions being safe for the recipient. Most modern self-custody wallets (Sparrow, Electrum, BlueWallet, Green, and Ledger/Trezor companions) sign RBF-signaling transactions by default.
Option 3: Child-Pays-For-Parent (CPFP)
CPFP works when RBF does not. Instead of replacing the stuck transaction, the sender (or recipient) spends one of its outputs in a new high-fee child transaction. Miners score parent-plus-child as a package, so the package rate can outbid the next-block band even when the parent alone cannot. CPFP requires someone to control at least one output, either a change output the sender still owns or the recipient's own output.
CPFP has limits. If the parent is very large in vbytes and the child is small, a practical child fee may not drag the package rate into the next-block band. CPFP is also only useful when an output is actually spendable; outputs locked under timelocks or custodial control cannot be used.
The decision tree
Is the transaction urgent?
├── NO → Wait. Rates usually drop within 6-24 hours. If it never confirms in 14 days,
│ rebroadcast at a higher rate.
└── YES → Does the wallet show the original as replaceable (RBF signaled, or full-RBF node)?
├── YES → Bump with RBF to 25-50% above the current next-block band
└── NO → Do you or the recipient control an output of the stuck transaction?
├── YES → Use CPFP so the package rate reaches the next-block band
└── NO → Wait for congestion to clear, or contact the sending service
(custodial exchange, payment processor) for their policy
For the detailed comparison of replacement paths, see RBF vs CPFP; for the full stuck-transaction triage checklist, see why is my bitcoin transaction stuck.
Common mistakes when choosing Bitcoin fees
Five mistakes generate most retail "why did this go wrong" support tickets. Each is easy to avoid once named.
Mistake 1: Optimizing total fee instead of fee rate
Users focused on the dollar amount at the bottom of the wallet screen underprice during congestion because they are not comparing sat/vB against current bands. Miners do not care about total fee; they sort by rate. A "cheap" 1-sat/vB transaction during a 40-sat/vB surge will sit, regardless of how many BTC it sends.
Mistake 2: Treating wallet presets as promises
Economy, standard, and priority are approximations. They can all underpay during a regime shift because the underlying estimator has not caught up. When the payment matters, cross-check against mempool.space before confirming.
Mistake 3: Ignoring transaction size
A clean 1-input send at 5 sat/vB costs 700 satoshis. A 20-input UTXO sweep at the same 5 sat/vB costs closer to 7,000 satoshis. Users who never consolidate their wallet during a quiet period pay the penalty every time they send. Consolidate UTXOs when fees are at 1-2 sat/vB; save meaningfully during any future surge.
Mistake 4: Always picking "priority"
Habitual priority users pay three to five times what they need for transactions that would have cleared economy within hours. If the send is not actually urgent, economy usually works, and the savings over a year of retail sends are real.
Mistake 5: Rushing the send itself
Before trying to save 100 satoshis on a fee, verify the address, the amount, and the network. A correctly-priced transaction sent to the wrong address is irreversible; an over-priced transaction sent to the correct address is a minor rounding error. Get the send right first, then tune the fee. For the step-through of the send flow, see how to send bitcoins; for the broader safety checklist, see bitcoin security checklist.
Frequently asked questions
Is sat/vB the same as the total Bitcoin fee?
No. Sat/vB is the fee rate, meaning how much you pay per virtual byte of transaction size. Total fee is the rate applied to the actual size of the transaction. Two transactions at the same sat/vB can pay different totals if one uses more vbytes because it has more inputs, more outputs, or a less efficient address type. Miners compare rates, not totals, which is why a small high-rate transaction confirms faster than a large low-rate one, even when the second pays more absolute satoshis.
Is mempool.space always accurate for choosing a fee?
No live estimator is exact. Mempool.space publishes its methodology openly: high priority is the median rate of the first mempool block, medium is an average across the first two mempool blocks, and so on (source: Mempool.space). The site itself warns its estimates do not guarantee confirmation in any specific window. Treat it as the best available decision aid, combined with your own urgency assessment and a small safety margin for propagation and regime shifts.
Should I always use the priority fee option?
Not usually. Priority makes sense when the payment is actually time-sensitive, but using it for every transaction typically means paying two to five times what the send required. Match the preset to the use case: priority for deadlines, standard for same-day, economy for consolidation and non-urgent transfers. Paying more improves the odds of fast inclusion but never creates a guaranteed confirmation deadline.
What if my Bitcoin fee was too low?
If the transaction is unconfirmed and actually needs to be cleared, three options apply. Wait if the payment is not urgent; mempool pressure cycles and most stuck transactions clear within a day. Use Replace-By-Fee if your wallet signaled replaceability or your receiving node supports full-RBF, since BIP-125 requires a higher absolute fee and coverage of the replacement's own bandwidth. Use Child-Pays-For-Parent if you or the recipient controls an output of the stuck transaction; miners score the parent-plus-child package fee jointly.
Why do fee estimates change so fast during busy periods?
Fee estimates move quickly because the mempool is not static. New transactions enter constantly, users raise their bids in response to delays, and block discovery follows a probability distribution rather than a fixed timer. During calm periods rates look stable. During an inscription drop or coordinated batching event, the competitive rate can double or triple within thirty minutes. Estimators calibrated on the prior half-hour of data lag briefly during these transitions, which is why cross-checking a wallet preset against a live source matters most when fees are moving.
What is the minimum relay fee and why does it matter?
Bitcoin Core's default minimum relay fee is 1 sat/vB. Transactions below this are not accepted into the mempool or relayed to peers. When the mempool approaches its 300 MB cap, Bitcoin Core raises the dynamic minimum relay fee to evict low-rate traffic, which means a transaction broadcast at 1 sat/vB during a surge may never propagate past the first node that receives it (source: GitHub). The transaction is valid, just effectively invisible to most of the network until the surge clears.
Does paying a higher fee guarantee faster confirmation?
No. A higher sat/vB improves the probability of next-block inclusion but cannot override block timing. Blocks average 10 minutes with substantial variance, and single-block intervals of two minutes and forty minutes both occur regularly. Paying above the live next-block band increases the chance of inclusion in the first mined block after broadcast, but that block itself might take 30 minutes to arrive. Treat confirmation speed as probabilistic and match the fee to urgency, not to a fixed countdown.
Can I cancel a Bitcoin transaction once I have broadcast it?
No, not cleanly. RBF lets you replace an unconfirmed transaction with a new version paying a different fee, but the replacement is a new commitment to the network and cannot undo the original broadcast. If the replacement includes different outputs (sending to yourself rather than the original recipient), it functionally reroutes the funds. Once any version is confirmed in a block, it is final. Verify address, amount, and network before signing; fee tuning is a separate, recoverable decision.
Glossary
Adjusted vsize: Bitcoin Core's block-selection metric combining raw vbytes with sigop weight; "5 times the number of sigops, or the unadjusted vsize, whichever is larger"
BIP-125: the Bitcoin Improvement Proposal defining opt-in Replace-By-Fee signaling and replacement rules
BIP-141: the SegWit proposal defining the 4-million-weight-unit block cap and witness-data discount
CPFP (Child-Pays-For-Parent): accelerating a stuck transaction by spending one of its outputs in a high-fee child transaction so miners score the package favorably
Economy band: mempool.space's lowest recommended band, targeted at confirmation within several hours to a day
Fee rate: satoshis per virtual byte (sat/vB); the number miners compare when building blocks
Full-RBF: a node policy (Bitcoin Core 24.0.1+) that accepts replacement of any unconfirmed transaction regardless of BIP-125 opt-in signaling
Minimum relay fee: the lowest fee rate a Bitcoin Core node will accept and relay; default 1 sat/vB
Next-block band: mempool.space's high-priority band, the median rate of transactions in the first mempool block
RBF (Replace-By-Fee): replacing an unconfirmed transaction with a higher-fee version; rules defined in BIP-125
sat/vB: satoshis per virtual byte; the fee rate unit most wallets and estimators use
Virtual byte (vB): size measurement accounting for the SegWit witness discount; 1 vB = 4 weight units of non-witness data or 1 weight unit of witness data
Weight unit (WU): the raw per-block capacity unit; 4 million WU per block under BIP-141
Researched and written by the BloFin Academy editorial team with AI-assisted drafting. Factual claims independently verified against BIP-141, BIP-125, Bitcoin Core documentation at github.com/bitcoin/bitcoin (including reduce-memory.md, mempool_options.h, and the 24.0.1 release notes), the mempool.space FAQ and live dashboard (snapshot 2026-04-16), the estimatesmartfee RPC reference at bitcoincore.org, Bitcoin Optech's RBF reference at bitcoinops.org, and Blockchain.com subsidy data.
Disclaimer: This content is for educational purposes only and does not constitute financial, investment, legal, or tax advice. Crypto assets are highly volatile and carry significant risk of loss. Always verify local regulations and consult a qualified professional before making financial decisions.