Repository navigation
Consider allowing users to see transaction details before sending onchain payments #578
Description
We should consider to allow users to see transaction details before sending onchain payments. In particular, they might want to see the fee they are going to pay before they actually send the onchain payment.
We could consider an API where we allow to 'stage' a pending transaction first, and then have the user release/cancel it with another call. However, if we do this, we'll have to figure out when/how to prune pending transactions if the user doesn't end up releasing/cancelling them.
The latter part is especially important as we need to make sure that, once BDK allows us to, lock the used UTXOs when staging, and unlock them in the cancellation case, or after some timeout.
As this introduces quite some complication to our payment flow, I'm not fully sold on the idea, but it indeed seems like a pretty useful feature for users.
Activity
Camillarhi commentedon Nov 2, 2025
@tnull , I've been thinking about this. Do we need the full staged transaction complexity?
The main goal seems to be showing users the fee before they commit. Could we instead expose a simpler
estimate_onchain_fee(amount, address)API that:feeratesThis avoids UTXO locking, timeouts, and state management. Fees are dynamic anyway, so staging doesn't guarantee accuracy if feerates change between preview and send.
We could start with this simpler approach and only add transaction staging later if users specifically need to preview the complete transaction structure. What do you think?
tnull commentedon Nov 7, 2025
Hmm, well, the issue there is that not only fees might change, but also your wallet state might change inbetween, meaning that the wallet might end up adding or removing a (e.g., change) output, which could considerably shift the fees in one or the other direction.
Note that we'll also have the same issue for splicing (cf. #677 (comment)), so working out an API design that works similarly in all cases would be preferable. That's why I'm hesitant to just 'ship the simple thing' right away.
Camillarhi commentedon Nov 7, 2025
I see, I will go through #677 to understand it and see if I have any more thought on this.
Thanks
f3r10 commentedon Jul 28, 2026
Hi @tnull is this issue open to work on? It seems challenging. I am going to investigate further and see if I can come up with a viable approach.