BTCFees

BTCFees Review

BTCFees Review Guide (fees.truelevel.io): Everything You Need to Know + FAQ

Ever looked at your wallet and thought, “How many sats per vB should I pay so I don’t get stuck—or burn money?” I’ve been there. Fees can swing 10x in a day, and guessing turns into either overpaying or waiting forever.

In this guide, I’ll show you how I use BTCFees to pick the right fee in under a minute. No fluff—just what to look at, what to ignore, and how to send smarter today.

“Pay enough to get in. Not a sat more.” That’s the goal.

Real talk: fees are a market. When demand spikes, you’re bidding against everyone else. During Runes/inscriptions peaks (think April 2024 around the halving), next-block fees blasted past 300–600 sat/vB and blocks earned dozens of BTC in fees. On calm weekend hours, sub-10 sat/vB has been common. Same network. Same rules. Totally different costs. Your job is to read the moment—and pay accordingly.

The real fee problems Bitcoin users face

Most of the pain comes from a few recurring traps:

Fees spike without warning, and you overpay. You see 80 sat/vB in your wallet, panic, and set 120 “to be safe,” even though the next block clears at 70. That extra 50 sat/vB on a 200 vB transaction is 10,000 sats wasted—every send.

Underbidding gets you stuck. You set 8 sat/vB because it worked last weekend, but today the mempool floor is 25. Now you wait hours or days, refreshing explorers and regretting everything.

Wallet estimators vary wildly. Some are conservative, others lag behind reality, and a few don’t show the recent block floors at all. You’re guessing in the dark.

Terminology trips people up. Even experienced users mix up sats/byte vs sat/vB, or don’t factor in transaction size. A 1-input, 2-output Taproot send can be ~120–160 vB; a multi-input legacy send can be 400–700 vB+. Same sat/vB, totally different total fee.

If any of that sounds familiar, you’re exactly who I’m writing this for.

What I promise in this guide

A simple process to pick the right sat/vB on BTCFees in under 60 seconds.

Plain-English explanations of the only metrics you actually need.

Timing tactics to save money without risking long delays (yes, weekends often help—but I’ll show you how to confirm it live).

Battle-tested playbooks for stuck transactions (RBF/CPFP) and for batching payments so you pay less over time.

Here’s the kind of clarity you’ll get:

“I need next block.” Pay the current next-block suggestion, add a small cushion if pressure is rising, and keep the transaction small (SegWit/Taproot) to cap your total sats.

“I’m fine with ~1 hour.” Match the mid-range band and avoid bidding below recent block floors. If it stalls, bump via RBF once.

“I’m patient.” Choose economy, send during low-traffic windows, and be ready to bump if demand picks up.

Who this is for and how to use this review

Beginnerswho want a crisp, friendly walkthrough without jargon.

Power users who want a fast checklist before every send.

Anyone who’s tired of paying “just to be safe” and wants a method that works when fees are 5 sat/vB or 500 sat/vB.

What you’ll find here:

Quick how-to for choosing the right fee band based on urgency.

FAQs with straight answers to the most-searched fee questions.

Pro tactics like batching, UTXO consolidation timing, and when to lean on Lightning.

Direct link to the tool I’ll reference throughout: BTCFees.

Before we jump into the method, here’s a quick sanity check with real numbers so the rest clicks instantly:

Example 1: 150 vB Taproot send at 20 sat/vB = 3,000 sats. If next-block is 40 sat/vB and you truly need speed, waiting might cost you more in time than the extra 3,000 sats. Pay 40, move on.

Example 2: 500 vB legacy send at 80 sat/vB = 40,000 sats. If the mempool is easing and the last few blocks are clearing at 50–60, dropping to 60 saves ~10,000 sats without adding much risk.

Ready to stop guessing and start sending with confidence? Perfect—next, I’ll show you exactly what BTCFees is and why I reach for it first when fees are moving fast. Curious what makes it different from busy explorers and laggy wallet estimates?

What is BTCFees (fees.truelevel.io) and why I use it

I reach for BTCFees when I want a clean, no-BS answer to one question: what should I pay right now? It’s a Bitcoin fee estimator and mempool analytics page that keeps the signal and throws out the noise. No clutter, no hunting for numbers under a pile of toggles—just real-time fee bands, current mempool pressure, and the recent block floors that actually influence your confirmation time.

