Inbound Liquidity

Petr runs a café and accepts Lightning Network payments. His node, the software handling payments, shows funds, yet a customer cannot pay. Missing inbound liquidity is one possible reason. A payment channel is an agreement between nodes about how deposited bitcoin is divided. Petr’s share is the local balance; his peer’s share is the remote balance. Receiving a payment shifts some value from the peer’s side to Petr’s. That requires funds on the peer’s side to shift. The remote balance still belongs to the peer: acquiring the ability to receive is not a gift of bitcoin or revenue already earned. [1] [6]

Consider a channel with a capacity of 1000000 sat. Sat abbreviates satoshi, a small unit of bitcoin. Petr has a local balance of 800000 sat and the peer a remote balance of 200000 sat. The gross room to receive is therefore 200000 sat. If Petr receives 100000 sat, his side rises to 900000 sat and the peer has 100000 sat left. He has gained the payment, but his remaining room to receive has shrunk. For clarity, this example leaves out reserves, fees and pending payments called HTLCs, explained below. If Petr alone funds a new channel without an initial transfer to the peer, he mainly gains the ability to send. Confirming the channel opening does not reverse that direction. [1] [2]

During a successful day, money accumulates on Petr’s side while the inbound room of the channels used declines. A larger balance can therefore accompany a reduced ability to receive the next payment. Running your own infrastructure means watching usable channels, expected amounts, payments in progress and the cost of replenishing liquidity. Some wallets handle part of this work for users, but the mechanism remains. Petr may not even see a failed attempt: it can stop before reaching his node. An issued invoice or an old capacity figure is not confirmation of payment. [6]

When Petr pays a supplier over Lightning, the local balance of the channels used falls and their remote balance rises. That can make room for future receipts. Loop Out works similarly: through a swap, an exchange between payment layers, he sends value out of Lightning and receives bitcoin at an on-chain address. The channels need not close. Loop In goes the other way, converting on-chain funds into a spendable Lightning balance. Neither operation creates bitcoin. Comparing the result means accounting for routing, swap-service and on-chain transaction fees, and checking that the operation actually completed. [1] [4]

Another option is for a peer to fund a channel to Petr. He can then gain room to receive without the peer giving him its money. Lightning Pool documentation describes a market for such agreements: a bid requests liquidity and an ask offers to provide it. The lease has a term measured in blocks and involves a premium and other fees. A block is a group of transactions added to the blockchain, Bitcoin’s public transaction history. The lease term therefore follows the arrival of blocks rather than an exact number of hours. It is not a purchase of the entire remote balance. Nor does the agreed term mean that the same amount remains available to receive throughout it: payments change the balance distribution. Continued channel availability after the agreement ends cannot be assumed either. [1] [5]

Petr may have several channels and need inbound room with a different peer. Circular rebalancing sends his payment into the network through one channel and brings it back through another of his channels. The sending channel gains inbound room; the receiving channel consumes it. Funds move between his sides of channels, rather than new capital appearing, and routing costs fees. The operation needs a usable route. If every remote side of his channels lacks funds, there is no channel through which the returning payment can arrive. Circular rebalancing alone cannot fix that. [1]

Some funds must remain as a reserve for safe channel operation. Other funds may be temporarily committed to HTLCs, conditional payment commitments. The recipient can claim them by revealing a secret value that produces the agreed payment hash, a value used for verification. If the payment fails, the sending party has a way to recover the funds after the deadline. BOLT 2, the channel-management specification, also limits the minimum amount, number of simultaneous HTLCs and their total value. The full remote balance may therefore be unavailable for another payment. Adding all remote balances and subtracting a universal reserve is not enough; the individual channels and their current state matter. [2]

A payment usually passes through several nodes. Even if Petr has receiving room, an earlier part of the route may be offline or short of funds. BOLT 7 describes channel_update messages in which nodes announce routing conditions for a channel direction. These include fees and htlc_maximum_msat, the upper limit for an individual conditional payment in msat, thousandths of a satoshi. They are not a promise of current funds along the entire route. Adding up Petr’s inbound room therefore does not guarantee that he can receive that amount from every particular sender. Receiver-side liquidity is a necessary part of the solution, not the only one. [3]