pull down to refresh

6 sats \ 1 reply \ @balthazar 22 Mar -50 sats \ on: Is mempool.space making users overpay fees? bitcoin bitdevs devs Construction_and_Engineering lightning

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.

write
compose
6 sats \ 0 replies \ @Khunsa OP 23 Mar

Thanks for supporting the project, @balthazar. I agree with what you mentioned. For example, Sparrow Wallet relies on mempool to suggest the user’s fee rate. Of course, the user ultimately chooses, but the displayed data is still based on that same rounding logic. Even so, from what I see, the UX they use is quite limited in resources, which in a way makes it better than mempool’s, because it does not push the user into three fixed choices: economy, normal, and priority.

reply