Why the Lightning Network Needs More Inbound Liquidity
The Lightning Network needs more inbound liquidity, primarily because of the legacy issue of "unilateral funding" — most channels are opened with funds from only one party, leaving the receiver without natural inbound capacity. And obtaining inbound liquidity requires additional on-chain fees and leasing costs, meaning users have to "pay to be able to receive money."
What Is Inbound Liquidity: Your "Receiving Limit"
On the Lightning Network, each channel has two balances: outbound balance is the money you have locked in the channel, which determines how much you can pay; inbound balance is the money the counterparty has locked in the channel, which determines how much you can receive.
To receive a certain amount, the counterparty's side of the channel must already have the corresponding balance. The total inbound liquidity represents the upper limit of payments you can receive on the network.
Why Inbound Liquidity Is Naturally Scarce
When most channels are opened, they are unilaterally funded — only the initiator deposits funds into the channel, while the other party puts in nothing. Once the channel is open, the initiator has the full outbound capacity, and the other side has the full inbound capacity.
The only way a new user can receive payments is for someone else to pre-fund their channel. But the question remains: why would anyone lock up funds just for your receiving capacity?
How This Problem Plays Out in Practice
Scenario A: You're a merchant or service provider.
Every time a customer pays you, your inbound balance decreases slightly (because the money "flows" from their side of the channel to yours). Once your inbound balance is exhausted, you can no longer receive payments until you spend the received funds or replenish your inbound capacity through other means.
Scenario B: You're an ordinary user trying to receive a transfer.
You open your wallet, generate a payment request, but the sender's payment fails — the wallet shows "insufficient channel capacity" or "receiving limit reached." The problem isn't your own balance; it's that the counterparty hasn't reserved any receiving space for you.
Ways to Add Inbound Liquidity and Their Costs
| Method | How It Works | Cost |
|---|---|---|
| Submarine Swap (Loop Out) | Move funds from your Lightning channel back to on-chain Bitcoin, freeing up inbound space | On-chain transaction fee + service fee |
| Channel Leasing | Pay a third party to inject funds into your channel | Leasing fee (block-based interest) |
| Dual-funded Channels | Both parties deposit funds when opening the channel, providing inbound capacity from the start | On-chain fee (paid only once) |
| Earn via Spending | Spend frequently; each outgoing payment "releases" inbound capacity from the counterparty | Routing fee |
On liquidity leasing markets like Lightning Pool, fees for inbound liquidity are determined by bids and asks, with a minimum lease period typically of 2,016 blocks (about two weeks).
Prerequisites
To supplement inbound liquidity through leasing or swaps, your wallet needs to support at least one of the following:
LND + Loop client: supports submarine swaps
Core Lightning: supports Liquidity Ads (channel leasing advertisements)
Wallets supporting dual-funded channels: obtain partial inbound capacity immediately upon channel opening
Common Failure Points
Failure: The wallet does not display "inbound balance" status, so the user doesn't know their receiving limit.
Many mobile Lightning wallets hide the complex concept of inbound liquidity in the background. When a payment fails, users only see a generic "payment failed" message without knowing their inbound capacity is exhausted. Mutiny Wallet was one of the few wallets supporting self-custody with LSP (Lightning Service Provider) access, but it ceased operations in 2024, showing that the inbound liquidity user experience problem remains fundamentally unsolved.
Risk Disclaimer
Leasing inbound liquidity does not mean borrowing money: the counterparty merely places funds in your channel; you do not have the authority to spend them, only the ability to receive payments. Ownership of the funds always remains with the lessor.
When the channel lease expires, the inbound capacity disappears: if you lease inbound capacity for one month, the lessor can close the channel or withdraw funds after expiry, and you will need to replenish it again.
Fluctuating on-chain fees can significantly affect replenishment costs: the core operations for adding inbound liquidity (opening channels, Loop Out swaps) require on-chain transactions. When mainnet fees spike, the on-chain cost of a single submarine swap can eat up all routing revenue.
How to Confirm Completion
Open your Lightning wallet or node management interface and check the "inbound liquidity" or "receivable amount" field in the channel list. If the number is greater than zero, you can receive at least some payments. If you just completed a submarine swap or channel lease, refresh and the number should increase — usually after waiting for on-chain confirmation (1–6 blocks, approximately 10–60 minutes).
Next steps: If you frequently receive payments, consider setting an inbound capacity alert — replenish early when the remaining receivable amount falls below twice your average daily receipts. Also check whether your wallet supports LSP (Lightning Service Provider) "on-demand funding" features, which can automatically top up inbound capacity when you receive a payment, avoiding temporary bottlenecks.
