Bitcoin VerityOpen comparator

Level 10 · Verification and second layers

Lightning routing, liquidity and payment failures

How a sender builds a route, what each intermediary sees and why a public channel does not guarantee that a payment can pass.

Article
100
Reading time
18 minutes
Reviewed
10 September 2026

In a nutshell

A Lightning sender selects routes from public channel announcements, directional fees and timing requirements. Onion routing gives each hop only its own instruction and next destination. Exact directional liquidity is absent from the public gossip graph, so routes are probed and payments can fail.

01

Gossip builds an incomplete map

BOLT 7 defines signed node, channel and directional update messages. Updates advertise status, base and proportional fees, HTLC bounds and CLTV delta, from which a sender builds a local network graph.

Funding capacity is visible on chain, but its current division is not public. Private channels are absent from the global graph. The map therefore shows possible edges rather than a guarantee for a particular amount.

02

The route is calculated backwards

Starting from the requested amount and final expiry, the sender adds each next node's fee and CLTV delta while moving backwards. The first HTLC therefore carries a larger amount and later expiry than the last.

The cheapest route need not be best. Wallet algorithms can weigh success probability, hop count, time exposure, channel bounds and previous attempts. Route choice is wallet policy, not one Lightning consensus algorithm.

03

Onion routing reveals one step

BOLT 4 uses a layered Sphinx packet. Each hop removes its layer, learns the outgoing channel, amount and expiry, and forwards a transformed packet. It does not automatically see the entire route or other hops' instructions.

This is not perfect anonymity. The first hop sees its sending peer, the last hop points toward the recipient, and timing, amounts, topology or controlled nodes can create clues. Repeated failed attempts also disclose information.

04

Failure is part of route finding

A payment can fail because of directional liquidity, stale updates, an offline node, HTLC limits, fees or timing. An encrypted failure lets the sender update its local view and try another route without settling only part of the payment.

A wallet may split a payment across paths, but each part still needs a viable route and compatible recipient. Better liquidity and retries improve probability, not certainty, so a truthful interface never promises an exact result or time.

Level 10 · Verification and second layers

Terms to know

Gossip
Signed P2P announcements from which nodes build a public Lightning graph.
Onion routing
Layered routing in which each hop reveals only its own instructions.
Directional liquidity
The amount currently sendable in one direction through a channel.

Common misconception

If a map shows connected nodes and enough channel capacity, the payment must succeed.

A more accurate explanation

The public graph does not reveal exact directional balances or live availability. It shows candidate routes that can fail when attempted.

A more accurate explanation

Is route probing inefficient?

It is part of the privacy trade-off created by not publishing every channel balance. Wallets combine gossip, prior results, probabilistic scoring and multiple routes to reduce attempts.

100

Key takeaways

  1. 01Gossip describes public channels and directional rules.
  2. 02Exact liquidity distribution remains private.
  3. 03An onion packet gives a hop only its next step.
  4. 04Alternative routes and splitting improve odds, not certainty.

A child-friendly recap

In very simple terms

The Lightning map shows possible paths but not exactly how much can move in each direction right now. Each middle node sees only its next step, so a wallet may try several routes and a payment can still fail.

Reviewed: 10 September 2026

Sources and further reading

Sources support particular facts and definitions; listing one does not mean the editors endorse every view of its author.

01
BOLT 4: onion routingLightning Network Specifications
github.com
02
BOLT 7: node and channel discoveryLightning Network Specifications
github.com
03
BOLT 11: payment request encodingLightning Network Specifications
github.com
04
BOLT 2: forwarding HTLCsLightning Network Specifications
github.com

Educational material, not an investment recommendation.