In the previous article, “How the Lightning Network Works (2),“ we explored the working principles of Bitcoin’s Lightning Network. Essentially, the Lightning Network is a carefully designed payment channel system that connects individual payment channels into a vast, interconnected payment network. This allows parties that are not directly linked to make payments to each other through multi-hop routing, with contracts such as HTLC and PTLC ensuring the security of the routes.

Despite years of development and significant progress in both technology and user experience, we must face the reality that the Lightning Network has still not reached the level of large-scale adoption. In today’s article, we will focus on a key challenge currently faced by the Lightning Network: the liquidity issue. This challenge can be further divided into two aspects: the overall lack of liquidity in the network and the problem of liquidity distribution.

Overall Network Liquidity Shortage

According to the latest statistics from Mempool, the Bitcoin Lightning Network currently has 12,389 nodes and 48,000 payment channels, with a total channel capacity of 5,311.8 BTC.

The Lightning Network is a P2P liquidity network, and to achieve true large-scale adoption, the number of nodes, payment channels, and overall channel capacity would need to grow by hundreds or even thousands of times. So, how can we attract more nodes to join the network?

First, it’s crucial to lower the barriers for setting up and maintaining Lightning Network nodes, making it easy for users without a technical background to run a Lightning Network node. Several teams in the Bitcoin ecosystem have already introduced plug-and-play hardware solutions, such as Umbrel’s hardware box, which supports running Bitcoin Lightning Network nodes. Similarly, Fi5Box not only supports the Bitcoin Lightning Network but also enables running nodes for other networks, such as CKB’s Fiber Network. These devices provide maintenance-free node solutions for users.

Second, introducing additional incentive mechanisms is key to creating a positive feedback loop for the Lightning Network. Once a payment channel is opened on the Lightning Network, the funds are locked in. For instance, if Alice wants to act as a Lightning Service Provider (LSP) and open channels with 100 people, allocating 1 BTC per channel, she would need to lock up 100 BTC. These funds only generate revenue when they are in motion; idle funds do not. This is because the primary income for Lightning Network nodes comes from transaction fees, which are typically calculated as “Base Fee + Fee Rate per satoshi.” The base fee is a fixed amount charged for each transaction, regardless of its size, while the fee rate is the percentage charged per satoshi in the transaction.

According to Mempool’s statistics, the current average base fee in the Bitcoin Lightning Network is 950 mSat (0.95 sat), and the average fee rate is 764 ppm (0.000764 Sat per satoshi). This means that for a transaction of 10,000 satoshis (0.0001 BTC, currently worth about $6.50), the routing node would earn less than 9 satoshis in fees. Moreover, transaction volume on the Lightning Network is still relatively low, and many transactions don’t require routing nodes at all (because the two parties involved have a direct payment channel). As a result, those holding BTC and looking for investment returns are not primarily choosing to lock their BTC into the Lightning Network to earn transaction fees. Instead, they prefer to lend their BTC on exchanges or participate in emerging projects offering Staking/Restaking opportunities.

If additional incentive mechanisms can be introduced to encourage more people to run Lightning Network nodes or become LSPs, and if more BTC holders are motivated to deposit their BTC into the Lightning Network to earn rewards, the issue of network liquidity shortage could potentially be resolved. As the Lightning Network becomes more user-friendly, it will attract even more users, leading to increased transactions, which in turn will raise the routing nodes’ fee income and encourage more people to become LSPs. This would eventually lead the Lightning Network into a positive feedback loop.

Currently, in the Bitcoin ecosystem, UTXO Stack has announced its transition into a staking layer for the Lightning Network. Through a decentralized staking protocol, it aims to provide better liquidity and an improved yield model for the Lightning Network. Additionally, UTXO Stack will introduce a token incentive mechanism to encourage users to stake BTC and enhance the liquidity of Lightning Network payment channels.

Liquidity Distribution Issue

Even if the overall liquidity shortage is resolved, effectively distributing this liquidity remains a challenge.

Let’s take an example where Alice makes a payment to Carol through the routing node Bob. Initially, both Alice and Carol have 20,000 satoshis in their channels, while Bob has 10,000 satoshis in each channel. After several transactions, the balance distribution in the channels may look like this (for simplicity, we are not considering the routing fees collected by Bob):

If Alice and Carol still have business dealings in the future, where Alice needs to make further payments to Carol, what can be done? Bob can no longer route payments (as Bob no longer has enough funds in his channel with Carol to transfer money to her). In this case, Bob needs to rebalance his channel.

This scenario is quite common for routing nodes in the Lightning Network. Node operators must constantly balance liquidity between their channels. If a channel has no funds on your side, you cannot send payments; if all the funds are on your side, you cannot receive payments.