“Pay for speed when you need it. Pay for patience when you have it.”

That’s how I treat fees. BTCFees makes that mindset effortless. It shows exactly how crowded the mempool is and sets clear fee targets for different urgency levels, so I can pick a sat/vB in seconds and stop second-guessing. When fees heat up (think market volatility or inscription surges), I glance at the pressures and decide: do I send now, or wait for a cheaper window?

For context, fee patterns really do cycle. Public mempool data (see mempool.space and Bitcoin Optech’s fee estimation topic) consistently shows waves: busy weekday peaks, calmer off-peak windows. BTCFees surfaces that reality in a way that’s quick to act on, not just interesting to look at.

Who’s behind it and what it focuses on

BTCFees is built by TrueLevel, and it pulls live mempool data to model likely confirmation targets across fee tiers. The focus is simple: a readable estimator with the essentials up front. It’s not trying to be a full block explorer or a deep analytics dashboard. The goal here is speed-to-decision—give me the sat/vB ranges and the mempool temperature right now, and let me move on with my send.

That product choice matters. Wallets often have built-in estimators, but they can lag or hide the context you actually need. BTCFees puts that context front and center, so I can trust the number I’m about to type in my wallet’s custom fee field.

What’s on the main screen

When I load BTCFees, I see exactly what I care about in one quick glance:

Suggested fees by priority: clear bands like “next block,” “~30–60 minutes,” and “economy.” You’ll typically see a range, not a single number—because fees are a moving market.

Mempool backlog pressure: a current read on how crowded things are, so you know if low bids are risky or if the mempool is easing.

Recent block fee ranges: the actual floors miners just accepted. This is the sanity check that helps you avoid bidding below what recently made it into blocks.

Here’s how that looks in practice. On a busy weekday, I might see something like:

Next block: 35–45 sat/vB

~30–60 minutes: 18–25 sat/vB

Economy: 8–12 sat/vB

If the backlog indicator is heating up and recent block floors are creeping higher, I know to either pay the higher tier or wait. On the other hand, late-night UTC or weekend reads often show those bands sliding down—exactly when I prefer to batch or consolidate UTXOs. These patterns line up with the behavior you can observe on public mempool charts and in historical fee analyses referenced by Optech.

What makes it different from other fee tools

Plenty of fee tools exist, but this one gets the “what should I do now?” dilemma right. Here’s why I like it:

Fast to read: minimal UI, the key numbers up front, and sensible priority tiers.

No overwhelm: fewer knobs to fiddle with, which means fewer chances to misread the market.

Grounded in recent blocks: shows the real floors that just cleared, so you don’t aim below reality when time matters.

Snappy and practical: I can glance, decide, and paste a fee into my wallet in under a minute.

During those 2023–2024 waves when inscriptions and market moves sent fees sky-high, being able to see fee bands alongside recent block acceptance ranges saved me from both overpaying and underbidding. When the mempool was climbing, I paid the right premium. When it cooled off, I caught cheaper windows with confidence. That’s exactly the job a good estimator should do.

Curious how I translate those panels into a precise sat/vB number without overpaying—or waiting all day? In the next section, I’ll show you the exact 60-second process I use, step by step. Ready to make your next send smarter?

How to read BTCFees and choose the right sat/vB

If you’ve ever watched a payment sit for hours while newer transactions leapfrog yours, you know that fee FOMO is real. The cure is a fast, repeatable way to match your urgency to the market right now—without overpaying. That’s exactly how I use BTCFees (fees.truelevel.io) in under a minute.

“The right fee isn’t the highest number on the screen—it’s the lowest price that still matches your patience.”

Step-by-step: pick a fee in under a minute

I keep this checklist open whenever I’m sending. It’s simple, fast, and it works in volatile fee hours.

Pick your target: are you aiming for the next block, roughly 30–60 minutes, or “as cheap as possible” later today?

Open BTCFees and look at the suggested sat/vB for your target. That’s your starting number, not the final bid.

Glance at recent block minimums. If the last few blocks show a higher floor than your target, bump your bid slightly or expect to wait.

