Builder's Guide
  • Welcome to the Builder's Guide to the LND Galaxy!
  • The Lightning Network
    • Overview
    • Payment Channels
      • Lifecycle of a Payment Channel
      • Watchtowers
      • Understanding Sweeping
      • Etymology
    • The Gossip Network
      • Identifying Good Peers on the Lightning Network
    • Pathfinding
      • Finding routes in the Lightning Network
      • Channel Fees
      • Multipath Payments (MPP)
    • Lightning Network Invoices
      • Understanding Lightning Invoices
    • Making Payments
      • The Payment Cycle
      • Timelocks
      • ⭐Hashed Timelock Contract (HTLC)
      • Payment Etymology
      • ⭐What Makes a Good Routing Node
      • Understanding Submarine Swaps
      • Instant Submarine Swaps
    • Liquidity
      • ⭐Understanding Liquidity
      • Managing Liquidity on the Lightning Network
      • Liquidity Management for Lightning Merchants
      • How to Get Inbound Capacity on the Lightning Network
      • Lightning Service Provider
    • L402: Lightning HTTP 402 Protocol
      • Macaroons
      • L402
      • 📋Protocol Specification
      • Implementations and Links
    • Taproot Assets
      • Taproot Assets Protocol
      • Taproot Assets on Lightning
      • Edge Nodes
      • Taproot Assets Trustless Swap
      • FAQ
      • Glossary
  • Lightning Network Tools
    • LND
      • 🛠️Get Started
      • lnd.conf
      • First Steps With LND
      • Wallet Management
      • Sending Payments
      • Atomic Multi-path Payments (AMP)
      • Receiving Payments
      • Unconfirmed Bitcoin Transactions
      • Channel Fees
      • Inbound Channel Fees
      • Macaroons
      • Configuring Watchtowers
      • Pathfinding
      • Blinded Paths
      • Key Import
      • Secure Your Lightning Network Node
      • Configuration of a Routing Node
      • Quick Tor Setup
      • Configuring Tor
      • Enable ‘Neutrino mode’ in Bitcoin Core
      • Send Messages With Keysend
      • Partially Signed Bitcoin Transactions
      • Bulk onchain actions with PSBTs
      • Sweeper
      • Debugging LND
      • Fuzzing LND
      • LND API documentation
      • Channel Acceptor
      • RPC Middleware Interceptor
      • HTLC Interceptor
      • NAT Traversal
      • Recovery: Planning for Failure
      • Migrating LND
      • Disaster recovery
      • Contribute to LND
    • Lightning Terminal
      • What is Lightning Terminal?
      • 🛠️Get litd
      • Run litd
      • Integrating litd
      • Demo: Litd Speed Run
      • Connect to Terminal
      • Recommended Channels
      • Rankings
      • Health Checks
      • Liquidity Report
      • Opening Lightning Network Channels
      • Managing Channel Liquidity
      • Autofees
      • AutoOpen
      • LND Accounts
      • Loop and Lightning Terminal
      • Loop Fees
      • Pool and Lightning Terminal
      • Command Line Interface
      • Troubleshooting
      • Lightning Node Connect: Under the hood
      • LNC Node Package
      • LITD API Documentation
      • Privacy and Security
      • Privacy Policy
      • Terms of Use
    • Loop
      • 🛠️Get Started
      • The Loop CLI
      • Autoloop
      • Static Loop In Addresses
      • Instant Loop Outs
      • Peer with Loop
      • Loop API Documentation
    • Pool
      • Overview
      • Quickstart
      • 🛠️Installation
      • First Steps
      • Accounts
      • Orders and Asks
      • Sidecar Channels
      • Zero-confirmation Channels
      • Channel Leases
      • Batch Execution
      • Account Recovery
      • Pool API Documentation
      • FAQs
    • Taproot Assets
      • Get Started
      • First Steps
      • Taproot Assets Channels
      • Asset Decimal Display
      • Become an Edge Node
      • RFQ
      • Collectibles
      • Universes
      • Asset Loop
      • Debugging Tapd
      • Multisignature
      • Minting Assets With an External Signer
      • Lightning Polar
      • Operational Safety Guidelines
      • Taproot Assets API Documentation
    • Aperture
      • ⚒️Get Aperture
      • LNC Backend
      • LNC Mailbox
      • Pricing
    • Faraday
      • 🛠️Get Started
      • The Faraday CLI
      • Faraday API Documentation
  • LAPPs
    • Guides
      • Use Polar to Build Your First LAPP
        • Setup: Local Cluster with Polar
        • Setup: Run the Completed App
        • Setup: Run the App Without LND
      • Add Features
        • Feature 1: Connect to LND
        • Feature 2: Display Node Alias and Balance
        • Feature 3: Sign and Verify Posts
        • Feature 4: Modify Upvote Action
      • Make Your own LNC-powered Application
    • Next Steps
  • Community Resources
    • Resource List
    • Lightning Bulb 💡
    • Glossary
    • FAQ
Powered by GitBook
On this page
  • Goals of this guide
  • Inbound liquidity
  • Acquiring inbound liquidity
  • Liquidity shifts as payments are received
  • Maintaining inbound liquidity
  • Identifying good peers
  • Summary