In the example above, one option would be to close the channel between Bob and Carol and open a new one. However, this approach is not cost-effective since both closing and opening channels require on-chain transactions, which incur Bitcoin miner fees. The primary goal of the Lightning Network is to reduce on-chain operations and move as many transactions as possible into off-chain channels. If millions of channels were opened and closed on the Lightning Network every day, the Bitcoin blockchain would become congested, and miner fees would skyrocket.

To address this, the Bitcoin community has proposed several innovative solutions to solve the liquidity distribution problem:

Submarine Swap (submarine swap)

In simple terms, Submarine Swap allows users to send BTC from their channels to an exchange service within the Lightning Network. In return, the exchange service sends an equivalent amount of BTC to a specified receiving address on the Bitcoin blockchain, or vice versa: users can send on-chain BTC to the exchange service, which then sends BTC from the channel to the designated receiving node. Although this process involves the exchange service, it is completely trustless thanks to HTLC (Hash Time-Locked Contracts).

Submarine Swap has also inspired many subsequent innovations, such as the PeerSwap channel balance adjustment protocol, which allows users to directly perform submarine swaps with their channel counterparts. In the example above, Carol can act as the exchange service. Bob transfers on-chain BTC to Carol, and in return, Carol pays Bob the equivalent amount of BTC from the channel.

Specifically, the process works as follows:

1. Bob generates a secret value R (preimage) and its hash H.
2. Bob creates an HTLC on the Bitcoin blockchain using hash H: he will pay Carol 10,000 satoshis, provided he can reveal secret R within 5 blocks; otherwise, the funds will return to Bob.
3. Carol creates an HTLC in his payment channel with Bob using the same hash H: he will pay Bob 10,000 satoshis from the channel, provided he can reveal secret R within 4 blocks; otherwise, the funds will return to Carol (for simplicity, we are not considering any service fees charged by the exchange service).
4. Bob uses the secret R to unlock the HTLC in the channel and takes 10,000 satoshis.
5. After Bob withdraws the funds, Carol also knows the secret R and uses it to unlock the HTLC on the Bitcoin blockchain to withdraw 10,000 satoshis.

Compared to closing the channel and opening a new one, Submarine Swap involves only one on-chain transaction, making it more economical and entirely trustless.

Splicing

Channel splicing is an on-chain rebalancing method where a node closes a channel and then opens a new channel in a single transaction, thereby changing the balance locked in the channel. When a node locks in more funds through this process, it is referred to as “splice in”; if it reduces the locked funds, it is called “splice out.” In the example above, the channel between Bob and Carol can be extended through channel splicing.

Channel splicing is much more convenient than using two transactions to close and reopen a channel. However, it still requires broadcasting the transaction across the network, paying on-chain miner fees, and waiting for the transaction to be confirmed.

Multi-Path Payment (MPP)

Multi-path payments allow a payment to be split into several parts, which can be simultaneously held or routed through different channels. For example, if Alice needs to pay Carol 10,000 satoshis and Bob can no longer route payments, Alice can pay Carol 6,000 satoshis through routing node David and 4,000 satoshis through routing node Eva. This way, Alice’s 10,000 satoshis payment can be completed using multi-path payments.

The original intention of multi-path payment technology is to overcome the limitations of single-path payments, allowing larger payments to be delivered by splitting them into smaller parts. For instance, a Lightning Network transaction of 1 BTC can be divided into 100 transactions of 0.01 BTC each. Multi-path payments benefit network decentralization and transaction privacy. In terms of security, the atomic multi-path payment (AMP) technology ensures that if one path fails to complete the payment, then all payments will fail, preventing confusion and fraud.

Additionally, in the Lightning Network, large transactions can also be completed through Wumbo channels. Wumbo channels remove the limit on the amount of Bitcoin a regular Lightning channel can hold (0.1667 BTC), allowing nodes to have higher channel capacities and thus support larger transactions.

Conclusion

Liquidity is one of the main factors constraining the development of the Lightning Network. By lowering the barriers to setting up and maintaining Lightning Network nodes and introducing additional incentive mechanisms, the network can address the issue of insufficient liquidity. Solutions like Submarine Swap, channel splicing, and multi-path payments also contribute to addressing liquidity distribution within the network.

In addition to these solutions, the Bitcoin community has proposed other strategies to optimize network liquidity, including Lightning Pool (a channel rental auction market), Liquidity Advertisement (a channel rental scheme), and loop payments (where a node pays itself through a loop formed by payment channels to achieve off-chain rebalancing).

Liquidity management is undoubtedly a complex undertaking for the Lightning Network. However, with continuous technological advancements and ongoing community efforts, we have reason to believe that these liquidity challenges will eventually be resolved.

Disclaimer：

1. This article is reprinted from [ RGB++ Fans]. All copyrights belong to the original author [Byte CKB]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.