Progress pill
The Tools of the Lightning Network

Managing Your Liquidity

Lightning Network Theory

Managing Your Liquidity

  • Liquidity Needs
  • Liquidity Management Strategies
  • The Loop Out Service
In this chapter, we will explore strategies for effectively managing liquidity on the Lightning Network. Liquidity management varies depending on the type of user and context. We will examine the main principles and existing techniques to gain a deeper understanding of how to optimize this management.

Liquidity Needs

There are three main user profiles on Lightning, each with specific liquidity needs:
  • The Payer: This is the one who makes payments. They require outgoing liquidity to transfer funds to other users. For example, this could be a consumer.
  • The Seller (or Payee): This is the one who receives payments. They need incoming liquidity to accept payments to their node. For example, this could be a business or an online store.
  • The Router: An intermediary node, often specialized in routing payments, that must optimize its liquidity in each channel to route as many payments as possible and earn fees.
These profiles are obviously not fixed; a user can switch between payer and payee depending on the transactions. For example, Bob could receive his salary on Lightning from his employer, placing him in the position of a "seller" requiring incoming liquidity. Subsequently, if he wants to use his salary to buy food, he becomes a "payer" and must then have outgoing liquidity.
To better understand, let's consider a simple network composed of three nodes: the buyer (Alice), the router (Suzie), and the seller (Bob).
Imagine that the buyer wants to send 30,000 sats to the seller and that the payment goes through the router's node. Each party must then have a minimum amount of liquidity in the direction of the payment:
  • The payer must have at least 30,000 satoshis on their side of the channel with the router.
  • The seller must have a channel where 30,000 satoshis are on the opposite side to be able to receive them.
  • The router must have 30,000 satoshis on the payer's side in their channel, and also 30,000 satoshis on their side in the channel with the seller, to be able to route the payment.

Liquidity Management Strategies

Payers must ensure to maintain sufficient liquidity on their side of the channels to guarantee outgoing liquidity. This proves to be relatively simple, as it is enough to open new Lightning channels to have this liquidity. Indeed, the initial funds locked in the multisig on-chain are entirely on the payer's side in the Lightning channel at the start. The payment capacity is thus assured as long as channels are opened with enough funds. When the outgoing liquidity is exhausted, it is enough to open new channels. On the other hand, for the seller, the task is more complex. To receive payments, they must have liquidity on the opposite side of their channels. Therefore, opening a channel is not enough; they must also make a payment through this channel to transfer the liquidity to the other side before they can receive payments themselves. For certain Lightning user profiles, such as merchants, there is a clear disproportion between what their node sends and what it receives, as the primary goal of a business is to collect more than it spends to generate a profit. Fortunately, for these users with specific incoming liquidity needs, several solutions exist:
  • Attracting channels: The merchant benefits from an advantage due to the volume of incoming payments expected on their node. Taking this into account, they can try to attract routing nodes that are seeking income from transaction fees and who might open channels towards them, thereby routing their payments and collecting the associated fees.
  • Liquidity movement: The seller can also open a channel and transfer some of the funds to the opposite side by making fictitious payments to another node, which will return the money in another way. We will explore this operation in the next part.
  • Triangular opening: Platforms exist for nodes wishing to open channels collaboratively, allowing each to benefit from immediate incoming and outgoing liquidity. For example, LightningNetwork+ offers this service. If Alice, Bob, and Suzie want to open a channel with 100,000 sats, they can agree on this platform for Alice to open a channel towards Bob, Bob towards Suzie, and Suzie towards Alice. In this way, each has 100,000 sats of both outgoing and incoming liquidity, while having only 100,000 sats locked up.
  • Buying channels: Services for renting Lightning channels also exist to obtain incoming liquidity, like Bitrefill Thor or Lightning Labs Pool. For example, Alice can buy a channel of one million satoshis to fund her node, allowing her to receive payments.
Finally, for routers, whose goal is to maximize the number of payments processed and the fees collected, they must:
  • Open well-funded channels with strategic nodes.
  • Regularly adjust the distribution of funds in the channels according to the network's needs.

The Loop Out Service

The Loop Out service, offered by Lightning Labs, enables the transfer of liquidity to the opposite side of the channel while reclaiming funds on the Bitcoin blockchain. For example, Alice sends 1 million satoshis via Lightning to a loop node, which then returns those funds to her in on-chain bitcoins. This balances her channel with 1 million satoshis on each side, optimizing her capacity to receive payments.
Therefore, this service enables incoming liquidity while reclaiming one's bitcoins on-chain, which helps to limit the immobilization of cash needed to accept payments with Lightning.
What should you take away from this chapter?
  • To send payments on Lightning, you must have enough liquidity on your side in your channels. To increase this sending capacity, simply open new channels.
  • To receive payments, you need to have liquidity on the opposite side in your channels. Increasing this receiving capacity is more complex, as it requires others to open channels towards you, or to make (fictitious or real) payments to move the liquidity to the other side.
  • Maintaining liquidity where desired can be even more challenging, depending on the use of the channels. That's why tools and services exist to help balance the channels as desired.
In the next chapter, I propose to review the most important concepts of this training.
Quiz
Quiz1/5
Why must a router maintain good liquidity distribution in its channels?