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.
Complete Step 1 // Required reading in the study plan above, then continue here.
Step 2 — Core idea: inbound vs outbound
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 finding a path where every hop has enough outbound on the forward edge.
Total channel capacity is fixed until you splice, dual-fund, or close. Payments move balance between sides — they do not create new capacity.
| 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).
Loading diagram…
Loading diagram…
When your node forwards an HTLC, that slice of outbound is reserved until settle or fail. Busy edges drain outbound — direction matters before pathfinding.
Done when: You can explain a “funded but cannot receive” failure in inbound/outbound terms.
Step 3 — Try it: send both ways (lab)
- Inspect
local_balancevsremote_balance(or Polar equivalent) - Pay funder → peer (should succeed if outbound exists)
- Pay back — may fail if inbound is insufficient
- One sentence explaining the failure in inbound/outbound terms
Done when: Lab evidence (balance split + failure sentence + source) is complete.
Next lesson
Commitment Transactions — the signed states that make channel updates safe.