Inbound Liquidity is a Lightning node’s ability to receive through the remote sides of its channels. Its basis is the peer’s remote balance, but reserves, pending payments, channel rules and an available route constrain usable receiving capacity.
Remote balance belongs to the peer and represents potential room to receive; local balance is your side. Receiving a payment moves value from the remote side to the local side. Buying the ability to receive is therefore neither a gift of bitcoins nor revenue already earned. [Lightning Labs — Managing liquidity]
In a simplified 1000000 sat channel with local balance of 800000 sat and remote balance of 200000 sat, gross receiving room is 200000 sat, not a million. This example omits reserves, fees and pending HTLCs. Funding a channel alone without an initial transfer mainly provides outgoing room; confirmation of opening does not reverse its direction. [Lightning Labs — Managing liquidity] [BOLT 2 — Channel management]
BOLT 2 constrains HTLC additions through reserves, minimum amounts, simultaneous HTLC counts and total outstanding value. Pending payments can temporarily tie up funds. Inspect the available amount and limits of each channel; do not subtract one universal reserve from the sum of all balances. [BOLT 2 — Channel management]
BOLT 7 publishes directional channel_update parameters such as fees and htlc_maximum_msat, not a guaranteed live balance for the entire route. An offline peer or an earlier bottleneck can stop a payment. The sum of remote balances therefore does not guarantee receipt of that amount from a particular sender. [BOLT 7 — Routing gossip]
An outgoing Lightning payment reduces local balance and increases remote balance in the channels it uses. Loop Out moves Lightning value to an on-chain output and can free receiving room; Loop In instead replenishes outgoing funds. No bitcoins are created: account for routing, swap and on-chain costs and the operation’s outcome. [Lightning Labs — Managing liquidity] [Lightning Loop — Direction and channel balances]
A peer can fund a channel toward you; on Lightning Pool, a bid buys time-limited liquidity and an ask offers it. Lease duration is expressed in blocks. Paying the premium and other fees neither transfers the entire remote balance into your ownership nor ensures permanent availability after the agreement ends. [Lightning Labs — Managing liquidity] [Lightning Pool — Orders and leases]
Circular rebalancing sends through one of your channels and receives through another via the network. The outgoing channel gains receiving room while the receiving channel consumes it. Rebalancing creates no new capital and costs routing fees; it needs a usable route and cannot alone solve a node lacking funds on every remote side. [Lightning Labs — Managing liquidity]
Receiving revenue continually converts remote balances into local balances and can exhaust further receiving room. Monitor usable channels, pending payments, replenishment costs and expected amounts. A failed attempt may never be visible at the receiving node; an issued invoice or old capacity reading is not confirmation of payment. [Lightning Labs — Merchant liquidity]
For the clearest picture, read this entry together with Lightning Network, Payment Channel, Lightning Routing, Submarine Swap, HTLC, Lightning Address. The reverse links also lead from Lightning liquidity, Lightning Routing, Lightning Address, Submarine Swap.