Check mempool pressure. If pressure is rising (thicker higher-fee bands, higher suggested next-block fee), add a small cushion. If it’s easing, you can shave a few sats.

Set a custom fee in your wallet (sat/vB). Confirm your transaction size in vBytes if your wallet shows it.

Send with RBF enabled so you can bump later if needed—no stress.

Real example (fast)

BTCFees shows: Next block: 45 sat/vB, 30–60 min: 24 sat/vB, Economy: 14 sat/vB. Recent block floors hover around 42–44 sat/vB.

If I need speed, I’ll set 47–50 sat/vB to avoid getting edged out by last-second bids.

If I can wait ~1 hour, I’ll choose 24–26 sat/vB only if the recent floors are slackening. If they’re stubborn at 40+, I either wait or pick ~28–30 as a compromise.

What does that cost in sats?

Typical sizes: Taproot (P2TR) ~110 vB, SegWit (P2WPKH) ~141 vB, Legacy (P2PKH) ~225 vB for a 1-in/2-out spend (you + change).

At 25 sat/vB: P2TR ≈ 2,750 sats, P2WPKH ≈ 3,525 sats, Legacy ≈ 5,625 sats.

This is why using SegWit/Taproot matters—same sat/vB, smaller vBytes, less total fee.

Key terms you’ll see (fast definitions)

sat/vB: The price per virtual byte you bid for block space. This is the one number you actually set.

vBytes (vB): The adjusted size of your transaction. Bigger transactions (more inputs, older formats) cost more at the same sat/vB.

Mempool backlog: All pending transactions waiting to be confirmed, grouped by fee levels. More backlog at higher fees = tougher competition.

Reading the mempool pressure and fee bands

BTCFees makes the current fee market feel less like a guessing game. Here’s how I read it at a glance:

Thick, stacked high-fee bands = caution. If most of the mempool sits above your target, low bids tend to stall. Either raise your bid or be comfortable waiting longer.

Thin, slipping bands = opportunity. When fee bands are thinning and recent block floors tick down, I get more aggressive about paying less.

Recent block minimums are your guardrails. If the last few blocks included a minimum of, say, 40 sat/vB, bidding 20 sat/vB for “fast” is magical thinking. Match reality or accept the wait.

Rising pressure? Add a small cushion. If the next-block suggestion just climbed and high-fee layers are fattening, a +5–10% bump can save you from an RBF later.

Easing pressure? Shave a few sats. If things are cooling, I’ll trim 1–3 sat/vB below the suggestion—still above the recent floor—to avoid overpaying.

Why this works

Fees are a simple market: more demand pushes sat/vB up, less demand pulls it down. You’re just choosing the right lane based on how crowded it is right now. Historical mempool data backs this up—fee layers expand and contract in waves, and timing your bid with those waves reduces costs without risking long stalls. If you’re curious, the layered backlog view at Jochen Hoenicke’s mempool charts visualizes these waves with years of data.

Quick sanity checks I do before clicking send

Is my bid above the recent block floor for my urgency?

Is the mempool showing rising or easing pressure in the last few blocks?

Does my wallet confirm the sat/vB unit (not sat/byte) and show the estimated vB size?

Is RBF enabled so I can bump if reality changes?

Now that you can read BTCFees without second-guessing, want the fast answers to the questions everyone asks—like why fees spike, the best time to send, and what to do if you bid too low? Keep going; the next section has the no-fluff answers you’ve been looking for.

Smart fee strategies using BTCFees

Here’s the playbook I actually use when fees are moving fast and my wallet balance is too precious to waste. BTCFees (fees.truelevel.io) gives me real-time fee bands and block floors; I match that to my urgency and set the right sat/vB without guessing.

“Overpaying every time is a tax on impatience. Underpaying without a plan is a tax on nerves.”

ASAP confirmation (next block)

When I need speed, I treat the suggested “next block” band as my baseline and check whether the mempool is heating up.

Check the top band: If BTCFees shows Next Block = 40–45 sat/vB and recent blocks are including minimums around 38 sat/vB, I’ll usually set 46–48 sat/vB for a cushion.

Watch the momentum: If the band just ticked up twice in 5–10 minutes, I add a couple extra sats per vB. If it’s flat or easing, I stick close to the top of the range.

