In previous popular science articles, we have 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 must first introduce several basic concepts, such as Local and Remote Balance, Inbound and Outbound Capacity, etc.
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 the initial balance, the balance on your side is called "Local Balance," while the balance on your counterpart's side is called "Remote Balance." Local Balance determines how much you can transfer to your counterpart, limiting your payment capability or "Outbound Capacity," while Remote Balance determines how much your counterpart 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, your Local Balance is 5, Remote Balance is 3, and the overall capacity of the channel is 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 (red box, this node's Outbound Capacity to LNTop is 0).
It can be said that channel capacity is one of the serious problems encountered in the early stages of the Lightning Network. If liquidity is more evenly distributed across the network, such problems will be effectively alleviated, and solutions to this issue are often collectively referred to as "liquidity management," such as connecting clients to multiple liquidity-rich nodes through rental markets (Lighting Pool), opening/closing new channels as needed, or introducing channel splicing and rebalancing methods 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 channel counterpart funds the channel, and the user does not inject funds during channel initialization, thus reducing the user's economic cost, but at the cost of having no external payment capability/Outbound Capacity initially.
Next, we will provide a more detailed popular science explanation of common liquidity management techniques in the Lightning Network. First, let us understand channel leasing, which primarily addresses the "Inbound Capacity" issue of nodes, meaning that when others want to transfer money to you, you need to ensure that they can successfully establish 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 the idea of allowing node operators to trade directly through market mechanisms, enabling liquidity-rich nodes to actively build channels for other nodes through "leasing." For example, if you are a merchant needing to receive money from others at any time and have high requirements for the amount, your "receiving capacity" must 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 capacity 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 establish a 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 by leasing liquidity)
In addition to the aforementioned leasing pool, there is also Liquidity Advertisement, where liquidity providers can use gossip messages from Lightning nodes to announce their pricing and channel duration, and accepting nodes 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 example, 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 free Inbound Capacity for a period to meet their receiving needs. Once 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, redistributing the on-chain assets jointly owned by both parties, while in early Lightning Network solutions, once a channel is opened, the overall balance in the channel cannot be changed unless it is closed and restarted.
Channel splicing is a later proposed new solution that allows for the direct on-chain restructuring and updating of the UTXO jointly controlled by both parties without closing existing channels. For example, new assets can be added based on existing assets for both parties to jointly control, thereby changing the overall balance in the channel. The diagram below briefly outlines this idea, where the left side represents the on-chain assets (UTXO1) corresponding to the old channel, controlled by Alice and Bob's multi-signature, and then 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 the 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 take time.
After understanding channel splicing, we continue to introduce the idea of channel rebalancing, which is also a means to adjust 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 issue is that in channels 2 and 3, your Outbound Capacity is insufficient, and you can only transfer a maximum of 0.1 BTC to your counterpart, 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 approach is to transfer 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 both Y and Z, and then Y and Z each transfer 0.4 BTC back to you in channels 2 and 3, respectively, 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 across 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 assumption: 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 us introduce submarine swaps, the core idea of which is to swap on-chain and off-chain funds without closing the channel.
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 since this channel is leased, it is not cost-effective to close it early. 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 take its hash H(R). Later, 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 conducts a transaction with Alice in the off-chain channel 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. Afterward, Alice's Local Balance in the channel increases, while her 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, one party usually creates an HTLC off-chain first, and the other party then creates a symmetric HTLC on-chain).
The above scenario is mainly used for swapping 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 that even if the other party backs out midway and refuses to cooperate, the money locked in HTLC remains safe because 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 inevitably affect you. To address these issues, submarine swaps often have some auxiliary measures, such as prepayment and reputation systems as punitive measures.
To summarize, the core idea of submarine swaps is to achieve flexible exchanges between on-chain and off-chain assets, and following the idea of channel rebalancing can lead to better liquidity adjustment measures. Here is a simple example:
Suppose you are running a node and have opened multiple channels, with some channels having surplus Local Balances and others having severely insufficient Local Balances, affecting your payment capability. 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 excessive Local Balance and use submarine swaps to transfer funds on-chain, and then use submarine swaps to inject the on-chain assets into the target channel, 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 such as channel leasing will all leave operational traces on-chain, thus incurring 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: