Encyclopedia How the network works · Entry 99
Lightning inbound liquidity: why receiving needs capacity
In this article
At a glance
Key facts
| Fact | Detail | Source |
|---|---|---|
| Direction | Inbound and outbound liquidity describe different directions through a channel. | [1] |
| Balance | A payment shifts allocation between channel participants. | [2] |
| Constraints | Reserves, pending HTLCs and routing limits reduce usable capacity. | [2] |
Separate capacity from available receiving room
Ignoring reserves and fees, a 100,000-satoshi channel with 90,000 on your side and 10,000 on your peer’s has roughly 90,000 of sending room and 10,000 of receiving room on that channel. The full 100,000 is not available in both directions simultaneously.
Actual limits can be lower because some funds are reserved or committed to pending transfers. The example explains direction; it is not a wallet quote.
Sending can create room to receive later
When a successful payment moves your balance toward the peer’s side, that channel can gain receiving room. Receiving moves it back toward your side. This is a rearrangement of funds, not a yield payment.
Rebalancing services and liquidity purchases can change placement, but introduce fees and service-specific conditions. Opening a channel funded entirely from your side does not automatically solve an inbound shortage.
A local balance is not the whole route
A recipient can have suitable last-hop inbound capacity while earlier hops are constrained. A sender can have outbound balance while no usable path reaches the recipient for the requested amount.
A failed route therefore does not prove that the recipient has no bitcoin or that the network has no capacity. It indicates that the attempted path and conditions did not complete.
Direct answers
Questions people ask
Does opening a larger self-funded channel guarantee I can receive more?
No. If most funds begin on your side, that primarily increases outbound capacity. Receiving depends on usable funds on the peer side and on the rest of the route.
Inspect the evidence
The answer and key facts have stable claim links. These records retain the scope and qualification when reused.
Inbound Lightning liquidity is usable channel capacity that peers can move toward your side when you receive a payment. Outbound liquidity supports payments in the opposite direction. A channel’s total capacity does not describe how much you can receive or send now; balance placement and channel constraints matter.
Scope: Bitcoin · data through 2026-10-02. Verification: verified · 2026-10-02T18:15:23.891Z.
Link to this claimDirection: Inbound and outbound liquidity describe different directions through a channel.
Scope: Bitcoin · data through 2026-10-02. Verification: verified · 2026-10-02T18:15:23.891Z.
Link to this claimBalance: A payment shifts allocation between channel participants.
Scope: Bitcoin · data through 2026-10-02. Verification: verified · 2026-10-02T18:15:23.891Z.
Link to this claimConstraints: Reserves, pending HTLCs and routing limits reduce usable capacity.
Scope: Bitcoin · data through 2026-10-02. Verification: verified · 2026-10-02T18:15:23.891Z.
Link to this claimRevision history
- — Initial Bitcoin encyclopedia entry at this permanent URL.
- — Added reusable claims, explicit source locators, and matching Markdown and JSON. This publishing change does not itself establish factual verification.
Source register
Sources and references
Retrieval dates and locators are recorded individually.- Understanding LiquidityLightning Labs
Channel balance placement determines the direction in which a payment can move.
Locator: Payments; Receiving funds; Routing liquidity · Retrieved: 2026-10-02T17:55:17.054ZOpen source - BOLT 2: Peer Protocol for Channel ManagementLightning specification contributors
Channel funding, commitment updates, forwarding and channel closing.
Locator: Channel Establishment; Forwarding HTLCs; Channel Close · Retrieved: 2026-10-02T17:22:20.750ZOpen source - BOLT 7: P2P Node and Channel DiscoveryLightning specification contributors
Direction-specific advertised routing fees and channel update parameters.
Locator: The channel_update Message; HTLC Fees; Example; fee_base_msat; fee_proportional_millionths · Retrieved: 2026-10-02T17:22:20.753ZOpen source
Research and drafting use AI assistance. A separate automated review checks claims against primary sources; no external expert or named human review is implied. Publication, substantive editing, source retrieval and verification are recorded separately. This version was independently checked by an automated reviewer on 2 October 2026.
Editorial method and correctionsDegrees of Satoshi editorial project. “Lightning inbound liquidity: why receiving needs capacity.” Published 2026-10-02; updated 2026-10-02. https://degreesofsatoshi.com/encyclopedia/lightning-inbound-liquidity/