Keep the transaction lean: Use SegWit or Taproot addresses and avoid pulling in extra small inputs. Smaller vBytes = less total cost.

Set RBF: Always enable Replace-By-Fee so you can nudge it up if the next block fills with whales.

Real example: A ~180 vB SegWit send at 48 sat/vB costs 8,640 sats. If I’d set 60 “just to be safe,” I’d pay 10,800 sats for no extra benefit. That’s a 25% tip to miners I didn’t need to leave.

Within an hour (balanced)

This is where most people overpay. I go for the mid target, but I refuse to underbid what recent blocks are actually taking.

Use the mid band: If BTCFees shows 30–60 minutes = 16–22 sat/vB, I’ll pick 18–20 sat/vB when the backlog is steady or falling.

Respect the floor: If the recent block minimums are sitting near 20 sat/vB, I won’t set 15 and hope. I’ll set 20 and avoid limbo.

Have a bump plan: If it misses my target window, I RBF to the next tier (e.g., 20 → 28 sat/vB) to skip the queue, not crawl through it.

Quick math: On a 200 vB tx, 20 sat/vB is 4,000 sats. Bumping once to 28 costs 1,600 more sats—not great, but still cheaper than panic-setting 40 from the start.

Cheapest possible (you can wait)

When cost matters more than clock time, I let BTCFees guide me to the lowest viable band and I time the send for off-peak hours.

Pick “economy” and add patience: If the economy band is 4–7 sat/vB, I choose 5–6 sat/vB and send during late night UTC or weekends when demand tends to be lower. Multiple fee trackers have shown those windows often bring softer floors.

Expect variance: If the mempool thins out, I look like a genius. If it suddenly fills (market news, inscriptions, exchange maintenance), I RBF up to 8–10 sat/vB and move on.

Know the timeout: Many nodes expire unconfirmed transactions after about 336 hours (≈14 days). I don’t cut it that close—if it’s stuck longer than I’m comfortable with, I bump or use CPFP from a change output.

Real example: A 160 vB Taproot send at 6 sat/vB costs 960 sats. If I catch a quiet Sunday and the next three blocks include at 5–7 sat/vB, I win. If it spikes, a bump to 10 sat/vB still keeps the total under 1,600 sats.

Batch sending and timing patterns

Batching is the unsung hero of fee savings. One transaction, many outputs, way lower per-payment cost.

Batch whenever possible: Adding an extra SegWit output is roughly ~31 vB, while a fresh standalone payment would be well over 100 vB. That’s why batching multiple payouts in one tx often saves 40–70% per recipient.

Example: Three separate P2WPKH payments (≈140–180 vB each) at 20 sat/vB might cost ~9,000–10,000 sats total. A single batched tx with three outputs might land around 250–300 vB at the same rate—roughly 5,000–6,000 sats. Same money moved; fewer sats burned.

Time your batches: I plan these for late-night UTC or weekends if the economy band looks soft on BTCFees. If the tool shows a building backlog, I wait a few hours. If two fee checks disagree, I set RBF and proceed.

One last thing: fee patterns tend to ebb and flow weekly. Watching BTCFees for a few minutes before you send often reveals a better window right around the corner. And if you batch, those windows really pay off.

Now, here’s the question that always comes up: how much can you trust these numbers—and what’s the safest way to use them without risking your coins? Let’s look at that next.

Accuracy, trust, and safety: what you should know

I use BTCFees (fees.truelevel.io) because it’s fast and honest about what fee picking really is: a probability game. You’re reading a snapshot of a moving market. That’s useful—if you know what you’re looking at and how to protect yourself when the market moves against you.

“Set a fee that gets you in, but never a satoshi more.”

Data approach and what estimates mean

BTCFees looks at the live mempool and recent blocks to suggest fee bands (like “next block” or “~1 hour”). Those numbers are probabilistic—they’re based on what just happened and what’s currently waiting, not a crystal ball.

Miners typically prioritize by feerate (sat/vB), with exceptions for things like CPFP chains. That’s not my opinion—that’s how Bitcoin works and is documented in sources like Mastering Bitcoin. Bitcoin Core’s own estimator tracks confirmation success rates across targets, which is a good mental model for any estimator you use (Bitcoin Core estimatesmartfee).

