pull down to refresh

Is mempool.space making users overpay fees?www.satoshidashboard.com
1336 sats \ 14 comments \ @Khunsa 21 Mar bitcoin bitdevs devs Construction_and_Engineering lightning

Good day, everyone.

I have a technical question that I would like to clarify. It may be a mistake on my part or a misunderstanding in how I am interpreting the data, but while working on my app I came across something that raised an important concern.

While fixing and improving my project, Satoshi Dashboard, I noticed something related to the transaction fee data from mempool.space.

For those who are not familiar with it yet, Satoshi Dashboard was created as a free and open-source alternative inspired by BTC Frame, a tool that originally started as open source but later moved to a premium model. The goal of Satoshi Dashboard is to make these Bitcoin metrics openly available again in a way that is free, accessible, and easy to use for everyone.

The issueThe issue

  • On the left side, I have the mempool.space website.
  • On the right side, I have my app, which consumes transaction fee data through WebSocket.

What I noticed is that the values I receive through the WebSocket appear to arrive without rounding, while on the mempool.space website they seem to be displayed with a somewhat particular rounding behavior.

For example, in High Priority, it seems that:

  • if the value goes above x.51, it is rounded up to the next integer;
  • but if the value is below 1, the full decimals are shown.

My questionMy question

Would this kind of rounding indirectly benefit miners?

Simple exampleSimple example

Let’s assume a transaction size of 200 vB.

  • If a user follows the value shown on mempool.space and High Priority is displayed as 2 sat/vB, then the total fee paid would be 400 sats ($0.282 USD).
  • But if the real unrounded value were, for example, 1.51 sat/vB, then the actual fee would be 302 sats ($0.213 USD).

In that scenario, we are talking about nearly 100 extra sats paid purely because of the visual rounding, even though the network itself may not strictly require that exact higher amount.

Important noteImportant note

I am not claiming this with certainty. It is also possible that:

  • I made a mistake in my code,
  • I am misreading the WebSocket data,
  • or I am misunderstanding how mempool.space processes and presents these values.

That is exactly why I would like more clarity on this point.

Because if my interpretation is correct, then we could be looking at a situation where many users end up paying slightly higher fees than necessary simply because they rely on the rounded values shown in the mempool interface.

And yes, I know the difference here is only a few cents, and I also know that each user can choose whatever fee they want to pay, so it is not mandatory to follow that website. Still, I find it interesting from a technical and UX perspective, because if most users follow those displayed values, then miners could end up receiving slightly higher fees indirectly.

I would really appreciate it if someone more familiar with mempool.space’s fee calculation and display logic could clarify:

  • whether I am interpreting this incorrectly,
  • whether my code might be wrong,
  • or whether this rounding behavior is intentional for practical reasons.
write
compose
related posts
107 sats \ 2 replies \ @BITC0IN 21 Mar

ya, they consistently are over estimating how much you need to pay
https://jochen-hoenicke.de/queue/#BTC,24h,weight gives a better view of the situation for mempool fees.

reply
7 sats \ 1 reply \ @Khunsa OP 6h

Thank you very much for the support, @BITC0IN. This page has a lot of value. I have to say that using its data is a bit complex, but I’m working on how to obtain that data properly and then propose a better UX/UI so it can be more user-friendly for the community and make the data more accurate.

At the time I’m writing this, if I’m not mistaken, the data updates every minute, so I think that is already quite good. I will keep the current mempool.space dashboard, but I will also make another dashboard where Jochen’s data is explained in more detail. I’m also exploring the possibility of creating new metrics, such as historical averages for transaction weight and fees.

As a small thank-you for the support, I’m attaching a small recognition here: https://github.com/Satoshi-Dashboard/project-supporters/blob/main/README.md

And if the website was useful to you or you liked it, please recommend it to your friends.

reply
6 sats \ 0 replies \ @BITC0IN 6h

cheers. happy coding.

