Liquidity is a core concept to understand when working with the lightning network, although tricky. Ideally, we are able to design products that are easy enough to use so that users do not need to concern themselves with liquidity. However, product designers need to understand liquidity in order to build effectively on lightning.
Put simply, liquidity on the lightning network is the ability to send or receive bitcoin. In the context of an individual user, liquidity is a measurement of their wallet’s ability to send and receive bitcoin over lightning.
Inbound liquidity is the amount of bitcoin that the user is able to receive over a lightning channel. Outbound liquidity is the amount of bitcoin that the user is able to send over a lightning channel.
Receiving bitcoin decreases the user’s inbound liquidity and increases their outbound liquidity. On the other hand, sending bitcoin decreases their outbound liquidity and increases their inbound liquidity.
Sending and receiving
If your app offers the user visibility into the channel management process, you might consider using the term “receive limit” in place of “inbound liquidity” and “send limit” in place of “outbound liquidity”.
Liquidity directly impacts the user experience. If a user has no outbound liquidity, they can not send bitcoin over lightning. Conversely, if a user has no inbound liquidity, they can not receive bitcoin over lightning.
Sourcing inbound liquidity is very important for funding and onboarding a user to a lightning wallet. Imagine if you were brand new to bitcoin. You download your first wallet, a lightning wallet. Because there is no inbound liquidity, you can not receive any bitcoin. Would you understand what to do next? Would the wallet still seem useful to you?
Helping the user to find inbound liquidity, or providing it as part of your application, will remove friction from onboarding and make their overall experience with bitcoin easier.
Before going further, it’s important to make a distinction between different use cases for lightning nodes. It is difficult to make firm categories for lightning nodes. However, we can categorize them very generally for our purposes within the Design Guide. Here are some very broad examples of different use cases.
Routing Node Operator
What is their incentive?
Rachel operates a lightning node so she can earn routing fees for routing payments or lease inbound liquidity to other lightning nodes
Miguel operates a lightning node so he can receive payments at his business
Wagner uses a mobile bitcoin wallet that supports lightning to send and receive payments
What's their role in the lightning network?
Rachel acts more like a hub for routing other's lightning payments, and is rarely the origin or endpoint
Miguel is usually the endpoint for lightning payments
Wagner is sometimes the origin and sometimes the endpoint for lightning payments
Where does the node run?
Runs on dedicated hardware, like a Raspberry Pi or rack-mounted server
Runs on a cloud service provider
Runs on Wagner's phone
When is the node online?
Only when Wagner opens his mobile wallet
How many lightning channels?
How much liquidity?
Where does the liquidity come from?
Liquidity is self-funded
Usually sourced externally (from an LSP, for example)
Usually sourced externally (from an LSP, for example)
How much do they know about lightning?
Rachel is a lightning node operator and is very cognizant of every decision she makes with her node
Miguel knows enough about operating a node to make his business function
Wagner is not even aware that his phone has a lightning node on it
Currently, most of the thinking in the Design Guide is focused on mobile wallet users such as Wagner. However, it is helpful to understand that routing nodes play a very important role in getting user funds across the lightning network.
The following examples are designed to help you understand how liquidity works on the lightning network.
Lori and Lamar, two routing node operators, open a channel together. Lori initiates the channel opening with 1,000,000 sats. This is the amount she makes available for transactions in the channel. Her initial outbound liquidity is the full amount of 1,000,000 sats, and her initial inbound liquidity is 0 sats (since Lamar has not committed any sats to the channel).
Suppose Lori routes a 100,000 sats payment through the channel. Her outbound liquidity is now 900,000 sats and her inbound liquidity is 100,000 sats. (Lamar’s liquidity is the inverse: he has outbound liquidity of 100,000 sats).
The liquidity of each user will continue to shift as Lori routes payments. For example, after she routes a 400,000 sats payment through the channel, her outbound liquidity is 500,000 sats and her inbound liquidity is 500,000 sats.
It works in the other direction, too. After Lamar routes a 200,000 sats payment through the channel, Lori’s outbound liquidity is 700,000 sats and her inbound liquidity is 300,000 sats.
Lori and Lamar can also change their liquidity by forming channels with other lightning nodes. For example, suppose Lindsay opens a channel with Lori for 2,000,000 sats. Lori’s total inbound liquidity has now increased to 2,300,000 sats, which is a combination of the inbound liquidity she has in the channel with Lindsay (2,000,000 sats) and the channel with Lamar (300,000 sats). Her outbound liquidity remains at 700,000 sats, which is a combination of the outbound liquidity she has in the channel with Lindsay (0 sats) and the channel with Lamar (700,000 sats).
Lori, Lamar, and Lindsay can open channels with as many other nodes as they like – the only limitation is how much bitcoin they are willing to put into lightning channels. This interconnected web of channels is effectively “the lightning network”.
Getting liquidity is not a one time issue on the lightning network. Routing nodes are constantly rebalancing their channels so that they have the right amount of liquidity in the right places. They do this by essentially sending themselves payments through the lightning network.
While the example thus far has focused on routing nodes, mobile nodes also fit into this scenario. Now that our node operator Lori has maintained a well-connected routing node, she can use her node to extend liquidity to mobile nodes.
This is a simplified overview of the lightning network. In reality, lightning is a fast-moving technology with a variety of different techniques for managing channels and liquidity. Recent innovations like dual-funded channels allow both channel partners to contribute to the liquidity from the start, and channel-splicing is a promising idea may help make channel balancing easier.
The above examples were designed to help you understand liquidity on a conceptual level. Ideally, the user of a mobile daily spending wallet never has to consider any of the liquidity sourcing that happens behind the scenes. Consider how you might design a bitcoin product that doesn’t require the user to understand lightning channel management.
Helping the user get inbound liquidity is probably more important than outbound liquidity for most use cases. Without inbound liquidity, the user can not receive bitcoin over lightning. This makes it very difficult for a new bitcoin user to receive their first bitcoin.
If the user does not have bitcoin in their wallet, they do not need outbound liquidity. On the other hand, if the user has inbound liquidity, then they are free to receive bitcoin, and then end up with outbound liquidity from the bitcoin they received.
One way to help your users receive inbound liquidity is through LSPs (Lightning Service Providers). You could run your own LSP service or integrate your product with an existing LSP.
One way to accomplish this could be through an instant channel open. If the user has bitcoin in an on-chain wallet, you could have them send bitcoin on-chain to the wallet, and then automatically use those funds to open a lightning channel with a well-connected node. An example of a wallet that does this is Blixt.
Another way to handle this would be through a swap-in service, where the user sends on-chain funds to an LSP and the LSP opens a channel for them. Read the LSP section to learn more. Phoenix is an example of a wallet that does this.
Helping the user get liquidity is just the beginning. As they continue to use their lightning wallet, the liquidity of their wallet’s lightning channels will shift. For example, what if they receive so much bitcoin that they max out their channel capacity?
Consider how you can help the user with channel management without them even knowing it’s happening. For example, you could automatically open a new channel for them if they try to create an invoice that exceeds their inbound capacity.
By combining the business incentives of an LSP, clever engineering, and good design, you can build a bitcoin product that makes using the lightning network very easy for the user.
A channel reserve is an amount that is set aside by each channel participant which ensures neither have ‘nothing at stake’ if a cheating attempt occurs. This reserve can not be spent, and is held aside for the entirety of the channels lifetime.
Channel reserves make cheating attempts less economical. When one channel party attempts to cheat the other and they are caught, a penalty transaction can be used to steal all the cheating parties bitcoin as punishment. Channel reserves makes it so cheating attempts always have something at stake making this less likely to occur.
The channel reserve amount is dynamic and unique to each channel participant. As defined in BOLT 2, the channel reserve amount dynamically trends towards 1% of the users local channel capacity. The channel reserve can not be lower than the current 354 sats minimum (dust limit).
So if a user has 100,000 sats of local capacity, their channel reserve will be 1,000 sats (1% of 100,000). The user can only spend 99,000 sats of the local capacity. The channel counterparty also has their own channel reserve which aims for a 1% reserve. This means the total channels capacity will have around 2% put aside and unspendable as a reserve.
As users send and receive funds, the channel reserve will dynamically adjust so that it’s always close to 1%.
If a user spends 10,000 sats of their 100,000 sats local capacity, their new channel reserve will dynamically adjust from 1,000 sats (1% of 100,000 sats) to 900 sats (1% of 90,000 sats). This amount adjusts upwards if the user receives funds.
Each additional channel has its own channel reserve. For example, a user with 20 channels may have more funds locked in reserve than a user with only one channel.