Here’s how I read BTCFees accurately in the wild:

Look at recent block floors. If the last few blocks had minimums around 40 sat/vB, and BTCFees says “~1 hour” at 22–28 sat/vB, that’s a bet that pressure is easing. If you can’t risk waiting, don’t bid below that recent floor.

Watch momentum, not only the number. If the mempool shows a growing backlog at ≥35 sat/vB, a 25 sat/vB bid can quietly sink for hours. Thin, shrinking fee bands? That’s your green light to go cheaper.

Treat spikes as weather alerts. I’ve seen next-block jump from ~30 to ~90 sat/vB within 15 minutes when inscriptions kicked up activity (a pattern noted widely by fee dashboards in 2023–2024). In those moments, add a cushion or enable RBF and wait it out.

Quick sample, so the math feels real:

Transaction size: 180 vB (a lean SegWit spend)

Fast window: 35 sat/vB → total fee 6,300 sats

Calmer window: 15 sat/vB → total fee 2,700 sats

That’s a 3,600 sat difference—0.000036 BTC. At $60k/BTC, it’s roughly $2.16 saved for a small tx. Scale that across dozens of sends, and it’s not pocket change anymore.

Bottom line: BTCFees is excellent at showing current fee pressure and realistic near-term targets. It’s not a guarantee for what the market will be in 20 minutes if a rush hits. That’s why I always pair estimates with control features in my wallet.

Is BTCFees safe to use?

Short answer: yes. It’s a read-only fee dashboard. You don’t connect a wallet, you don’t sign anything, and you never paste keys.

No keys, no connection. You’re viewing public mempool data and suggested fees. That’s it.

Standard web hygiene. Use the correct URL: fees.truelevel.io/#/btc. Bookmark it. Avoid typosquats and “accelerator” pop-ups on other sites that promise miracles.

Pair with wallet controls. Enable RBF (Replace-By-Fee) in your wallet so you can bump if conditions shift. If RBF isn’t possible, keep CPFP in your back pocket.

Privacy basics. Like any website, it sees your IP and browser info. If that matters to you, use a privacy-friendly browser/VPN. You still never expose wallet secrets.

The real “risk.” It’s not theft; it’s timing. If you misread the market, you might overpay or wait too long. The antidote is simple: RBF on, and don’t bid below recent block floors when timing matters.

If you’re the cautious type (same), cross-check with one other reputable estimator before a big send. When two tools align, I send with confidence. When they disagree, I either set RBF and proceed or wait for clarity.

Mobile and accessibility notes

I check fees on my phone constantly, usually during off-peak hours. A few small tips:

Bookmark the BTC page. Go straight to fees.truelevel.io/#/btc for one-tap checks.

Rotate for clarity. Landscape mode makes the fee bands and recent block ranges easier to read on smaller screens.

Color-blind friendly habit. Don’t rely only on color gradients. Read the numeric sat/vB labels and the recent block minimums.

Low bandwidth days. If your connection is flaky, give it a second to load the charts before you choose; you want fresh data, not stale cache.

The emotional truth? Overpaying by 2–3x stings. Getting stuck for half a day is worse. BTCFees helps you avoid both—if you respect that it’s a live market, not a promise.

Ready to turn “probabilities” into an actual edge—saving sats repeatedly without stress? Up next, I’m going to show you the exact tweaks I use in my wallets to cut vBytes, enable fee-bumps on autopilot, and avoid the three most expensive mistakes I see every week. Which one are you making right now?

Pro tips: get more from your fee planning

Fees don’t have to feel like a slot machine. A few smart habits compound into real savings, especially if you send often. Here’s how I squeeze more out of every sat without getting stuck or stressed.

“The cheapest fee is the one you don’t pay twice.”

Map your wallet type to fee math

Your address type and UTXO layout massively change what you pay. Same money moved, very different bill.

Upgrade addresses: Moving from Legacy (1...) to SegWit (bc1q...) or Taproot (bc1p...) slashes the size of your transaction in vBytes. Smaller tx = fewer sats burned.

