Plan a Bitcoin payment fee without sending anything

What you will end up with

A small fee budget written in satoshis: an estimate for a payment that can wait, an estimate for a more urgent payment, and a maximum cost worth accepting. The exercise ends with that note. It does not create, sign or broadcast a transaction.

The useful habit is separating fee rate, measured in satoshis per virtual byte, from total fee, measured in satoshis. A rate only becomes a cost when multiplied by a transaction's size. A payment's bitcoin amount is not that size: spending many small inputs can require more space than spending one larger input.

This guide is for someone planning an ordinary on-chain payment. It is not a Lightning fee guide or a procedure for rescuing an already broadcast transaction. The mempool and fees explainer covers the underlying mechanisms; here the outcome is a calculation and a decision.

Before you start

Use a browser, a calculator and a blank note. No wallet, account, address or recovery phrase is needed. Keep the exercise separate from a real checkout or invoice with a deadline.

The reference service is mempool.space, using its Bitcoin mainnet estimates. Its official recommended-fees endpoint can be opened directly in a browser and returns plain JSON. JSON is structured text: each quoted field name is followed by its value. There is nothing to install.

The endpoint and the arithmetic below were checked on October 15, 2026. The latest published mempool release was v3.3.1; the public service reported a development build, 3.4-dev. These are different facts. This guide checks the public response and the released source's field meanings, without claiming that the service runs the published release. Wallet interfaces, signing and broadcast were not tested.

The tradeoff you are accepting

A lower rate may cost less, but leaves less room for demand to rise before a miner includes the transaction. A higher rate spends more for a stronger bid for block space. Neither purchases a delivery deadline. Estimates describe the service's current view, and new transactions can change it.

There is also a privacy choice. Opening general fee information exposes an ordinary web request to the service, but does not require linking an address to that request. Do not enter an address, upload a transaction or connect a wallet for this exercise. A self-hosted explorer is an alternative for people who already operate one; setting it up is outside this guide. No purchase or paid acceleration service is needed.

Steps

1. Write down the payment's timing requirement. Use plain language, such as “can wait until tomorrow” or “recipient needs a confirmation before accepting the order.” If the recipient imposes a deadline, record that separately. An estimate cannot extend an invoice's expiry, and a transaction seen by a website is not the same as a confirmed payment.

2. Open the recommended-fees endpoint. Use the official URL above, with no address or transaction ID appended. Record the UTC time of the observation. The expected result is an object containing numeric fastestFee, halfHourFee, hourFee, economyFee and minimumFee fields. If the page is unavailable or returns an error, stop using that observation. An error page is not a zero-fee recommendation.

3. Record two rates for comparison. Use hourFee for the less urgent example and fastestFee for the more urgent one. These field names are not promises about elapsed time. The released fee-panel template presents them as Low Priority and High Priority. The estimator implementation derives recommendations from projected blocks and the node's mempool floor. Do not treat minimumFee as a universal network minimum or an assurance of confirmation.

4. Choose a clearly labelled practice size. Write “invented example: 200 vB.” This is an arithmetic input, not a typical size promised for a wallet. A second example of 400 vB shows the effect of a larger transaction. Virtual bytes account for transaction weight; BIP 141 defines the size as weight divided by four, rounded up. There is no need to calculate weight for this exercise.

5. Multiply each rate by each practice size. At an invented 3 sat/vB, a 200 vB transaction costs 600 sats. At an invented 8 sat/vB it costs 1,600 sats. The 400 vB example costs 1,200 or 3,200 sats respectively. These are practice rates, not today's recommendation. Label the results “network fee estimate” and keep the units beside each number. If a fractional result occurs, round the estimated total upward to a whole satoshi.

6. Write a maximum total fee. Make this a personal spending limit in sats, rather than copying the explorer's highest rate. Compare both estimates with that limit. If neither fits and the payment can wait, the useful result is “recheck later.” If a deadline is strict, the useful result may be “this payment method does not fit the deadline and budget.” There is no requirement to send merely because a calculation is finished.

7. Save the note with its observation time. Include the service URL, the two observed rates, the invented sizes, the calculated totals and the timing requirement. Before a future real payment, obtain a fresh estimate and read the wallet's own final fee and size. An actual transaction may select different inputs or create change, so this practice budget cannot approve a real transaction. This guide ends before any signing or sending action.

Verify it worked

Check the units first: sat/vB × vB = sats. Then divide each total by its practice size. The result should recover the input rate. In the examples, 600 ÷ 200 = 3 and 1600 ÷ 200 = 8. Doubling the size while keeping the rate fixed should double the fee. If it does not, correct the arithmetic before using the note.

Check that the recorded rates came from the same observation and that the values are finite positive numbers. An absent value, a blank page or text saying “unavailable” must stay unknown. The successful outcome is a dated budget with explicitly invented sizes, not a prediction that a particular transaction will confirm.

The arithmetic was exercised with disposable synthetic inputs, including rejection of missing and negative rates. No real wallet, transaction, funds or recipient was used. The live endpoint was read; its future estimates and actual confirmation times cannot be validated by this exercise.

If something goes wrong

The two rates are equal. That can be a valid response. The released estimator allows priorities to converge when projected demand is low. Record the equality rather than inventing a premium for urgency. Equal estimates still do not create a deadline guarantee.

The website shows a different total cost. Check whether it assumes a sample transaction size or converts the fee into a local currency. The released fee panel uses a 140 vB example for its fiat display. That is not the size of the invented examples above or of a future wallet transaction. Compare sat/vB with sat/vB and total sats with total sats.

The wallet later quotes more than the budget. Stop at its review screen. Check the actual virtual size, rate, and any separate provider charge. Do not lower a fee blindly to make a total look acceptable, and do not change input selection without understanding its privacy implications. The coin-control guide explains that separate decision.

A payment is already pending. Repeating this exercise does not replace or cancel it. Do not send a duplicate payment just because an explorer is slow or an estimate changed. Use the transaction-reading guide to distinguish transaction details from confirmation status, then follow the sending wallet's documentation for any further action.

Sources

• mempool recommended-fees response, checked October 15, 2026.
• mempool v3.3.1 release, published April 21, 2026.
• Released mempool v3.3.1: fee-panel labels and sample size, fee estimator, and HTTP route and unavailable response.
• BIP 141: transaction size calculations.