Skip to content

Commit eecb9d7

Browse files
Leo Weesegitbook-bot
Leo Weese
authored andcommitted
GITBOOK-388: change request with no subject merged in GitBook
1 parent 60be160 commit eecb9d7

File tree

3 files changed

+34
-0
lines changed

3 files changed

+34
-0
lines changed
Loading

SUMMARY.md

+1
Original file line numberDiff line numberDiff line change
@@ -86,6 +86,7 @@
8686
* [Connect to Terminal](lightning-network-tools/lightning-terminal/connect.md)
8787
* [Recommended Channels](lightning-network-tools/lightning-terminal/recommended-channels.md)
8888
* [Health Checks](lightning-network-tools/lightning-terminal/health-checks.md)
89+
* [Liquidity Report](lightning-network-tools/lightning-terminal/liquidity-report.md)
8990
* [Opening Lightning Network Channels](lightning-network-tools/lightning-terminal/opening-channels.md)
9091
* [Managing Channel Liquidity](lightning-network-tools/lightning-terminal/channel-liquidity.md)
9192
* [Autofees](lightning-network-tools/lightning-terminal/autofees.md)
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,33 @@
1+
---
2+
description: >-
3+
Lightning Terminal Liquidity reports provide node operators with a quick view
4+
over their inbound capacity
5+
---
6+
7+
# Liquidity Report
8+
9+
Inbound liquidity, or inbound capacity, refers to the ability of a node to receive Lightning payments. This inbound liquidity comes at a cost, charged to the payer in the form of a fee rate. As inbound liquidity depletes, peers raise their fees, and finding a path becomes more difficult as the payer has to attempt more routes before their payment succeeds.
10+
11+
[Read more: Understanding Liquidity](../../the-lightning-network/liquidity/understanding-liquidity.md)
12+
13+
As a merchant, plentiful and economical inbound capacity is an important key to successfully accepting Lightning payments. For routing nodes too, inbound capacity is a determining factor in your ability to route payments
14+
15+
In [Lightning Terminal](./), navigate to “Loop” and click on “Liquidity Report” on the top right side to view your node’s liquidity report. For various simulated payment sizes, you can see the estimated fee somebody paying to your node would have to pay.
16+
17+
The “Routable Liquidity” graph shows how many channels you can get paid through at several fee levels. It can be displayed as an ordinary or cumulative histogram.
18+
19+
[Read more: How to get Inbound Capacity](../../the-lightning-network/liquidity/how-to-get-inbound-capacity-on-the-lightning-network.md)
20+
21+
The “Routable Inbound” graph places your channels into various fee buckets, and shows for each fee bucket how many channels have liquidity available.
22+
23+
24+
25+
<figure><img src="../../.gitbook/assets/Screenshot from 2023-11-17 21-28-57.png" alt=""><figcaption><p>Sample liquidity report</p></figcaption></figure>
26+
27+
Don’t rely on other participants of the Lightning Network to remotely detect your liquidity needs. Monitor your node’s inbound capacity and fees and actively manage your node’s liquidity. Attempt to free up additional capacity first, for instance through [Lightning Loop](../loop/), and only close channels that can’t be empty otherwise. Maximize your percentage of channels that have inbound capacity, rather than maximize the number of your channels. Keep channels open and allow their cost to be amortized over multiple cycles, rather than closing them after their liquidity has been depleted.
28+
29+
Needs Attention: Some fee ranges may be marked in red, indicating that no channels in that fee range have sufficient inbound capacity left. You may empty these channels by pushing satoshis out, for example into cold storage using Lightning Loop, or alternatively close them.
30+
31+
[Read more: Liquidity Management for Lightning Merchants](../../the-lightning-network/liquidity/liquidity-management-for-lightning-merchants.md)
32+
33+
Lightning Terminal’s Liquidity Report for now only takes into account local information, that is information gathered directly from your node. It visualizes available inbound capacity ordered by their remote fee, but does not take into account the quality of the inbound capacity. Channels might not always be useful for routing or receiving payments, for example in cases where the peer themselves lacks inbound capacity.

0 commit comments

Comments
 (0)