Choose Who Bears Channel Opening Fees

Has it ever happened...

...that you want to gift someone their first 10,000 sats on Lightning, but - with your Bitcoin principles right - you recommend a self-custodial wallet and the new Bitcoiner now only gets 7,500 sats. Expecting to receive 10,000 sats, this situation dampens the joy, leaving you in the awkward position of having to immediately explain channel opening fees and LSPs (Lightning Service Providers). Paying an extra 2,500 sats would have been a small price to avoid this awkward explanation during a first introduction to Bitcoin.

Or perhaps you've found yourself wanting to transfer funds between your own wallets, aiming for an exact amount in a specific one. Yet again, you're thwarted by channel opening fees, receiving less than anticipated and forcing you to make additional payments just to reach the desired balance.

Let me know if these scenarios sound familiar too you, so we know we are not alone ‎and please share if you would find the small, simple feature presented next useful or not.

Feature exploration

The feature we are exploring allows the user the flexibility to decide who bears the cost of LSP fee(s) – a choice between adding the fees on top of the invoice amount or having them deducted from the inserted amount to receive. Or in other words, the choice between passing fees on to the payer and receiving the desired amount or bearing the fees oneself, receiving less than the inserted amount to receive.

Currently, the apps we know of only give an informative fee estimate for opening a channel, but it is up to the user to do the calculation of how much the invoice amount should be to really receive a certain desired amount, taking the fee deduction into account. We think we can make this easier.

This concept isn't new in the world of financial transactions. In traditional banking, especially in international payments, parties often have to decide whether costs are borne by the sender, shared between both parties, or assumed by the receiver. We think this concept can also be applied to some Lightning Service Provider fees.

In our first iteration, we do not include sharing the fee between both parties, but first try to solve the problem of the receiver not receiving the amount he wanted. We think this is important in our app since we ask "How much do you want to receive?" when a flow to receive sats is initiated.

Functional demo

In this demo you can see how the expected fee is presented when trying to receive an amount bigger than the available inbound liquidity and how the user can choose to bear the fee by toggling off a switch and receiving less than the desired amount to receive.

If the switch is kept on, the fee is added to the total amount of the invoice, passing the cost on to the payer of the invoice. If the switch is turned off, you can see that the "Amount to receive" becomes less, clearly letting the user know he will probably not receive the inserted amount.
The invoice will always be generated with the amount as shown in the "Invoice total".

As mentioned above, our focus is on letting the receiver receive the inserted amount, so the switch is toggled on by default, passing fees on to the payer by default.

If enough inbound liquidity is available and no channel opening fee is needed, the switch will not be shown. As can be seen at the end of the video when inserting a much smaller amount to receive.

NOTE: The switch and layout of the modal in the demo are not designed by our great UX designer Joseph yet, but just done by myself in code directly to test this out and make it more visual to communicate. Based on the feedback, we will improve this with Joseph.

Considerations

The feature's effectiveness is not bulletproof and may vary if LSP fee rates or inbound liquidity change after invoice generation, potentially still altering the received amount. It's most reliable for payments immediately after invoice generation.

Enhancements

Future enhancements could refine total invoice amount calculations to receive the desired amount after fee deduction in all scenarios, possibly supported by LSP APIs providing fee estimates for desired amounts to receive directly.

We Want to Hear From You

Have you experienced similar frictions with fee deductions and desired payment amounts? Do you think this feature could make your Lightning wallet experience smoother and more predictable? Do you think this is worth exploring further? Have you seen something similar already? What do you think the default option should be for bearing or passing on the fees? Do you think splitting the fee in half between receiver and payer should also be an option?

Your input is invaluable to us, so please leave a comment. Definitely also if you think this is a bad idea or do not see the need for it.