Lightning uses payment channels that hold a fixed total capacity, but that capacity is split between two parties at any moment. The split determines who can send and who can receive:
Lightning Labs’ channel liquidity guide describes the identity relationship directly: inbound and outbound liquidity always sum to the channel’s total capacity, and every send or receive shifts that distribution.
This is the root reason Lightning feels different from onchain spending. A node can have a large total balance yet be unable to receive if inbound capacity is near zero.
Inbound capacity is the amount the counterparty currently controls on a channel, because those sats can be pushed to the local node as incoming payments.
A new channel funded only by the local node starts with almost all outbound and almost no inbound. That is why a newly opened channel is great for sending but not for receiving.
Inbound capacity is not created by a setting. It is created by moving balance to the remote side.
That can happen through natural activity, such as paying out through the channel, which pushes balance to the remote side and increases inbound.
It can also happen through explicit liquidity operations, such as circular rebalancing or swap-style workflows that shift funds across channels.
The important operational fact is that inbound is an economic state. A node cannot force inbound without either spending, rebalancing, or paying someone to provide it.
Outbound capacity is the local balance in channels that can be forwarded to others. It is created immediately when the node funds a channel.
Outbound capacity is usually easier to acquire because opening a channel creates outbound by default. The limiting factor is not configuration, it is capital and onchain fees for opening and closing.
Routing fees are paid to intermediate nodes that forward HTLCs across channels. A node sets fees it charges for forwarding payments outward over a channel.
At the protocol level, routing fee parameters are communicated in channel announcements. BOLT 7 includes two fee fields for routing policy:
This structure produces the common fee model used by node software: a fixed base plus a ppm-style variable component.
Routing fees are directional. A node sets the fee policy it charges when it forwards outbound through its channel, but it does not directly set the fee it pays to receive inbound through someone else’s channel. The other side controls their forwarding fees for the direction they provide.
This asymmetry is one reason inbound liquidity feels like something that must be earned or purchased. For a node to receive reliably, it needs remote balance on channels where the remote party is willing to forward inbound at acceptable fees.
Rebalancing is shifting channel balances so the node has outbound where it needs to send and inbound where it needs to receive.
Rebalancing is the process of adding incoming liquidity to channels used for routing from, and outgoing liquidity to channels used for routing to, which captures the idea that the node is shaping balance distribution over time.
Circular rebalancing sends a payment from the node and routes it through the network back to the node, landing in a different channel. The effect is that one channel loses outbound (it was spent) and another channel gains outbound (it was refilled), shifting balance distribution while keeping total funds roughly the same.
Circular rebalancing is not free. It pays routing fees along the path. It is best understood as purchasing a new balance distribution.
Rebalancing needs both sides of liquidity to exist somewhere.
A circular rebalance typically requires outbound on a starting channel and inbound on an ending channel. Without at least one channel that can receive, a rebalance cannot “land” back at the node.
This constraint is why inbound is the gating resource for many nodes. A node can open many outbound-heavy channels and still be unable to rebalance into a receive-ready posture.
Liquidity determines whether a payment can find a path that has sufficient outbound capacity on each hop and sufficient inbound capacity at the destination.
A payment can fail even when fees are acceptable if any channel along the route lacks enough balance on the needed side.
Liquidity also affects route choice. High-fee routes may be avoided even if they have liquidity. Low-fee routes may fail repeatedly if they are depleted.
This is why routing is an economic routing problem, not just a graph problem.
A node’s fee strategy interacts with liquidity.
High outbound fees can discourage flows and preserve outbound, but they can also reduce routing volume.
Low outbound fees can attract flows and earn volume, but they can also drain outbound quickly, which can reduce the ability to send and can require more rebalancing.
Fees also affect rebalancing cost. A node that frequently rebalances through high-fee routes is effectively paying a recurring tax to maintain its desired balance distribution.
BOLT 7’s base plus proportional model makes these tradeoffs explicit. Even a small proportional fee can become meaningful on larger routed payments, while a base fee dominates small payments.
Inbound and outbound balance per channel is the most actionable state variable. Liquidity is the core indicator of whether the node can send, receive, and route.
fee_base_msat and fee_proportional_millionths define the node’s outbound forwarding economics per channel. These fields should be treated as a lever for traffic shaping rather than as a passive setting.
Rebalancing is a cost center. A rebalancing plan should be evaluated by comparing expected routing revenue versus rebalancing fees paid. A node that pays more to rebalance than it earns in routing fees is subsidizing the network.
Receiving depends on inbound plus routing conditions. A node that expects to receive at scale should check that inbound capacity exists on channels connected to well-connected peers with consistent forwarding behavior.
High total capacity with low inbound: A node can have many channels and still fail to receive because most channels were funded locally and remain outbound heavy.
Fee settings that trap liquidity: If fees are set too high, routes avoid the node and liquidity distribution stops evolving naturally through routing. The node can become stagnant and require manual rebalancing.
Rebalancing that leaks privacy and increases cost: Large rebalancing loops can create distinctive patterns and can pay unnecessary fees when paths are poorly chosen. The economic cost is visible immediately, and the privacy cost is a secondary tradeoff.
Reliance on a single inbound provider: Inbound that depends on one peer creates concentration risk. If that peer goes offline or changes fees, receive capacity effectively disappears.
Lightning liquidity is the distribution of channel balances, not a separate asset class. Inbound capacity controls receiving because it represents the counterparty’s balance that can be pushed to the local node. Outbound capacity controls sending because it represents the local balance that can be pushed out. Together, they always sum to channel capacity, and every payment shifts the split.
Routing fees and rebalancing decisions are how operators manage this distribution. BOLT 7’s fee_base_msat and fee_proportional_millionths fields encode forwarding economics at the hop level, making fees an operational tool rather than a cosmetic setting. Rebalancing, especially circular rebalancing, buys a new liquidity shape at the cost of routing fees. When those mechanics are understood, inbound capacity stops being a mystery and becomes a manageable constraint.
The post Lightning Liquidity Explained: Inbound Capacity, Routing Fees, and Rebalancing Basics appeared first on Crypto Adventure.