Know the rough sizes:
- Legacy input ≈ 148 vB
- SegWit (P2WPKH) input ≈ 68 vB
- Taproot (P2TR) input ≈ 58 vB
- Outputs: P2WPKH ≈ 31 vB, Legacy ≈ 34 vB, Taproot ≈ 43 vB

Real example at 30 sat/vB (2 inputs, 2 outputs):
- Legacy: ~374 vB × 30 = 11,220 sats
- SegWit: ~208 vB × 30 = 6,240 sats
- Taproot: ~212 vB × 30 = 6,360 sats
That’s ~45% savings by just using modern addresses.

Inputs cost you the most: Every extra input is like strapping a brick to your fee. Ten tiny UTXOs? You’re paying 10× the input cost.

Consolidate UTXOs during cheap windows: Merge your dust when the mempool is quiet so later transactions use fewer inputs.
- Example: Each extra P2WPKH input ≈ 68 vB. At 30 sat/vB, that’s ~2,040 sats per input. Consolidate the same input at 2 sat/vB and it’s ~136 sats. 15× cheaper.

Tip: I keep an eye on fee softness using BTCFees and run consolidation sends when the economy band hits rock bottom.

Use RBF and CPFP like a pro

When the mempool turns, control beats hope. Two tools matter: Replace-By-Fee (RBF) and Child-Pays-For-Parent (CPFP).

Always enable RBF: Most good wallets have a “Replaceable” or “Bump fee” option. Turn it on before you send.

How I bump with RBF:
- I check the “next block” suggestion on BTCFees.
- If the mempool is heating up, I add a tiny cushion (+2–5 sat/vB) to avoid rebumping.
- Example: I sent at 12 sat/vB, but the floor climbs. I replace at 24 sat/vB and it confirms in the next block. I pay once, not twice—in time and anxiety.

CPFP when RBF isn’t possible: No RBF? Spend a change output from the stuck parent with a high-fee child so miners include the package.
- Example: Parent is 8 sat/vB and stuck. I have a 50k-sat change UTXO. I create a child tx (e.g., pay myself) with a strong fee so the combined parent+child is attractive. Miners see the total fee, not your tears.
- Note: You need a spendable change output from that parent to do CPFP.

Pro move: If fees are spiking fast, RBF straight to the next-block target; leapfrog the middle band and save yourself another bump.

Avoid common mistakes

Don’t reuse yesterday’s fee: The market changes by the hour. Always check live conditions before hitting send.

Don’t underbid block floors when you’re in a hurry: If recent blocks are clearing at 25–30 sat/vB, a 12 sat/vB “hope bid” just parks your tx.

Mind the units: Set fees in sat/vB. Some older docs say sat/byte; modern wallets use virtual bytes. If your wallet looks ambiguous, assume vB or confirm in settings.

Keep transactions lean: Each added input/output is literal money. Combine payments when it makes sense and avoid tiny dust outputs you’ll pay to move later.

According to long-running community guidance (see Bitcoin Optech and core wallet docs), consistent wins come from three habits: modern address formats, UTXO hygiene, and fee control (RBF/CPFP). It’s boring. It also works.

Lightning and off-chain where it makes sense

On-chain is settlement-grade. Lightning is for speed and small/frequent payments. Use both intelligently.

Small or frequent payments: Lightning often costs only a few sats and confirms instantly. For a $5 tip, paying a 4,000-sat on-chain fee makes zero sense.

Consider the full lifecycle: Opening/closing a channel is on-chain. If you’ll make dozens of small payments, the amortized cost still favors Lightning.

Large transfers and finality: On-chain still rules for big, infrequent moves. Pair it with SegWit/Taproot and smart timing to keep costs sane.

Rule of thumb: If your on-chain fee approaches or exceeds 1–2% of the amount you’re sending—and you don’t need settlement-level finality—Lightning is likely the better route.

One more thought: Fees are a market. Markets reward the prepared. Build your routine now and your future self keeps more sats, every week.

Curious which fee tool I cross-check before big sends—and when I ignore it? In the next part, I’m comparing my go-to, BTCFees, with mempool.space and a couple of classics. Which one should you trust when they disagree?

BTCFees vs alternatives: what I recommend

