Lightning Routing

Routing starts at the payer, not at routing nodes: its wallet or node selects a candidate path to the payee and specifies the next channel for every intermediary. The recipient supplies identity, features and possibly route hints or blinded paths, but the sender normally computes the public portion leading to it.

BOLT #7 propagates channel announcements and directional channel updates containing base fee, proportional fee, CLTV delta, minimum, maximum and availability flags. They describe advertised forwarding policy and topology; they do not prove that a peer is online or that the channel currently has enough liquidity for the chosen amount.

Public gossip does not reveal how a channel's balance is split between its sides. A router therefore combines known local liquidity, capacity, earlier successes and failures, penalties and implementation-specific scoring. The theoretically cheapest path need not have the highest success probability.

Amounts and expiries are assembled backward from payee to payer. Every forwarding node must receive an incoming amount covering the next hop plus its own fee, and an incoming CLTV sufficiently above the outgoing CLTV by its advertised delta; a longer path therefore increases aggregate fees and the time-lock margin.

BOLT #4 uses onion routing: the payer creates a Sphinx packet with a separately encrypted payload for each hop. An intermediary learns its previous and next peer and its forwarding instructions, but not the whole path, its length or exact position; traffic analysis and collusion can still weaken this privacy.

A temporary channel failure, insufficient fee, incorrect CLTV or unknown next peer returns a constrained failure signal to the payer. The implementation can penalize the candidate, recalculate and retry; one success or failure is not a permanent description because the channel state can change meanwhile.

A payment succeeds only when every hop accepts the HTLC and has enough usable liquidity in the required direction after reserves, pending HTLCs and htlc_minimum_msat and htlc_maximum_msat limits. High aggregate capacity or many connections do not remove a bottleneck at one poorly balanced channel.

If an invoice supports basic MPP, the payer may divide total_msat across several paths and the recipient settles them as one set. MPP can bypass a single-channel limit and use distributed liquidity, but adds HTLCs, attempts and fees and still requires sufficient aggregate directional capacity.

BOLT 11 route hints can expose final unannounced hops; BOLT 12 and route blinding let a recipient provide an encrypted tail through an introduction point. These mechanisms improve reachability and privacy, but the payer must still find a viable route to the first known point and honor aggregate fee and CLTV constraints.

To verify routing, record implementation and version, amount, maximum fee and CLTV limit, attempt count, paths used, completion time and exact failure reason. Compare the same node pair at a similar time: routing success belongs to a specific payment and network state, not a permanent global score. Sources: BOLT #4 — Onion Routing Protocol; BOLT #7 — P2P Node and Channel Discovery; BOLT #11 — Lightning Payment Encoding; Lightning Labs — Pathfinding; LDK — Routing and Route Parameters.