A Lightning channel has two balances whose sum is constrained by channel capacity. Local spendable balance forms outbound liquidity; remote spendable balance forms inbound liquidity. Reserves, commitment transaction fees, pending HTLCs, channel rules and usable capacity at every hop determine whether a particular amount can actually traverse a route.
Channel capacity is bitcoin locked in the funding output. Liquidity is only the part currently usable in one direction; a channel with capacity of 1,000,000 sats can therefore hold almost everything on one side and fail to carry a large payment in the opposite direction. [BOLT #2 — Peer Protocol for Channel Management] [Lightning Labs — Understanding Liquidity]
Outbound liquidity is the amount the local node can send through a channel after protocol reserves, commitment transaction fee obligations and pending HTLCs. It decreases when paying or forwarding outward and increases when value arrives from the peer. [BOLT #2 — Peer Protocol for Channel Management] [Lightning Labs — Understanding Liquidity]
Inbound liquidity is the amount the peer can send toward the local node. It is needed to receive through that channel, but changing a payment request does not create it; it must exist in the remote balance or be supplied by a liquidity-management operation. [BOLT #2 — Peer Protocol for Channel Management] [Lightning Labs — Understanding Liquidity]
A routed payment succeeds only if every selected hop has enough usable liquidity in the right direction and accepts the HTLC under its fee rules, minimum and maximum amounts and CLTV time constraint. One depleted channel can block an otherwise well-connected route. [BOLT #2 — Peer Protocol for Channel Management] [BOLT #7 — P2P Node and Channel Discovery]
channel_reserve_satoshis, commitment transaction fees, anchor outputs, dust rules, max_htlc_value_in_flight_msat, max_accepted_htlcs and already-pending HTLCs can reduce the amount available for a new payment. Wallet balance, channel capacity and the amount immediately routable are therefore three different numbers. [BOLT #2 — Peer Protocol for Channel Management]
BOLT #7 allows a channel and its forwarding rules to be announced. Its capacity can be obtained from the funding output identified on-chain; this does not reveal the private balance split. The sender estimates a route using its own information, past results and payment attempts. A public explorer cannot confirm that a chosen route will carry a specific amount right now. [BOLT #7 — P2P Node and Channel Discovery]
A settled payment shifts the balance in every channel it uses: outbound liquidity falls and inbound liquidity rises on the sending side, with the opposite change at the other end. The payment reallocates existing capacity without increasing total capacity. [BOLT #2 — Peer Protocol for Channel Management] [Lightning Labs — Understanding Liquidity]
A forwarding node needs inbound liquidity in one channel and outbound liquidity in the next for the same HTLC. A large aggregate number of sats is insufficient if they sit in the wrong channels or on the wrong sides. [BOLT #2 — Peer Protocol for Channel Management] [Lightning Labs — Understanding Liquidity]
Received payments, circular rebalancing, channel opening or closing, swaps and splicing can move liquidity. They differ in fees, on-chain footprint, timing, counterparty trust and failure risk; no method creates free liquidity. A multi-part payment can combine routes but still requires sufficient aggregate directional capacity. [BOLT #2 — Peer Protocol for Channel Management] [Lightning Labs — Managing Liquidity]
Check your own node’s local and remote balances for each channel, reserves, pending HTLCs and fee buffer, then test the intended amount. Record direction, size, time and implementation: liquidity changes after every payment and is not one permanent score for the whole network. [BOLT #2 — Peer Protocol for Channel Management] [Lightning Labs — Understanding Liquidity] [Lightning Labs — Managing Liquidity]
For the clearest picture, read this entry together with Lightning Network, Payment Channel, Lightning Routing, Inbound Liquidity, Bitcoin, HTLC. The reverse links also lead from Payment Channel, Lightning Routing, Volatility, Market capitalization.