In the previous article “How the Lightning Network Works (2),” we explored the working principle of the Bitcoin Lightning Network. Essentially, the Lightning Network is a meticulously designed payment channel system that links multiple payment channels together, forming a vast, interconnected payment network that allows parties not directly connected to make payments through multi-hop routing, with contracts like HTLC and PTLC ensuring the security of the routing.
After years of development, although the Lightning Network has made significant progress in technology and user experience, we must face a reality: it has not yet reached a level suitable for large-scale adoption. In today’s article, we will focus on a key challenge currently facing the Lightning Network: the liquidity issue. This issue can be further divided into two aspects: one is insufficient overall liquidity in the network, and the other is liquidity allocation issues.
Insufficient Overall Liquidity in the Network#
According to the latest statistics from mempool, the Bitcoin Lightning Network currently has 12,389 nodes, 48,000 payment channels, and a total channel capacity of 5311.8 BTC.
The Lightning Network is a P2P liquidity network, if it is to truly move towards large-scale adoption, both the number of nodes, the number of channels, and the channel capacity need to grow by hundreds or even thousands of times. So, how can we attract more nodes to join the network?
First, it is crucial to lower the barriers to building and maintaining Lightning Network nodes, allowing ordinary users without a technical background to easily run Lightning Network nodes. In the Bitcoin ecosystem, several teams have already launched plug-and-play hardware devices, such as Umbrel's hardware box, which supports running Bitcoin Lightning Network nodes, and Fi5Box, which supports running nodes for other Lightning Networks (like CKB's Fiber Network). They provide users with a maintenance-free Lightning Network node solution.
Secondly, introducing additional incentive mechanisms is key to promoting a virtuous cycle for the Lightning Network. Once a channel is opened in the Lightning Network, funds are locked. If Alice wants to become a Lightning Service Provider (LSP) and open channels with 100 people, locking 1 BTC in each channel, she would need to lock 100 BTC. These 100 BTC will only generate revenue when they are liquid; when they are static, they won’t, as the revenue for Lightning Network nodes mainly comes from transaction fees. The fee structure is “Base Fee + Fee Rate,” where the base fee is a fixed fee charged by the Lightning Network node for each transaction invoice, regardless of the transaction amount, and the fee rate is the proportion charged for each satoshi of the transaction invoice.
According to mempool statistics, the current average base fee for the Bitcoin Lightning Network is 950 mSat (0.95 satoshis), and the average fee rate is 764 ppm (0.000764 satoshis per satoshi), which means that for a transaction amount of 10,000 satoshis (0.0001 BTC, currently about $6.5), the routing node receives less than 9 satoshis in fees. Moreover, the current transaction volume in the Lightning Network is not large, and many transactions do not need to go through routing nodes (i.e., the two parties have a direct payment channel). Therefore, those holding BTC who want to invest are not primarily choosing to deposit BTC into the Lightning Network to earn fees, but rather to lend on exchanges or participate in staking/restaking in some emerging projects.
If additional incentive mechanisms can be introduced to encourage more people to run Lightning Network nodes or become LSPs, and to motivate more BTC holders to deposit BTC into the Lightning Network to earn incentives, the issue of insufficient network liquidity may be resolved, making the Lightning Network more user-friendly. Once the Lightning Network becomes more user-friendly, it will attract more users, leading to more transactions, increasing routing node fee income, and incentivizing more people to become LSPs... ultimately creating a virtuous cycle for the Lightning Network.
Currently, in the Bitcoin ecosystem, UTXO Stack has announced its transformation into a staking layer for the Lightning Network, providing better liquidity and a better yield model for the Lightning Network through a decentralized staking protocol. At the same time, UTXO Stack will also launch a token incentive mechanism to encourage users to stake BTC to enhance the liquidity of Lightning Network payment channels.
Liquidity Allocation Issues#
Even if the issue of overall liquidity is resolved, how to effectively allocate this liquidity remains a challenge.
Taking the example of Alice making a payment to Carol through routing node Bob, suppose initially Alice and Carol each have 20,000 satoshis in the channel, and Bob has 10,000 satoshis in each channel. After several transactions, the balance distribution in the channel is as follows (for simplicity, we will not consider the fees charged by routing node Bob):
If Alice and Carol still have business dealings in the future and Alice needs to initiate a payment to Carol, what should be done? Bob can no longer route the payment (i.e., Bob can no longer transfer funds to Carol in the channel between Bob and Carol), and he needs to rebalance his channel.
This situation is very common for routing nodes in the Lightning Network. Node operators must constantly balance liquidity between their channels; if there are no funds on your end of the channel, you cannot send payments; if all the funds in the channel are on your end, you cannot receive payments.
In the above example, one method is to directly close the channel between Bob and Carol and open a new channel, but this method is not economical, as both closing and opening channels require on-chain transactions, which incur Bitcoin miner fees. The original intention of the Lightning Network design is to reduce on-chain operations and conduct as many transactions as possible off-chain in channels. If the Lightning Network has hundreds of millions of channels to open and close daily, the Bitcoin blockchain will be perpetually congested, and miner fees will become exorbitant.
To address this, the Bitcoin community has proposed various innovative solutions to solve liquidity allocation issues:
Submarine Swap#
In simple terms, Submarine Swap allows users to send BTC from their channels to a swap service provider in the Lightning Network, which will then send the corresponding amount of BTC to a Bitcoin chain receiving address, or vice versa, the user sends on-chain BTC to the swap service provider, and the swap service provider sends BTC from the channel to a designated receiving node. Although this process involves the swap service provider, it is entirely trustless through HTLC (Hash Time-Locked Contract).
Submarine Swap has also inspired many successors, such as the channel balance adjustment protocol PeerSwap, which allows users to directly implement submarine swaps with their channel counterparties. In the above example, Carol can directly act as the swap service provider, with Bob sending on-chain BTC to Carol, and Carol paying the corresponding amount of BTC to Bob in the channel. Specifically:
- Bob generates a secret value R (pre-image) and its hash H.
- Bob creates an HTLC on the Bitcoin blockchain using hash H: Bob will pay Carol 10,000 satoshis as long as he can provide secret value R within 5 blocks; otherwise, the funds will return to Bob.
- Carol creates an HTLC in the payment channel between him and Bob using the same hash H: Carol will pay Bob 10,000 satoshis in the channel as long as he can provide secret value R within 4 blocks; otherwise, the funds will return to Carol (for simplicity, we will not consider the service fee charged by the swap service provider here).
- Bob uses secret value R to unlock the HTLC in the channel and takes 10,000 satoshis.
- After Bob takes the funds, Carol also knows secret value R, and he uses R to unlock the HTLC on the Bitcoin chain and takes 10,000 satoshis.
Compared to closing the channel and then opening a new one, Submarine Swap only requires one on-chain transaction, making it more economical and entirely trustless.
Channel Splicing#
Channel splicing is an on-chain rebalancing method: nodes close a channel and then open a new channel in a single transaction, thereby changing the balance locked in the channel. When a node locks in more funds, we call it “splice in”; if it reduces the locked funds, it is called “splice out.” In the above example, the channel between Bob and Carol can be lengthened through channel splicing.
Channel splicing is much more convenient than using two transactions to close and reopen a channel, but it still requires broadcasting the transaction on the network, paying on-chain miner fees, and waiting for transaction confirmation.
Multi-Path Payment (MPP)#
Multi-Path Payment allows a payment to be split into several parts, which can simultaneously reside or circulate in different places. If Alice needs to continue paying Carol 10,000 satoshis, although Bob can no longer route the payment, Alice can pay Carol 6,000 satoshis through routing node David and 4,000 satoshis through routing node Eva, thus completing Alice's 10,000 satoshis transaction through multi-path payment.
The original intention of multi-path payment technology is to overcome the limitations of single-path payments, allowing larger amounts to be delivered by splitting them into smaller parts, for example, a Lightning Network transaction of 1 BTC can be completed by splitting it into 100 transactions of 0.01 BTC each. Multi-path payment benefits the decentralization of the network and the privacy of transactions. In terms of security, Atomic Multi-Path Payment (AMP) technology ensures that if one path fails to complete the payment, all payments will not succeed, thus preventing confusion and fraud.
By the way, in the Lightning Network, large transactions can also be completed through Wumbo channels in addition to multi-path payments. Wumbo channels remove the Bitcoin amount limit that conventional Lightning channels can hold — 0.1667 BTC, allowing nodes to have higher channel capacity to support large transactions.
Conclusion#
Liquidity is one of the main factors restricting the development of the Lightning Network. By lowering the barriers to building and maintaining Lightning Network nodes and introducing additional incentive mechanisms, we can help the Lightning Network address the issue of insufficient network liquidity, while solutions like Submarine Swap, channel splicing, and multi-path payments can assist in addressing liquidity allocation issues.
In addition to the above solutions, the Bitcoin community has also proposed Lightning Pool (a channel leasing auction market), Liquidity Advertisement (a channel leasing solution), and loop payments (a node pays itself through a loop formed by payment channels for off-chain rebalancing) among other solutions to optimize network liquidity.
Liquidity management is undoubtedly a complex project facing the Lightning Network, but with continuous technological advancements and ongoing community efforts, we have reason to believe that these liquidity challenges will eventually be resolved.
📖 Recommended Reading