I’m a fan of quick, confident fee picks. BTCFees gives me that. But I still cross-check with a couple of classics when the mempool looks chaotic or I’m about to send a high-value transaction. Here’s how each tool earns its spot in my workflow and the exact moments I reach for them.

mempool.space fee estimator

mempool.space is my go-to for richer context. It shows upcoming blocks with fee floors, how miners are likely to fill blocks, and the spread of fee-paying transactions waiting in line. When I need to understand the why behind a number, this is where I look.

What I watch: the “Next block” and “Projected blocks” fee floors. If I see the lower bound creeping up block by block, I’ll add a small cushion to the fee I got from BTCFees.

When it shines: during fast-changing markets. If BTC is ripping and fees are climbing, mempool.space shows that slope clearly so I don’t underbid by 2–3 blocks.

Example: during the post-halving Runes surge in April 2024, mempool.space made it obvious when blocks were being packed with 300–600 sat/vB transactions. BTCFees got me a number fast; mempool.space told me how “hot” the next few blocks really were.

Quick read: If “Next block” says 35–40 sat/vB and the next two projected blocks show 32–38 sat/vB and 30–35 sat/vB, I’ll set 38–40 sat/vB for speed, or 32–34 sat/vB if I’m okay with one extra block of wait.

Jochen Hoenicke’s mempool (queue)

Jochen Hoenicke’s mempool (queue) is the original backlog heatmap. It stacks the mempool by fee bands over selectable time ranges, letting you spot trends at a glance—are low-fee layers shrinking, growing, or staying flat?

What I watch: slope and thickness of the bands between 1–50 sat/vB. A thinning low-fee layer is my cue to send cheap and be patient.

When it shines: timing budget-friendly sends. If the 5–15 sat/vB layers are shrinking over a few hours, I’ll post an economy fee with RBF and wait it out.

Example: on a quiet Sunday UTC, I saw the 10–20 sat/vB band melt away across six hours. I set 12 sat/vB with RBF and confirmed in ~3 blocks without bumping.

Pattern tip: A big, flat “shelf” between 20–40 sat/vB often means competition in that range. I either jump slightly above it for speed or drift below with patience and RBF enabled.

Bitcoiner.live fee estimator

Bitcoiner.live is a clean, no-fuss estimator with target windows and suggested sat/vB. It’s excellent as a second opinion because it tends to give pragmatic, “don’t overthink it” numbers.

What I watch: the “next block,” “30 minutes,” and “60 minutes” suggestions. If they line up with BTCFees within a few sat/vB, I’m comfortable sending.

When it shines: during moderate congestion where the market isn’t whipsawing. It often matches my actual outcomes closely in those conditions.

Example: BTCFees suggested 28 sat/vB for ~1 hour; Bitcoiner.live showed 25–27 sat/vB for 30–60 minutes. I set 28 sat/vB with RBF and landed in two blocks.

How I compare them

My routine is simple and keeps me from guessing:

Step 1: Get a fast read on BTCFees for my target (next block, ~1 hour, or economy).

Step 2: Cross-check with mempool.space for block-by-block floors and trend direction.

Step 3: Sanity check the number on Bitcoiner.live. If it’s close, I’m done. If it’s off, I enable RBF and plan to bump if needed.

Rules I follow without thinking about it:

If two tools agree within ~10–15%: I send with that fee.

If they disagree by a lot: I wait 10–20 minutes, refresh, or send with RBF and a modest cushion above the lowest estimate.

If mempool.space shows a rising floor: I add a few sat/vB to the BTCFees suggestion if I need speed.

If Jochen’s chart shows thinning low-fee layers: I take the economy lane with RBF and let time work for me.

Real-world moments where this saved me:

Runes/inscription surges: I’ve seen BTCFees call 200–250 sat/vB for next block while mempool.space showed the floor climbing into the 300s. I paid 310 sat/vB, landed in the next block, and avoided the bumping spiral.

Weekend troughs: BTCFees said 14 sat/vB for ~1 hour; Bitcoiner.live said 12–13 sat/vB; Jochen’s low-fee layers were thinning. I went 13 sat/vB and confirmed in ~2 blocks.