Was this helpful?

  1. The Lightning Network
  2. Liquidity

Liquidity Management for Lightning Merchants

Learn how to manage your channels as a merchant receiving payments on the Lightning Network

PreviousManaging Liquidity on the Lightning NetworkNextHow to Get Inbound Capacity on the Lightning Network

Last updated 1 year ago

Was this helpful?

Payments on the Lightning Network are settled instantly at a low cost for the sender and typically no cost for the receiver. Anyone can run a Lightning Network node at home or in the cloud, and there is plenty of tooling available to integrate a Lightning node into other systems, for instance, by using BTCPay or LNbits.

When running your own node to receive payments,, the obligation to manage channel liquidity falls onto you, the merchant. The concept of channel liquidity is novel to system administrators and extends beyond “keeping the lights on” and regularly updating the software. However, with Lightning Labs tooling, you can manage liquidity as easily as possible including automation and simple UX, which we’ll outline in this guide.

Goals of this guide

As a merchant, you want payments to your node to be as reliable as possible. Not being able to find a route can cause unnecessary user frustration, which in the worst case leads the customers to look elsewhere, or choose a payment option less advantageous for you. Due to the architecture of the Lightning Network, as a merchant, you may not even know if users are having issues paying you unless they file a report. Failed payments from users are not easily distinguishable from payments that were never attempted. Therefore, it is critical to ensure that you have sufficient liquidity in the right place at the right time.

Payments to your node should also be cheap, as excessive routing costs can make your service appear less valuable to the consumer. Typically, payment failures and high fees typically go hand in hand for mismanaged nodes.

Using the guide below, you will learn how to understand and acquire inbound liquidity, maintain it and automate the process.

Inbound liquidity

The Lightning Network relies on payment channels to route funds between participants. The size of these payment channels is fixed at the time of their creation, defining the total capacity of a channel. For instance, a 10 BTC channel can at maximum facilitate a transfer of 10 BTC.

Inbound liquidity describes the portion of that capacity that is held by your peer and can be forwarded to your side as part of a payment.

Acquiring inbound liquidity

To be able to receive payments, a merchant has to acquire inbound liquidity. There are multiple ways of achieving this.

  1. Ask your clients! As a new merchant, the users most enthusiastic about Lightning payments might be able and willing to provide inbound capacity.

  2. Buy channels! There are market places like Pool where channels can be purchased, as well as dedicated Lightning Service Providers specializing in liquidity services.

  3. Push out payments! A merchant may also open channels themselves, then acquiring liquidity in these channels by swapping funds onchain, making Lightning payments themselves or selling Bitcoin on an exchange that supports Lightning Network deposits. This mechanism works best in the long run and is explained in more detail below.

Liquidity shifts as payments are received

When a payment is made through a channel, the balances of the channel shift.

In the above example, Bob is opening a channel to Alice over 10 million satoshis, or 0.1 BTC. The total capacity of the channel will forever be 0.1 BTC, although Bob can open another channel later if needed.

Once the channel active, Alice at first has 10 million satoshis in inbound liquidity, meaning she will be able to receive payments of up to 10 million satoshis before the channel is depleted. This can be one payment, or 1 million payments of 10 satoshis.

Eventually, all funds will have moved to Alice’s side of the channel, and she can no longer receive payments through this channel.

Maintaining inbound liquidity

Repeatedly soliciting or buying new channels is costly, as channel peers expect to be compensated for their capital and the cost of opening and closing the channel.

Ideally, channels are reused, so the cost of opening the channel can be amortized over a longer period of time. This can be achieved by emptying channels. In the example above, Alice will need to “push out” funds through her channel with Bob to be able to receive payments again.

This can be achieved mainly in three ways:

  1. Make Lightning payments. In an ideal world, a merchant would be able to pay suppliers or staff the same way they receive payments from their clients. When channels are used in both directions, fees tend to be the lowest.

  2. Swap offchain funds for onchain funds, for instance using Lightning Loop. This option is preferable if the funds are to be held in Bitcoin, for example as a reserve or savings account. This process can be automated using Autoloop in the Lightning Terminal UI.

  3. If funds need to be converted to fiat currencies, this is ideally done through platforms that support Lightning Network deposits. This minimizes onchain fees and allows channels to be open longer.

Identifying good peers

Good peers are peers that most reliably and cheaply route payments to your node. As a rule of thumb, whatever channels deplete the quickest, these are your best peers.

Another metric of a good peer is your cost of pushing out payments. If a peer reliably routes payments to you, but charges significantly more to push out payments than other peers, you may deprioritize maintenance on their channel.

Summary

  • Avoid closing channels unless peers are offline or funds cannot be pushed out through the Lightning Network

  • Identify your good peers and regularly push payments out through their channel, either by making Lightning payments yourself or swap funds into your onchain wallet with Loop or Autoloop.

Read more: Using Autoloop to acquire inbound capacity.
Read more: Autoloop configuration
Read also: How to get inbound capacity on the Lightning Network
Channel capacity shifts as payments are made through the channel