Send fees
Fees are a necessity in a market-based network, both the base layer and lightning. They can vary drastically based on which layer the transaction is being made on, as well as the current network state, transaction complexity, whether any additional services were used, and more. To simplify this complexity for users, it is important to provide clear and actionable information and options.
Lightning fees #
Let’s take a look at how fees surface in a regular send flow, and how users can quickly pull up additional details.
Routing fees #
On the lightning network, payments are passed between nodes to get from the sender to the receiver. Each of those nodes may charge a base fee and a second fee based on a percentage of the amount forwarded. Fees paid can vary, but are typically in the single-digit or double-digit Satoshi range (a small fraction of on-chain fees).
Service fees #
Lightning wallets may require additional services to solve certain usability issues. An example being a lightning service provider (LSP) opening payment channels and providing inbound liquidity for the user, so they can receive payments. As these services are offered by third parties, additional fees may be charged.
On-chain fees #
This fee is largely dependent on how many other transactions are currently waiting to be processed on the base layer as a whole. The average fee in January 2021 was $0.63, and $28.60 in April 2021.
A new block of transactions is confirmed roughly every 10 minutes. Blocks have a size limit, which places a limit on the number of transactions they can contain. Transaction size varies depending on the complexity. A complex multi-key transaction with many inputs and outputs involves more data, and therefore carries a higher fee, compared to a simple one that involves only one input and output. An organic fee market emerges from these dynamics, as miners try to earn as much as they can from fees, and transacting users try to optimize for time, fee rate, or other priorities.
Generally, it is best to dynamically calculate a reasonable fee range and provide a few simple options based on how urgent the transaction is for the user. Total cost and confirmation time are often the primary decision points.
High fee situations #
Unfortunately, it is common for users to overpay on-chain fees by mistake. Wallets should have mechanisms in place to avoid this from happening.
If a user’s transaction amount is low compared to the fee they would pay to broadcast, warn them. There are no standards regarding the threshold percentage to trigger such an alert. A good benchmark is to warn the user if their fee is 50% or more than the value of the transaction itself. You might choose a different threshold for your app. Procedures like this should be enough to ensure users do not overpay on-chain fees unintentionally.
Including the fee in the amount #
The most common scenario is that sender and receiver have an understanding of how much to exchange, and the sender is also responsible for paying the fee. However, there are situations where this is not wanted or possible:
- Sender and receiver agree that the receiver will cover the fee
- The sender balance is enough to cover the amount to pay, but not the fee
- The sender wants to clear out the wallet, possibly to migrate
To accomodate these, the interface also needs to provide manual customization options, although they can be placed into secondary location (see below).
Other scenarios #
The visuals below illustrate additional scenarios and states, for when the users balance is so low that they may not be able to pay for the fee, and for customizing the fee in detail.
Now that we’ve tackled sending and receiving, let’s look at how we can summarize this activity and make it useful.