The point isn’t to obsess over tiny differences—it’s to build confidence in the fee you pick right now. Cross-checking with one extra tool takes 20 seconds and prevents most “stuck for hours” headaches.

Want a dead-simple checklist you can follow every time? I’m putting that next, along with a rapid-fire FAQ so you can send smarter in under a minute. Ready for the quick-win playbook?

Wrap-up, quick checklist, and FAQ-at-a-glance

Here’s the straight-to-action wrap-up I use whenever I need to send BTC without wasting time or money. If you’ve ever been burned by a stuck transaction or overpaid during a brief spike, this will keep you in control on every send.

Quick sending checklist

Open BTCFees: check the current next block and economy bands at fees.truelevel.io.

Match fee to urgency: pick “next block” for ASAP or the mid/economy tier if you can wait. Don’t bid below recent block floors when you need speed.

Enable RBF before sending: if the mempool heats up, you can bump the fee without re‑creating the transaction.

Use SegWit or Taproot: they cut vBytes vs legacy, which lowers the total fee for the same sat/vB rate.

Keep the transaction lean: fewer inputs, minimal outputs. If you must send many payments, batch them.

Time your send: if fees look hot and you’re not in a rush, wait—cheap windows often show up within hours.

Real example: Last month I saw “next block” around 28–32 sat/vB and “economy” at 6–8. I batched two payouts into one Taproot transaction and used the 8 sat/vB tier. It landed a few hours later when the mempool eased, and the total fee was less than half of what two separate sends would have cost.

Rule of thumb: If the recent blocks are all clearing at 20+ sat/vB, don’t try to sneak in at 10 sat/vB if you need speed. Either add a cushion or plan to RBF.

FAQ-at-a-glance

Cheapest time to send? Often weekends and off-peak UTC hours. You can see consistent weekend troughs on historical mempool charts like Jochen’s mempool queue and block fee floors on mempool.space. Always confirm live on BTCFees before sending.

Stuck transaction? If you enabled RBF, bump to the next fee tier shown on BTCFees. If not, try CPFP from your change output to pull it through, or wait if the mempool is easing.

How much should I pay? Pick the band that matches your deadline. If the mempool is rising, add a small cushion over the suggested fee so you don’t get leapfrogged.

Why are fees high right now? Temporary congestion from market moves, inscriptions/mints, or exchange batching cycles. These waves cool off—watch for the next soft patch on BTCFees.

Data note: Over many months, public mempool datasets have shown a clear pattern—transaction pressure tends to dip on weekends and late-night UTC. That doesn’t mean it’s guaranteed every week, but it’s frequent enough to plan around when you’re flexible.

Final notes if you send often

Batch outputs: One bigger transaction is usually cheaper than many small ones. If you do payroll or regular payouts, this alone can cut your monthly costs meaningfully.

Consolidate UTXOs during cheap windows: Spend your small fragments into a single UTXO when fees are low—future transactions will be smaller and cheaper.

Track patterns weekly: Make a quick Saturday/Sunday habit—open BTCFees and note the economy band. Set reminders for recurring low-fee windows.

Cross-check before big transfers: Confirm your target sat/vB on BTCFees and one other source like mempool.space or bitcoiner.live. If they agree, I send. If they disagree, I enable RBF and stay flexible.

One more practical scenario: I sent a low-priority payment at 5 sat/vB while the “economy” band was 5–7. A sudden surge pushed recent block floors to ~22. Instead of sweating it, I used RBF to 24 sat/vB, and it confirmed in the next block. That 10-second decision saved hours of waiting.

Conclusion

Fees shouldn’t be a guessing game. With a quick look at BTCFees, a realistic fee band, and RBF as your safety net, you’ll stop overpaying, avoid stalls, and send with confidence. Keep it simple: check the bands, set the right sat/vB, and use timing to your advantage. Your future self—and your fee budget—will thank you.

Pros & Cons

Updates info in real-time i.e. few seconds.

Table is easy to be understood by pro miners.

Relays important information to users.

Not suitable for beginners.

Site is too advanced and looks complex.

Cryptocurrency Websites Like BTCFees

CRYPTO HOME

1.ETH Gas Station

2.transaction fee info

3.WhatTheFee.io

» VIEW ALL THE Best Cryptocurrency SITES (4) «