BA-11 · LESSON 03

Routing and liquidity

KEY DEFINITIONS

Terms used in this lesson

Preimage: The original secret data whose hash equals a previously committed value.
HTLC: Hashed Timelock Contract: a conditional payment that requires a secret before a deadline or permits a later refund.
CLTV: CheckLockTimeVerify: a Bitcoin Script operation that enforces an absolute time or block-height condition.
BOLT: Basis of Lightning Technology: a numbered specification document for the Lightning protocol.
BTC: The common market ticker for bitcoin.

Multi-hop payments use onion routing and conditional transfers but depend on directional channel liquidity.

55 min Difficulty 3/5 Not started

VISUAL MODEL

See the whole mechanism before going step by step

Use the diagrams to orient yourself. Then the guided explanation below teaches every part in depth.

4 explanatory views

CONCEPT-SPECIFIC MAP · state machineOne valid action transforms a known stateSelect any state to inspect its exact role.

RELATIONSHIP MAPOrdered mechanism flow

01
BEFOREKnown state
Identify the facts and objects that exist before the action.
02
ACTIONRouting and liquidity
The Routing and liquidity lesson isolates the event that proposes a change.
03
RULEDeterministic check
The enforcing rule accepts or rejects the proposed transition.
04
AFTERSuccessor state
Accepted work creates a new state without silently changing the prior facts.
05
FAILUREState unchanged
A failed condition must not produce a partially accepted successor.

Rule shown: A valid transition names the prior state, action, enforcing rule, and successor state.

STAGE 1 OF 5BEFORE: Known state

Identify the facts and objects that exist before the action.

Governing relationship: A valid transition names the prior state, action, enforcing rule, and successor state. Complete path: 1. BEFORE, Known state. Identify the facts and objects that exist before the action. 2. ACTION, Routing and liquidity. The Routing and liquidity lesson isolates the event that proposes a change. 3. RULE, Deterministic check. The enforcing rule accepts or rejects the proposed transition. 4. AFTER, Successor state. Accepted work creates a new state without silently changing the prior facts. 5. FAILURE, State unchanged. A failed condition must not produce a partially accepted successor.

1. State transitionWhat exists, what changes, and what results

BEFORE

Alice routes through B and C to Dana. B charges a 500-sat base fee, C charges 300 sats, and neither charges a proportional fee. Receiver expiry is height 600; C adds 6 blocks…

MECHANISM

The sender uses network announcements, local channel state, fees, and heuristics. Public capacity does not reveal exact available balance.

AFTER

A connected graph is not enough; the payment needs calculated fees, safely ordered expiries, and directional liquidity along every hop.

Text equivalent: Starting from Alice routes through B and C to Dana. B charges a 500-sat base fee, C charges 300 sats, and neither charges a proportional fee. Receiver expiry is height 600; C adds 6 blocks and B adds 10. The mechanism begins when The sender uses network announcements, local channel state, fees, and heuristics. Public capacity does not reveal exact available balance. The resulting lesson is A connected graph is not enough; the payment needs calculated fees, safely ordered expiries, and directional liquidity along every hop.

2. Mechanism pathSelect a stage to inspect its job

STAGE 1 OF 5

Find candidate routes

The sender uses network announcements, local channel state, fees, and heuristics. Public capacity does not reveal exact available balance.

Complete path: 1. Find candidate routes: The sender uses network announcements, local channel state, fees, and heuristics. Public capacity does not reveal exact available balance. 2. Create a payment secret: The receiver supplies a payment hash and keeps its preimage. Linked HTLCs across the route use that hash. 3. Wrap onion instructions: The sender encrypts per-hop next-hop, amount, and timeout data so each node removes one layer and learns only what it needs. 4. Forward conditional value: Each forwarding fee is base fee plus floor of downstream amount times proportional parts per million divided by 1,000,000. Each upstream expiry equals its downstream expiry plus the forwarder's block delta. Every hop needs enough outbound liquidity for its calculated amount. 5. Settle backward or fail: The receiver reveals the preimage, which propagates backward and moves each installed HTLC from locked to settled while preserving receiver value plus forwarding fees. If installation fails, upstream locks release and downstream HTLCs are never installed. Without a preimage, shorter downstream expiries unwind before their upstream dependencies.

3. Rule and failure boundaryWhat accepts the result and where it can stop

ACCEPTED PATH

Each hop independently authenticates its packet, needs amount plus base plus floor-proportional fee within reserve-adjusted outbound liquidity, preserves increasing upstream expiry, and leaves second-stage value above fee plus dust.

CHANGED CONDITION

A corrupted packet, insufficient directional liquidity, fee-rounding error, unsafe expiry order, or fee-plus-dust shortfall rejects installation; absent preimage unwinds in downstream-to-upstream timeout order.

Important distinction: A channel with 1 BTC capacity can route 1 BTC in either direction at any time. Capacity is split between sides. Only the sending side's available balance, minus reserves and pending HTLC constraints, supports that direction.

Text equivalent: The accepted path is enforced by Each hop independently authenticates its packet, needs amount plus base plus floor-proportional fee within reserve-adjusted outbound liquidity, preserves increasing upstream expiry, and leaves second-stage value above fee plus dust. If the required condition changes, A corrupted packet, insufficient directional liquidity, fee-rounding error, unsafe expiry order, or fee-plus-dust shortfall rejects installation; absent preimage unwinds in downstream-to-upstream timeout order.

Loading lesson visuals...

Learn the idea

Lightning routing sends a payment across several channels using linked HTLCs. Onion routing gives each forwarding node only its adjacent hop instructions. Liquidity is directional: a channel may have total capacity but lack outbound balance in the needed direction. Parts per million, abbreviated ppm, is the proportional-fee unit. CheckLockTimeVerify, abbreviated CLTV, supplies the name used for each hop's expiry delta. Fees and timeouts increase along the route to compensate forwarders and preserve safe failure order. Basis of Lightning Technology, abbreviated BOLT, names Lightning's specification documents. The lab independently authenticates and peels a deterministic teaching packet; it is not the BOLT 4 Sphinx wire format.

GUIDED EXPLANATION1/5 ideas inspected

Find candidate routes

The sender uses network announcements, local channel state, fees, and heuristics. Public capacity does not reveal exact available balance.

The worked example follows the explanation

Inspect every idea above to open it.

Important distinction“A channel with 1 BTC capacity can route 1 BTC in either direction at any time.”

Capacity is split between sides. Only the sending side's available balance, minus reserves and pending HTLC constraints, supports that direction.

FINISH LEARNING FIRST

The questions unlock after every required learning activity

Inspect every guided idea, open the worked example, rebuild its mechanism, and complete the deterministic lesson tool. Your progress is saved automatically.