In previous popular science articles, we briefly introduced core concepts related to the Lightning Network, such as payment channels, multi-hop routing, and HTLC.
We mentioned that to make transfers in the Lightning Network, it often requires building paths through multiple intermediary nodes, and the available balance of these intermediary nodes is often limited, which ultimately affects the success rate of payments. To ensure that the nodes in the path have sufficient funds and enhance user experience, liquidity management solutions need to be implemented. However, to deeply understand the liquidity management issue, we first need to introduce a few basic concepts, such as local balance and remote balance, inbound and outbound capacity.
In the past, we mentioned that the basic components of the Lightning Network are nodes and channels, the latter being off-chain 1-to-1 transfer facilities built on the Bitcoin network. When a channel is initialized, both parties will transfer some money as an initial balance, the balance on your side is called "local balance," and the balance on your counterparty's side is called "remote balance." The local balance determines how much you can transfer to your counterparty, limiting your payment capability or "outbound capacity," while the remote balance determines how much your counterparty can transfer to you, limiting your "inbound capacity" or receiving capability.
Although the balances of both parties can change frequently before the channel is closed, the total capacity of the channel, which is the sum of both balances, cannot change unless you completely restart the channel or inject funds through "channel splicing."
(This image shows the balances of you and Robert, with your local balance at 5, remote balance at 3, and the overall capacity of the channel at 8)
After understanding the above basic concepts, let's look at what liquidity management in the Lightning Network aims to solve. The simplified node connection diagram below shows that you (in the lower left corner) are only connected to one node, LNTop. Since your remote balance is 3, you can receive a maximum of 3 dollars in transfers. If Sophie wants to transfer 1 dollar to you, it will fail due to insufficient available balance of the intermediary node to LNTop (indicated by the red box, where the outbound capacity of that node to LNTop is 0).
It can be said that channel capacity is one of the serious problems faced by the Lightning Network in its early stages. If liquidity is more evenly distributed across the network, such issues will be effectively alleviated, and the solutions to this are often collectively referred to as "liquidity management," such as connecting clients to multiple liquidity-rich nodes through a rental market (Lighting Pool), opening/closing new channels as needed, or introducing channel splicing, rebalancing, etc., to adjust balances in channels on-chain or off-chain.
Currently, some wallet clients also provide automated channel management features, intelligently managing channels based on user payment behavior and network conditions to ensure sufficient liquidity for transfers. New users connecting to the Lightning Network can also adopt a "one-way funding" model, where only the counterparty funds the channel, and the user does not fund it during initialization, thus reducing the user's economic cost, but at the cost of having no outbound capacity for external payments initially.
Next, we will provide a more detailed popular science explanation of common liquidity management techniques in the Lightning Network. First, let’s understand channel leasing, which primarily addresses the "inbound capacity" issue of nodes, meaning when others want to transfer money to you, you need to ensure that they can successfully build a payment path, which requires each node in the path to have sufficient available balance/outbound capacity. The previously mentioned scenario of path failure stems from insufficient liquidity in the channels established by certain intermediary nodes with other nodes.
Building channels incurs costs, as participants often have to lock up a portion of their funds, resulting in opportunity costs. The so-called channel leasing is based on market mechanisms allowing node operators to trade directly, enabling liquidity-rich nodes to actively build channels for other nodes through a "leasing" system. For example, if you are a merchant needing to receive money from others at any time, with a high demand for capacity, your "receiving capability" needs to exceed 200 BTC within a day.
Thus, you reach an agreement with four large nodes through Lighting Pool, and these four nodes establish a 24-hour channel with you, each locking in 50 BTC, providing you with 50 BTC of remote balance, so your receiving capability in each channel will reach 50 BTC. If someone wants to transfer money to you, they can use any one of these four nodes as an intermediary to build the payment path.
(On 1ml.com, we can see several well-known Lightning Network node operators, these nodes have surplus funds and have established multiple channels with other nodes, allowing them to earn income through leasing liquidity)
In addition to the aforementioned leasing pool, there is also liquidity advertisement, where liquidity providers can broadcast their pricing and channel duration using gossip messages from Lightning nodes, and nodes accepting the pricing can open channels with them. Such leasing-based solutions often incorporate a margin system to prevent one party from suddenly defaulting.
Currently, developers of the Lightning Network, such as Lighting Labs and Fiber, are trying to optimize liquidity leasing scenarios under one-way funding, for instance, Fiber plans to introduce a liquidity payment system based on CKB smart contract functionality, where designated LSP service provider nodes will establish channels with users and provide them with inbound capacity for free for a period, meeting their receiving needs. After users receive some money, the contract will automatically withdraw costs from it, and liquidity staking mechanisms related to such scenarios are also under discussion.
Generally speaking, channel leasing is often used to solve the problem of establishing connections between nodes and obtaining inbound liquidity, while the following channel splicing solution will inject funds/withdraw directly through on-chain operations, changing the total balance of both parties in the channel. Normally, opening and closing a channel requires 2/2 signatures, where both parties redistribute the jointly owned on-chain assets, but in early Lightning Network solutions, once a channel is opened, the total balance in the channel cannot be changed unless it is closed and restarted.
Channel splicing is a later proposed solution that allows for the direct on-chain reorganization and updating of UTXOs jointly controlled by both parties without closing existing channels. For example, new assets can be added to the existing assets for joint control by participants, thereby changing the total balance in the channel. The diagram below briefly outlines this idea, where the left side shows the on-chain assets (UTXO1) corresponding to the old channel, controlled by Alice and Bob's multi-signature. Afterward, both parties initiate channel splicing to add another asset (UTXO2) for joint management, ultimately increasing the amount of assets (UTXO3) that both parties can jointly control, thus increasing capacity.
Channel splicing can also be used to reduce excess funds in a channel, transferring temporarily idle assets out of the channel to improve capital utilization efficiency. Compared to the traditional method of closing/restarting a channel, which requires two on-chain interactions, channel splicing only requires a single on-chain operation, significantly reducing costs. Despite the clear advantages of channel splicing, due to historical reasons, this solution has not fully matured, and its widespread adoption will still take time.
After understanding channel splicing, we continue to introduce the idea of channel rebalancing, which is also a means of adjusting off-chain balances within different channels without closing the channel or changing the total capacity of the channel (ignoring fees). Suppose you are running a Lightning Network client and have established a total of three payment channels with other nodes:
- Channel 1: Established with node X, total capacity of 1 BTC
- Channel 2: Established with node Y, total capacity of 0.5 BTC
- Channel 3: Established with node Z, total capacity of 0.5 BTC
The fund distribution in each channel is as follows:
- Channel 1: Your local balance: 0.9 BTC, remote balance: 0.1 BTC
- Channel 2: Your local balance: 0.1 BTC, remote balance: 0.4 BTC
- Channel 3: Your local balance: 0.1 BTC, remote balance: 0.4 BTC
The current problem is that in channels 2 and 3, your outbound capacity is insufficient, with a maximum transfer of 0.1 BTC to your counterparty, which cannot meet the demand for large transfers. Meanwhile, channel 1 has excess outbound capacity of 0.9 BTC, but you cannot use that much in the short term. Clearly, the best solution is to move the surplus funds from channel 1 to the other two channels. Therefore, you plan to transfer 0.4 BTC from the local balance of channel 1 to channel 2 and 0.4 BTC to channel 3. To achieve this, you need to complete two circular payments.
The specific operation method is shown in the above diagram, where you can directly transfer 0.8 BTC to node X, which then transfers 0.4 BTC to Y and Z respectively, and then Y and Z transfer 0.4 BTC back to you in channels 2 and 3, increasing your local balance, thus providing you with sufficient available funds to meet future large transfer needs.
Observing the above diagram, it is not difficult to see that the essence of circular payments is that you are transferring funds to yourself, moving your balances between different channels to achieve your desired overall balance distribution, but this method alone cannot arbitrarily increase the total balance of either party in any channel. Additionally, its implementation relies on the following assumptions: X has sufficient available funds for Y and Z, in other words, circular payments often require relevant nodes to have a certain liquidity reserve in advance.
Circular payments are one implementation of the channel rebalancing idea, and rebalancing solutions can also be combined with other methods in practice, such as submarine swaps. Next, let’s introduce submarine swaps, the core idea of which is to swap on-chain and off-chain funds without closing the channel, using methods like HTLC.
The simplest submarine swap scenario is to recharge the channel on-chain. Suppose Alice has established a 1-to-1 channel with Bob, but after a while, Alice's local balance is nearly exhausted, and she can no longer make payments. At this point, Alice needs to inject more funds, which would require closing and restarting the channel, but this channel is leased, and closing it early is not cost-effective. So what should she do?
If using a submarine swap, the process would be relatively easy, but it requires HTLC. First, Alice can generate a random number R and hash it to get H(R). Then, Alice can send BTC to Bob's address on-chain, with the unlocking condition restricted by HTLC. Bob must know the pre-image R corresponding to H(R) to unlock these bitcoins on-chain.
Bob trades with Alice off-chain through HTLC, but in reverse: Alice must present R to unlock the money Bob paid. As long as Alice presents the value of R, Bob can use it to unlock the BTC locked by Alice on-chain. After this, Alice's local balance in the channel increases, while the on-chain asset balance equivalently decreases (ignoring fees), essentially a 1-to-1 swap (the above explanation simplifies the principle and does not strictly follow the conventional order of submarine swaps; in practice, most of the time one party first creates HTLC off-chain, and the other party then creates a symmetric HTLC on-chain).
The above scenario is primarily used to swap on-chain assets for off-chain balances. By adjusting the direction of operations for Alice and Bob, it can be converted into a withdrawal operation, turning off-chain balances into on-chain assets. Submarine swaps ensure security through the combination of HTLC and time locks, meaning even if the other party suddenly backs out, the money locked in HTLC remains safe, as the other party does not know the key to unlock HTLC. Once the time lock expires, you can reclaim your principal.
However, it is important to note that while your principal will not be stolen in the above scenario, one party must create HTLC on-chain to lock funds, which will inevitably incur fee losses. If the other party backs out, it will have a certain impact on you. To address these issues, submarine swaps often have some auxiliary measures, such as prepayments, reputation systems, and other punitive measures.
To summarize, the core idea of submarine swaps is to enable flexible swapping of on-chain and off-chain assets, which can lead to better liquidity adjustment measures following the idea of channel rebalancing. Here’s a simple example:
Suppose you are running a node and have opened multiple channels, with some channels having surplus local balances while others have severely insufficient local balances, affecting your payment capabilities. You want to balance the fund distribution across channels without closing any channels; submarine swaps can be a good solution. You can choose a channel with excess local balance and use submarine swaps to transfer funds on-chain, then inject the on-chain assets into the target channel through another submarine swap, all without closing any channels.
However, summarizing the above knowledge points, it is not difficult to find that submarine swaps, channel splicing, and liquidity adjustment operations all leave operational traces on-chain, leading to transaction fees. If such operations are performed frequently, it will inevitably put pressure on the user's economic costs and UX. Since the Bitcoin Lightning Network relies on the BTC mainnet, frequent on-chain interactions are not realistic, while Fiber based on CKB faces relatively less pressure in this regard, providing a smoother experience in liquidity management. Nevertheless, both the Lightning Network and Fiber are conducting in-depth research on more innovative liquidity solutions, and in the future, they may explore more suitable paths through active collaboration with project teams like Mercury Layer.
📖 Recommended Reading: