According to the latest data from mempool, the Bitcoin Lightning Network currently has 12,389 nodes and 48,000 payment channels, with an overall channel capacity of 5,311.8 BTC.
The Lightning Network is a peer-to-peer liquidity network, and to achieve large-scale applications, significant increases in the number of nodes, channels, and channel capacity are necessary—potentially growing by hundreds or even thousands of times. So, how can we attract more nodes to join this network?
Firstly, it is crucial to lower the difficulty of setting up and maintaining Lightning Network nodes, enabling users without technical backgrounds to easily operate these nodes. In the Bitcoin ecosystem, several teams have introduced plug-and-play hardware devices, such as Umbrel's hardware box, which supports running Bitcoin Lightning Network nodes. Additionally, Fi5Box not only supports the Bitcoin Lightning Network but can also run nodes for other Lightning Networks (like CKB's Fiber Network), providing users with a maintenance-free node solution.
Secondly, introducing additional incentive mechanisms is essential for promoting a positive feedback loop within the Lightning Network. Upon opening a channel, funds are locked. For example, if Alice wants to become a Lightning Service Provider (LSP), she needs to open channels with 100 individuals, locking 1 BTC per channel, which totals 100 BTC. These 100 BTC can only generate income when they are in circulation; if they remain static, no revenue is generated because the income for Lightning Network nodes primarily comes from transaction fees. The fee structure is calculated as "Base Fee + Fee Rate per Satoshi," where the base fee is a fixed charge for each transaction regardless of the transaction amount, and the fee rate is a percentage charged per Satoshi.
According to mempool data, the current average base fee for the Bitcoin Lightning Network is 950 mSat (0.95 Satoshi), with an average fee rate of 764 ppm (0.000764 Satoshi per Satoshi). This means that for a transaction amounting to 10,000 Satoshis (approximately 0.0001 BTC, currently around $6.50), the routing node receives less than 9 Satoshis in fees. Furthermore, the transaction volume in the Lightning Network is relatively low, with many transactions not requiring routing nodes (i.e., direct payment channels exist between the two parties). Consequently, many BTC holders prefer not to deposit BTC into the Lightning Network to earn fees but instead opt to lend on exchanges or participate in emerging projects' staking/restaking.
If more incentive mechanisms can be introduced to encourage users to run Lightning Network nodes or become LSPs, and to motivate BTC holders to deposit BTC into the Lightning Network for rewards, the issue of insufficient liquidity in the network may be resolved. As the Lightning Network becomes more practical, it will attract more users, increasing transaction volume and boosting routing node fee income, which will further incentivize more individuals to become LSPs—ultimately creating a positive cycle.
Currently, in the Bitcoin ecosystem, UTXO Stack has announced its transformation into a staking layer for the Lightning Network, enhancing liquidity and revenue models through a decentralized staking protocol. Additionally, UTXO Stack will introduce a token incentive mechanism to encourage users to stake BTC, thereby increasing the liquidity of payment channels in the Lightning Network.
Even if the overall liquidity shortfall is addressed, effectively allocating this liquidity remains a challenge.
For instance, consider Alice making a payment to Carol through a routing node, Bob. Initially, both Alice and Carol have 20,000 Satoshis in their channel, while Bob has 10,000 Satoshis in each of his channels. After several transactions, the distribution of funds in the channel changes (for simplicity, we will not consider the fees that Bob may charge). If Alice needs to make another payment to Carol in the near future, what can she do? At this point, Bob can no longer route the payment (i.e., he has no transferable funds in the channel with Carol), and he needs to rebalance his channels.
This situation is quite common among routing nodes in the Lightning Network. Node operators must constantly adjust liquidity between their channels. If a channel has no funds on your end, you cannot send payments; conversely, if all funds are concentrated on your end, you cannot receive payments.
In this example, one solution is to directly close the channel between Bob and Carol and reopen a new one. However, this method is not cost-effective, as closing and opening channels requires on-chain transactions, incurring Bitcoin miner fees. The original intention of the Lightning Network design is to minimize on-chain operations and conduct as many transactions off-chain as possible. If the Lightning Network has millions of channels needing to be opened and closed daily, the Bitcoin blockchain will face congestion, and miner fees will soar.
Consequently, the Bitcoin community has proposed several innovative solutions to address liquidity allocation issues:
In simple terms, Submarine Swap allows users to send BTC from their channel to a swap service provider in the Lightning Network, which in turn sends an equivalent amount of BTC to a receiving address on the Bitcoin blockchain, or vice versa. Users can send BTC from the blockchain to the swap provider, who then sends BTC from the channel to a specified receiving node. Although this process involves a swap service provider, it is trustless through the use of HTLCs (Hash Time-Locked Contracts).
Submarine Swap has also inspired several subsequent protocols, such as the channel balance adjustment protocol PeerSwap, which allows users to perform submarine swaps directly with their channel partners. In the example above, Carol can act as the swap service provider, where Bob transfers BTC from the blockchain to Carol, and Carol pays Bob the corresponding amount of BTC from the channel. The specific steps are as follows:
Bob creates an HTLC on the Bitcoin blockchain using hash H, paying 10,000 Satoshis to Carol, provided he can reveal secret R within 5 blocks; otherwise, the funds will revert to Bob.
Carol creates an HTLC in their payment channel using the same hash H, paying 10,000 Satoshis to Bob, conditioned on revealing secret R within 4 blocks; otherwise, the funds will revert to Carol (for simplicity, we will not consider the service fee for the swap provider).
Once Bob takes the funds, Carol also receives secret R, which he uses to unlock the HTLC on the Bitcoin blockchain and obtains 10,000 Satoshis.
Compared to closing a channel and reopening a new one, Submarine Swap involves only one on-chain transaction, making it more economical and trustless.
Splicing is an on-chain rebalancing method that allows nodes to close one channel and reopen another in a single transaction, thus adjusting the balance locked in the channel. If a node locks in more funds, this process is referred to as "splice in"; if it reduces the locked funds, it is called "splice out." In the previous example, the channel between Bob and Carol can be extended through splicing.
Multi-Path Payment (MPP) technology allows a single payment to be split into multiple parts, which can be transmitted simultaneously through different routes. For instance, if Alice needs to pay Carol 10,000 Satoshis, even if Bob can no longer route the payment, Alice can still pay 6,000 Satoshis to Carol through routing node David and 4,000 Satoshis through routing node Eva, successfully completing the 10,000 Satoshi transaction.
The primary design intention of multi-path payments is to overcome the limitations of single-path payments, enabling larger amounts to be paid by dividing them into smaller parts. For example, a 1 BTC transaction on the Lightning Network can be broken down into 100 transactions of 0.01 BTC each. Multi-path payments not only contribute to the decentralization of the network and the protection of transaction privacy, but they also enhance security. The Atomic Multi-Path Payment (AMP) technology ensures that if one path fails to complete the payment, all related payments will also fail, thereby avoiding confusion and fraud.
Moreover, in the Lightning Network, large transactions can be facilitated not only through multi-path payments but also through Wumbo channels. Wumbo channels eliminate the traditional Bitcoin limit for Lightning channels (0.1667 BTC), allowing nodes to have larger channel capacities and thus supporting high-value transactions.
Liquidity is one of the key 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, we can help address the issue of insufficient liquidity in the network. Solutions such as Submarine Swap, splicing, and multi-path payments provide effective strategies for liquidity allocation.
In addition to these solutions, the Bitcoin community has proposed other innovative methods, such as Lightning Pool (a channel rental auction market), Liquidity Advertisement (channel rental schemes), and loop payments (off-chain rebalancing through payment channel loops), to further optimize network liquidity.
Liquidity management is undoubtedly a complex challenge facing the Lightning Network, but with ongoing technological advancements and community efforts, there is good reason to believe that these liquidity issues will ultimately be resolved.