Channel liquidity is not how much bitcoin you locked — it is which side of each channel holds that balance. Lightning is directional: the same channel can send easily in one direction and fail in the other.
Why this matters
This is the Lightning-specific idea that confuses people the first time. On-chain, a UTXO is yours to spend. In a channel, only your outbound balance is spendable by you; inbound is the counterparty's share that lets you receive. Routing later is just finding a path where every hop has enough outbound on the forward edge.
Fixed capacity
Total channel capacity is fixed until you splice, dual-fund, or close. Payments move balance between the two sides — they do not create new capacity.
Inbound vs outbound
| Term | Meaning |
|---|---|
| Outbound | Your side's balance — what you can send or forward |
| Inbound | Counterparty's balance on your channel — what you can receive |
After a typical single-funded open, the funder starts outbound-heavy (can send, cannot receive much). The peer starts inbound-heavy relative to the funder.
Payment failure from wrong-side balance
Loading diagram…
Forwarding locks liquidity
When your node forwards an HTLC, that slice of outbound is reserved until the payment settles or fails. Heavy routing without balanced channels drains outbound on busy edges — another reason direction matters before you study pathfinding.
Try it in Polar or regtest
- Open a channel between two nodes.
- Check
local_balancevsremote_balance(or equivalent). - Pay from the funder toward the peer — should succeed.
- Pay back the full amount — may fail if inbound is insufficient.
- Write one sentence explaining the failure in inbound/outbound terms.
Next steps
Commitment transactions — the signed states that make channel updates safe.