Lightning liquidity: enough bitcoin can still be in the wrong place

A Lightning wallet can have enough bitcoin to cover a payment and still struggle to deliver it. A merchant can have substantial funds in a channel and still lack room to receive another payment. These are not contradictory outcomes. Lightning liquidity has a direction and depends on a usable route.

The total value committed to a channel tells only part of the story. To understand a payment's feasibility, ask where that value sits, which direction it needs to move and who manages the channels behind the wallet.

One channel has two perspectives

A payment channel connects two peers whose balances change as they transact. From one peer's perspective, outbound liquidity supports sending; inbound liquidity supports receiving. Lightning Labs' liquidity guide makes this distinction explicit.

Imagine a simplified channel with 1,000,000 satoshis of capacity: 800,000 on Alice's side and 200,000 on her peer's side. Before reserves, fees and other constraints, Alice has 800,000 satoshis pointing outward and 200,000 pointing inward. Her peer sees the reverse.

If Alice sends 100,000 satoshis through this channel, her side falls to 700,000 and the other side rises to 300,000, ignoring fees. Sending has created additional room for Alice to receive through that same channel. Receiving has the opposite effect. This example describes balance movement, not a guaranteed spendable amount.

Real channels have constraints beyond the two headline balances. BOLT 2 specifies such considerations as channel reserves and limits on pending conditional payments. Funds committed to payments already in progress can also reduce what another payment can use.

Capacity does not describe an end-to-end route

A routed payment needs a workable sequence of channels from sender to recipient. Each intermediate node must be able to receive on one channel and forward on another. Liquidity elsewhere in the network cannot automatically substitute for a shortfall along the chosen path.

The Lightning Network overview explains why senders may attempt more than one route: knowledge of connections does not give complete knowledge of peers' availability and usable liquidity. A public capacity total is consequently not a promise that a particular recipient can receive a particular amount now.

In a hypothetical route Alice → Bob → Carol, suppose Alice can send 400,000 satoshis toward Bob, while Bob can send only 60,000 toward Carol. A 100,000-satoshi payment cannot traverse that single route under those assumptions, even though Alice's balance exceeds the payment. The constraining direction is Bob to Carol.

Other paths may change the result, but their existence has to be established. Adding up unrelated channel capacities does not establish it. Fees and channel policies also belong in the real routing calculation.

Sending, receiving and routing need different resources

This is a diagnostic worksheet, not a channel-management prescription. Lightning Labs' discussion of liquidity emphasizes that different participants need different channel arrangements. A merchant receiving repeatedly and a customer spending repeatedly can face opposite constraints even when their starting capacity matches.

The wallet may handle the channels for you

Channel management can be delegated without necessarily surrendering control of funds. A Lightning service provider can supply inbound liquidity to a non-custodial wallet. The commercial terms and technical dependencies remain relevant: an uncomplicated interface does not make the underlying capital free or unlimited.

A custodial account is a different arrangement. For example, LND Accounts maintains virtual account balances on an operator's node. Its documentation explicitly distinguishes those balances from the node's overall channel balances and describes the user's trust in the operator. That example illustrates a service model, not a claim that every Lightning wallet works that way.

Ask separately who holds spending authority, who provides receiving liquidity and what happens if the provider becomes unavailable. The earlier guide to wallet control and recovery helps with the first question. The answers to the other two explain why a balance displayed on screen does not, by itself, establish immediate payment reachability.