# Lightning inbound liquidity: why receiving needs capacity 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. Evidence: [Understanding Liquidity](https://docs.lightning.engineering/the-lightning-network/liquidity/understanding-liquidity); [BOLT 2: Peer Protocol for Channel Management](https://raw.githubusercontent.com/lightning/bolts/1aadb719b4007c4cea0ba6e36b08c4fb53788dee/02-peer-protocol.md) Canonical: https://degreesofsatoshi.com/encyclopedia/lightning-inbound-liquidity/ Published: 2026-10-02 Substantively modified: 2026-10-02 Independently verified by an automated reviewer: 2026-10-02T18:15:23.891Z Data current through: 2026-10-02 AI-assisted research and drafting with a separate automated source-verification pass; no external expert or named human review is implied. ## Key facts - **Direction:** Inbound and outbound liquidity describe different directions through a channel. ([Understanding Liquidity](https://docs.lightning.engineering/the-lightning-network/liquidity/understanding-liquidity)) - **Balance:** A payment shifts allocation between channel participants. ([BOLT 2: Peer Protocol for Channel Management](https://raw.githubusercontent.com/lightning/bolts/1aadb719b4007c4cea0ba6e36b08c4fb53788dee/02-peer-protocol.md)) - **Constraints:** Reserves, pending HTLCs and routing limits reduce usable capacity. ([BOLT 2: Peer Protocol for Channel Management](https://raw.githubusercontent.com/lightning/bolts/1aadb719b4007c4cea0ba6e36b08c4fb53788dee/02-peer-protocol.md)) ## 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. Evidence: [Understanding Liquidity](https://docs.lightning.engineering/the-lightning-network/liquidity/understanding-liquidity); [BOLT 2: Peer Protocol for Channel Management](https://raw.githubusercontent.com/lightning/bolts/1aadb719b4007c4cea0ba6e36b08c4fb53788dee/02-peer-protocol.md) ## 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. Evidence: [Understanding Liquidity](https://docs.lightning.engineering/the-lightning-network/liquidity/understanding-liquidity) ## 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. Evidence: [BOLT 2: Peer Protocol for Channel Management](https://raw.githubusercontent.com/lightning/bolts/1aadb719b4007c4cea0ba6e36b08c4fb53788dee/02-peer-protocol.md); [BOLT 7: P2P Node and Channel Discovery](https://raw.githubusercontent.com/lightning/bolts/1aadb719b4007c4cea0ba6e36b08c4fb53788dee/07-routing-gossip.md) ## Questions ### 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. Evidence: [Understanding Liquidity](https://docs.lightning.engineering/the-lightning-network/liquidity/understanding-liquidity); [BOLT 2: Peer Protocol for Channel Management](https://raw.githubusercontent.com/lightning/bolts/1aadb719b4007c4cea0ba6e36b08c4fb53788dee/02-peer-protocol.md) ## Claims and scope ### lightning-inbound-liquidity-quick-answer 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: {"collection":"bitcoin","dataAsOf":"2026-10-02","blockHeight":null} ### lightning-inbound-liquidity-fact-direction Direction: Inbound and outbound liquidity describe different directions through a channel. Scope: {"collection":"bitcoin","dataAsOf":"2026-10-02","blockHeight":null} ### lightning-inbound-liquidity-fact-balance Balance: A payment shifts allocation between channel participants. Scope: {"collection":"bitcoin","dataAsOf":"2026-10-02","blockHeight":null} ### lightning-inbound-liquidity-fact-constraints Constraints: Reserves, pending HTLCs and routing limits reduce usable capacity. Scope: {"collection":"bitcoin","dataAsOf":"2026-10-02","blockHeight":null} ## Sources - [Understanding Liquidity](https://docs.lightning.engineering/the-lightning-network/liquidity/understanding-liquidity) — Lightning 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.054Z. - [BOLT 2: Peer Protocol for Channel Management](https://raw.githubusercontent.com/lightning/bolts/1aadb719b4007c4cea0ba6e36b08c4fb53788dee/02-peer-protocol.md) — Lightning specification contributors. Channel funding, commitment updates, forwarding and channel closing. Locator: Channel Establishment; Forwarding HTLCs; Channel Close. Retrieved: 2026-10-02T17:22:20.750Z. - [BOLT 7: P2P Node and Channel Discovery](https://raw.githubusercontent.com/lightning/bolts/1aadb719b4007c4cea0ba6e36b08c4fb53788dee/07-routing-gossip.md) — Lightning 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.753Z. ## Revision history - 2026-10-02: Initial Bitcoin encyclopedia entry at this permanent URL. - 2026-10-02: Added reusable claims, explicit source locators, and matching Markdown and JSON. This publishing change does not itself establish factual verification. ## Cite this entry Degrees 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/