Overview
Inbound liquidity is the amount of bitcoin that a Lightning Network node can receive through its channels, determined by the funds held on the remote side of those channels. It is one of the most important yet least intuitive concepts for Lightning users and node operators. While on-chain Bitcoin allows anyone to receive any amount at any time by simply sharing an address, Lightning requires that sufficient funds already exist on the sender's side of a channel path leading to the receiver.
This asymmetry is a fundamental property of payment channels. When you open a channel and fund it entirely from your own wallet, all the capacity sits on your side — you can send up to the full channel amount, but you cannot receive anything until some of that balance moves to the other side through outgoing payments. For merchants and services that primarily receive payments, acquiring inbound liquidity is often the biggest operational challenge.
How Inbound Liquidity Works
Your Node's Channels:
Channel with Alice (1.0 BTC total):
┌──────────────────────────────────┐
│ Your side: 0.8 │ Alice's: 0.2 │
│ ████████████ │ ███ │
└──────────────────────────────────┘
Inbound from Alice: 0.2 BTC
Channel with Bob (0.5 BTC total):
┌──────────────────────────────────┐
│ Your side: 0.1 │ Bob's: 0.4 │
│ ██ │ ████████ │
└──────────────────────────────────┘
Inbound from Bob: 0.4 BTC
Channel with Carol (0.3 BTC total):
┌──────────────────────────────────┐
│ Your side: 0.3 │ Carol's: 0.0 │
│ ██████████ │ │
└──────────────────────────────────┘
Inbound from Carol: 0.0 BTC
Total inbound liquidity: 0.2 + 0.4 + 0.0 = 0.6 BTC
Maximum single payment receivable: 0.4 BTC (limited by largest channel)
Note that total inbound liquidity does not equal the maximum single payment you can receive. A single payment must fit through one channel (or be split via multi-path payments), so the largest individual channel's inbound balance is the practical single-payment limit.
The Inbound Liquidity Problem
New nodes and merchants face a bootstrapping challenge: to receive their first payment, they need inbound liquidity, but inbound liquidity typically comes from either spending through existing channels or having other nodes open channels to you. This creates a chicken-and-egg problem that the ecosystem has developed several solutions for.
New merchant node opens channels:
Merchant ──[1.0 BTC]──► Peer A
Merchant ──[0.5 BTC]──► Peer B
Outbound liquidity: 1.5 BTC (can send)
Inbound liquidity: 0.0 BTC (cannot receive!)
The merchant funded both channels, so all
capacity is on their side. No one can pay them.
Acquiring Inbound Liquidity
Several strategies exist for obtaining inbound liquidity:
Have others open channels to you: If your node is well-connected and offers competitive routing fees, other nodes may open channels to you because routing through your node is profitable for them.
Spend through your channels: Every outgoing payment moves balance to the remote side, converting outbound into inbound liquidity. Spending sats is the most natural way to acquire receive capacity.
Use a Lightning Service Provider: An LSP can open channels to your node with pre-funded remote balances, providing instant inbound liquidity in exchange for a fee.
Dual-funded channels: Dual-funded channels allow both parties to contribute funds at channel opening, ensuring some inbound liquidity exists from the start.
Liquidity swaps and marketplaces: Services and protocols allow nodes to buy inbound liquidity from willing providers, creating a market for channel capacity.
Rebalancing: Circular rebalancing or submarine swaps can shift existing capacity from outbound-heavy channels to inbound-heavy ones.
Why It Matters for Adoption
Inbound liquidity is arguably the biggest UX challenge facing Lightning adoption for merchants. A physical store that sets up a Lightning node cannot accept its first customer payment until it has inbound liquidity. This is why Lightning Service Providers and wallet solutions that abstract away liquidity management are critical infrastructure for bringing Lightning to everyday commerce.
Related Concepts
- Liquidity — the broader concept of fund distribution in Lightning channels
- Lightning Channel — the payment channel whose remote balance determines inbound liquidity
- Rebalancing (Lightning) — techniques for redistributing liquidity across channels
- Lightning Service Provider — entities that provide inbound liquidity as a service
- Dual-Funded Channel — a channel type that provides inbound liquidity from creation