Lightning liquidity

Anna and Pavel have a payment channel with a capacity of 1,000,000 sat: one million satoshis, the smallest units on the Bitcoin chain. Imagine a simplified state in which Anna owns 800,000 sat and Pavel owns 200,000 sat. For now, we leave out reserves, fees and pending payments to make the example easier to follow. Anna can send money to Pavel from her side; she can receive from him only from his side. Pavel therefore cannot send her 300,000 sat through this channel, even though its total capacity is a million. No money has disappeared. It simply is not distributed in a way that allows that payment. [1] [3]

Outbound liquidity is the amount usable for a payment away from you. In our example it starts with Anna’s 800,000 sat balance, but the actual maximum is usually lower because of reserves, fees and pending payments. When Anna pays someone other than Pavel, her first step still uses one of her own channels. A node is the software that manages channels and processes Lightning payments. The following nodes need their own funds for the next steps. Bitcoin held outside channels does not automatically increase her outbound liquidity; the wallet needs a suitable way to move that value into Lightning. [1] [3]

Inbound liquidity is the amount your peer can send toward you. If Anna opens a channel and owns almost all its funds, she is well placed to send, but has little room to receive. Creating a new payment request does not change that distribution. She needs a channel whose other participant has a usable balance. Some wallets arrange this through a service provider, hiding the complexity from the user, often for a fee. Inbound capacity is not extra money Anna already owns: it is the ability to receive a future payment. [1] [3] [5]

Anna now pays Pavel 100,000 sat. In our simplified example, the balances become 700,000 sat for Anna and 300,000 sat for Pavel. Capacity remains 1,000,000 sat. Anna has less room to send but more room to receive back; Pavel experiences the reverse. If a wallet has multiple channels, it is the channels actually used by the payment that change. Direction therefore always matters. A liquidity figure from the morning may not describe what can be sent that evening. [1] [3]

A payment to a distant recipient passes through a sequence of channels. Each needs enough usable liquidity in the right direction, including amounts for fees further along the route. If one step cannot carry it, this route fails even if the other channels have plenty of capacity. The wallet may try another route or split a supported payment into several parts. That still cannot create missing funds. The amount is not the only constraint: timing matters too. An HTLC is a conditional payment that can be completed by demonstrating knowledge of a particular secret. The rules associated with CLTV set deadlines in blocks; the gaps between those deadlines give intermediaries time to settle on the Bitcoin blockchain if forwarding gets stuck. [1] [2]

An intermediary must be able to receive through one channel and send the linked payment through another. A large sum of balances is not enough. If its funds sit on its own side of the wrong channel, they may not be usable for the chosen route. Receiving needs inbound liquidity in the first channel; forwarding needs outbound liquidity in the second. These steps are linked by HTLC conditions: the payments depend on knowing a particular secret and on timing rules. The intermediary does not merely rely on a promise that the previous participant will pay it later. [1] [3]

Incoming and outgoing payments naturally change liquidity. An operator with several channels can also use circular rebalancing: send a payment out along one route and receive it back along another to shift balances between their own channels. A swap exchanges on-chain funds for Lightning funds or the reverse. Splicing can change the funding of a supported channel without the usual close-and-reopen process. Opening another channel is another option. These methods differ in fees, timing, on-chain footprint, trust requirements and failure risk. None creates new money; choose according to whether you need to send, receive or both. [1] [4]

First establish whether you are trying to send or receive, and whether your wallet and peer are online. On your own node, compare local and remote balances for each channel, reserves, pending payments and fees. With a managed wallet, check what its available-amount figure actually means. One failed payment does not itself prove money has been lost; a hop may lack liquidity, a limit may apply, or there may be a temporary outage. A smaller test payment verifies only that amount at that moment, not guaranteed passage for every later payment. [1] [3] [4]

Node operators need to distinguish several limits. A transaction output specifies an amount and the conditions for spending it. channel_reserve_satoshis identifies funds that must remain as a reserve. Some funds may be committed to pending HTLCs, conditional payments not yet completed. The following limits apply to HTLCs offered by the other participant. max_htlc_value_in_flight_msat limits their total value and max_accepted_htlcs their number; msat is a thousandth of a satoshi used in Lightning accounting. Depending on the channel type, there are also fees for the commitment transaction that closes the channel, and possibly anchor outputs: special outputs that let a follow-up transaction increase the fee for confirming the package. Dust rules determine which outputs are too small to include in that transaction. Calculate the exact available maximum for the particular implementation and channel type, rather than subtracting one universal reserve. [1] [6]

BOLT #7 describes channel announcements and forwarding policies. For an announced channel, its funding output and capacity can be found on-chain. That does not reveal the current split between its participants. Senders choose routes using their own information, earlier results and payment attempts, not a complete public list of live balances. A network explorer can therefore display a large channel without establishing that your amount can pass through it in the right direction right now. [2]