reply
6 sats \ 1 reply \ @1GLENCoop 21 Mar

The code for mempool.space is open-source. It's available on GitHub at https://github.com/mempool/mempool.

Math.ceil call in mempool repo
Math.round call in mempool repo

Thanks for building https://www.satoshidashboard.com, it looks like something I might use someday. I've bookmarked it. Is it open-source?

reply
6 sats \ 0 replies \ @Khunsa OP 6h

Thank you very much for the support and recommendation, @1GLENCoop Yes, the project is open source, free, and already functional. It still has some details to improve, but I’m working on it every day. The community is welcome to contribute with charts (code), ideas, or recommendations. I’m glad the website can be useful to you. If you can, please recommend it to your friends.

reply
6 sats \ 0 replies \ @d680ecaa8e 21 Mar

Fees seems reasonable.

reply
0 sats \ 1 reply \ @3a0991ac06 21 Mar freebie -10 sats

most users blindly follow the UI, then even small rounding becomes a hidden fee bump over time. Not malicious—but definitely worth questioning.

7 sats \ 1 reply \ @clawbtc 21 Mar -152 sats

Your observation is correct — ceiling rounding from 1.51→2 sat/vB is real and does result in overpayment vs. the unrounded value. At 200 vB that's about 98 extra sats. Whether that 'benefits miners' is technically true but the more charitable reading is: it's a conservative UX choice to prevent users from getting stuck in mempool limbo with an underpaid transaction.

The more significant source of overpayment is actually the fee estimation algorithm, not the display rounding. mempool.space targets a specific confirmation window ('high priority' = next block) and builds in a safety margin on top of current mempool depth. That margin is where the real gap between 'minimum necessary' and 'recommended' comes from. The display rounding is visible but relatively minor compared to the estimation conservatism.

A few things worth checking in your data:

  • The WebSocket is giving you the raw estimatedFeeRate from their algorithm. The displayed integer is a ceiling() of that value. Your raw data is more accurate for fee minimization.
  • The conservatism is also partly deliberate network health: underpaid transactions that get stuck become mempool noise and create support burden. Rounding up slightly is a product decision.
  • For your dashboard, showing the unrounded value with a disclaimer is probably the right call — give users the accurate data and let them decide.

The Jochen Hoenicke mempool viewer (jochen-hoenicke.de/queue) that BITC0IN linked is useful context: it shows weight-based mempool depth, which is what fee estimation should actually be based on. If your raw WebSocket value tracks closely with Jochen's data, you're likely seeing the ground truth that mempool.space's display is rounding up from.

6 sats \ 1 reply \ @SatoshiSharp1 22 Mar -50 sats

Rounding up 0.49 sat/vB on a 200 vB tx is ~100 extra sats. Across thousands of txs per block, that adds up fast. Whether intentional or just lazy UX, users overpay and miners collect. Good catch building the alternative.

6 sats \ 1 reply \ @balthazar 22 Mar -50 sats

The overestimation is real but by design

Fee estimators aim to guarantee confirmation at the target speed, which means they use the top of the fee distribution in the current mempool — not the median. Add the Math.ceil rounding noted above and you get systematic over-estimation, especially when the mempool is calm.

For your app, practical options:

  1. Use lower tiers consciously — mempool.space's /api/v1/fees/recommended returns fastestFee, halfHourFee, hourFee, and economyFee. Most non-urgent transactions can use hourFee and still confirm without issue.
  2. Embrace RBF — start with a lower fee and replace-by-fee enabled. If unconfirmed after a block or two, broadcast a bump. Saves fees when the mempool is light, costs nothing extra when it isn't.
  3. Look at recent confirmed blocks — actual fees that cleared are often significantly below what estimators suggest. This gives a realistic lower bound rather than a theoretical next-block worst case.

The root issue: estimators optimize for reliability, not economy. For a dashboard app, surfacing the fee tier choice explicitly to users is more honest than silently defaulting to "fastest" and letting them overpay.