To successfully run a Lightning node, you need to understand how the Lightning Network works; it is not some plug-and-play operation where you can set it and forget it. When you commit funds to the Lightning Network, you’re dealing with funds in a hot wallet that is connected with another peer and needs to remain online at all times, waiting for requests to route payments.
Managing a Lightning node is also a fairly interactive process, meaning you have to do a lot of individual manual tasks. The job description includes finding good peers, opening, closing, and manually balancing your channels.
Obviously, these tasks pile up and eventually become the equivalent of a part-time job and a job that doesn’t guarantee that you always get paid for that labour.
Liquidity management is an unavoidable pain.
Liquidity management ensures that a node on the Lightning Network has enough capacity to make payments and route payments. This is important because you don’t want to have an unbalanced channel, or you will miss out on potential routing fees as the network would route payments around you since you’re no longer a viable path.
If you’re keeping tabs on your node, your only problem would be how you plan to rebalance your node. Will it be using another channel, with new channels you bring online with an on-chain payment, or will it be you buying liquidity from another node?
Depending on your specific case, and the cost, you would pick one of those options.
Nodes with more channels and more funds in each channel will have more issues to deal with, and the more channels you have, the more work you have to keep them operational. Nodes that are well-connected to other nodes will also have more liquidity issues.
Good liquidity management is essential for the Lightning Network to function properly. By managing your liquidity effectively, you can help to ensure that the network is able to handle more payments and that fees remain low, as well as ensure you take a piece of those routing fees going around.
As the network grows, so does the need for better use of liquidity, and manually managing things won’t be practical, so Lightning Automation Tools have to come into play to help lessen the burden.
What are fee rate cards?
One of the most common tasks of running a Lightning node is channel rebalancing; in some cases, it might take some time; in other cases, it can happen rather quickly, and you will need to intervene. Since fees are the primary method of control over payments flowing through a channel, two proposals have made the round, one is the concept of negative fees, and the other is fee rate cards.
Both proposals aim to tackle the pain of lopsided channels, each with its own pros and cons.
With fee rate cards, the user specifies four different fee rates to be charged for routing a payment, and those fees will become active based on preset amounts of the available liquidity (channel capacity).
This means that the fee charged would be dynamically set based on how much liquidity you have available to be consumed.
- If you have the majority of the liquidity on your side, you could set a negative fee to incentivise peers to use that payment channel and rebalance it.
- If you have a minority of the liquidity on your side, you could set a very high fee to disincentivise people to use that route and unbalance the channel even more.
- Finally, if the liquidity is balanced, you can charge the current market average price for using the payment channel.
Since fee rate cards would apply rules based on certain parameters, it doesn’t require constant signalling to the network that you are about to change your fee policy. This also implies less overhead on broadcasting channel updates and changing the channel graph regularly, which can cause issues with payment path calculation.
There are no formal proposals for rate cards yet, but Developer Lisa Neigut is formalising a proposal for fee rate cards, an alternative fee structure and giving node runners more optionality versus the current base and proportional fees.
Reducing Lightning node maintenance
Running a Lightning node can be simple if you’re only focusing on private payments between a few friends or you only maintain a channel for a very specific service, but this is not a realistic use of Lightning for everyone, nor is it a landscape that can scale.
Ideally, we want those willing to connect to the network to split up their liquidity and create as many interconnections as it takes for all users to route payments as cheaply and as quickly as possible.
While there will be super user nodes and industrial nodes that can deploy more liquidity and better manage their channels to chase profits, there will also be a need for smaller nodes willing to take on connections that aren’t attractive to those larger nodes.
There are always opportunities to extract value from the network, but if users find it complex or laborious to deploy capital to capture that yield, the effectiveness of the network suffers in a sense.
If Lightning’s aim is to reach more users and encourage those users to run their own infrastructure and remain in control of their capital instead of relying on custodial services or Lightning Service Providers, then the user experience and toolsets need to ensure channels remain operational most of the time.
The easier it becomes to manage a channel and keep it operational, the less chance users need to interfere or close channels. If channels remain open for longer, it reduces the on-chain footprint and ensures more channels close in a profitable state.
Are you a Bitcoin and Lightning fan?
Have you been using Lightning to make micro-payments? Stream sats or engage with apps? Which app is your favourite? Do you run a Lightning node? Have you tried all the forms of Lightning payments? Which one do you prefer?
Let us know in the comments down below.
