Timechain Wiki

Lightning routing

12 min read

Lightning routing is the protocol layer that finds payment paths through the channel network and delivers payments atomically. The sender computes the route locally from a gossip-derived view of network topology and policies; the route is encoded as an onion-routed (Sphinx) payment that propagates hop-by-hop, with each hop seeing only its neighbors. Pathfinding satisfies the payment amount, per-channel liquidity (inferable but not directly observable), routing-fee budget, and timelock budget; gossip publishes channel announcements after sufficient base-layer confirmations and channel-update messages as policies change. Routing concentration is real and operationally significant — a small number of well-connected hub nodes route the majority of payments, producing a hub-and-spoke topology that trades pathfinding efficiency against decentralization. Lightning Service Providers (LSPs) have emerged to bridge casual-user needs (inbound liquidity, just-in-time channels, managed routing) and self-sovereign operation, and are now a structural feature of the modern network. Channel construction lives in Lightning channels and the overview in The Lightning Network.

Why this note matters

Routing is where Lightning’s network-effect properties emerge — and where most of its operational friction lives. The protocol-mechanism distinction between paying someone you share a channel with (trivially direct) and paying someone you don’t (requires routing) explains why Lightning’s UX has not been straightforwardly resolved by base-layer scaling. The pathfinding-and-gossip layer is also where Lightning’s privacy properties partially live (onion routing protects intermediate-hop identity) and where routing-concentration concerns originate.

Understanding routing is the necessary precondition for understanding Lightning at scale: why LSPs exist, why custodial Lightning is dominant, why inbound-liquidity is a recurring user pain point, and why proposed routing improvements (trampoline routing, blinded paths, atomic multi-path payments) are the active development frontier.

The gossip protocol

Lightning nodes maintain a view of the public network through gossip — a peer-to-peer message-propagation protocol distinct from the base-layer P2P network.

The two principal message types:

  • channel_announcement — published after a channel’s funding transaction has six base-layer confirmations. The message includes the channel’s short_channel_id (derived from the funding transaction’s block height, transaction index, and output index), the two participants’ node public keys, and proof that both participants signed off on the announcement. Channels not announced (i.e., private channels) do not propagate via gossip.
  • channel_update — published when a channel’s routing policy changes. The message includes the channel’s fee parameters (base fee in millisatoshis; proportional fee in millisatoshis-per-million), the cltv-delta the channel requires for routing, and the channel’s min_htlc and max_htlc constraints. Updates supersede prior updates via a sequence number.

Plus the node_announcement message that publishes a node’s metadata (alias, color, addresses).

The gossip database. Each node maintains a local database of all gossip messages it has received. The database represents the node’s view of public Lightning topology and is the input to pathfinding. Gossip-message volume is non-trivial: a node syncing the full network from cold start can receive millions of gossip messages over hours.

Sync protocols. The original “channel_query and channel_range” sync protocol has been incrementally improved (BOLT 07 sync extensions; gossip_v2 proposals) to reduce sync-time bandwidth and to support partial-sync for resource-constrained nodes. Modern implementations support various sync modes (full sync, partial sync, on-demand sync).

Source routing and the Sphinx onion construction

Lightning uses source routing — the sender constructs the full hop sequence before sending the payment. Each hop sees only the immediate adjacent hops (predecessor and successor); intermediate hops do not see the payment’s full path or the sender’s or recipient’s identity. This is the privacy property.

The Sphinx onion construction. The sender constructs a fixed-size (1300 bytes) onion packet that contains an encrypted layer for each hop. Each layer contains:

  • The next hop’s node public key
  • The amount to forward (in millisatoshis)
  • The outbound HTLC’s expiry blockheight
  • A MAC for integrity

Each hop decrypts its layer to learn the next hop’s identity and the forwarding parameters, then forwards the remaining onion (padded back to 1300 bytes) to that next hop. The final recipient sees a “you are the final destination” marker rather than another hop’s identity.

The padding-to-fixed-size guarantees that an intermediate hop cannot infer its position in the route from the onion’s size. Combined with the per-hop encryption, this provides the structural privacy guarantee.

Pathfinding mechanics

The sender’s pathfinding algorithm takes as input:

  • The target node’s public key (from the invoice)
  • The payment amount (in millisatoshis)
  • The sender’s gossip-derived topology and per-channel routing policies
  • The sender’s view of likely channel liquidity (inferred from past routing successes and failures)
  • Optional route hints provided in the invoice (for private-channel destinations)

And produces a candidate route (sequence of hops) that minimizes a cost function — typically weighted combination of routing fees, cltv-delta budget, and inferred liquidity probability.

The liquidity-inference problem. Channel announcements publish only total capacity, not the live balance between participants. Pathfinding must guess at which channels have sufficient outbound balance in the requested direction. Modern pathfinders use a probability model that incorporates past success and failure information: a channel that recently succeeded in a similar payment is high-probability; a channel that recently failed is low-probability. The probability model converges with experience but produces failed payment attempts on cold-start.

Multi-path payments. The Atomic Multi-Path (AMP) and Multi-Path Payment (MPP) extensions split a single logical payment across multiple physical routes. The receiver collects partial HTLCs and finalizes when sufficient total amount has arrived. This addresses payment-amount-larger-than-best-channel-capacity scenarios and improves the routing-failure recovery profile.

Trampoline routing. The trampoline-routing extension allows a sender to delegate pathfinding for the latter portion of a route to an intermediate “trampoline node.” The sender computes the route to the trampoline; the trampoline node computes the route from itself to the final recipient. This reduces the sender’s required topology view and bandwidth (the sender does not need the full gossip database to use the trampoline’s pathfinding). Trampoline routing is implementation-dependent; Eclair supports it natively.

Blinded paths. BOLT 12 introduces blinded paths — invoice-encoded route hints that obscure the recipient’s identity from the sender. The sender computes a route to a “blinding point” published in the invoice; the recipient’s node maintains the unblinded mapping. Blinded paths provide receiver privacy that the original Lightning invoice format lacked.

Routing-fee economics

Each forwarded hop earns a routing fee specified by the channel’s most recent channel_update:

  • Base fee (msat): paid per HTLC regardless of size
  • Proportional fee (ppm — parts per million of the forwarded amount in msat)

A typical mid-2026 fee profile for a routing-active channel might be 1 msat base and 1-100 ppm proportional. Very low ppm encourages flow; higher ppm captures more value per payment but routes less volume.

The fee discovery problem. Routing fees are set unilaterally by channel operators. Senders’ pathfinders compete on fee minimization; channel operators compete on fee competitiveness. Equilibrium fee rates have settled at low single-digit-to-low-double-digit ppm for the bulk of routing channels.

Inbound-liquidity provisioning fees. Operating a routing node profitably requires maintaining channel balances on the side that needs them. Inbound-liquidity provisioning (channels with balance on the operator’s side, available for incoming payment forwards) is a real operational cost. Some routing nodes have moved to dedicated services or paid liquidity-provisioning protocols.

Lightning Service Providers (LSPs)

The LSP architecture has emerged to bridge the gap between Lightning’s protocol-level self-sovereignty and the operational reality of running a Lightning node.

What LSPs do:

  • Just-in-time channels (JIT channels). A client requests an inbound payment; the LSP opens a channel to the client on-demand to receive the inbound payment, then leaves the channel open for future use. The client pays a fee (typically a one-time channel-open fee plus ongoing forwarded fees) for the inbound liquidity.
  • Inbound-liquidity sales. An LSP sells inbound capacity to clients who need to receive payments. Pricing is typically per-month-per-million-sats or upfront for a fixed channel size.
  • Managed routing. An LSP operates the client’s Lightning channels on the client’s behalf, optionally with the client’s key material or via collaborative signatures. The client retains ownership of channel funds but delegates operational complexity.
  • Hot-wallet Lightning integration. An LSP provides Lightning-enabled wallet functionality to mobile and web wallets that cannot operate a full Lightning node themselves.

Major LSP services include Olympus (Lightning Labs), Voltage, OpenNode, and many others. Each operates with different trust profiles; the architecture is not uniform.

The LSP tradeoff. LSPs make Lightning usable for casual participants at the cost of introducing trusted intermediaries. Pure self-sovereign Lightning (run-your-own-node-with-direct-channel-management) is the maximalist ideal; LSP-mediated Lightning is the practical mainstream. The middle ground (LSP-assisted self-custodial Lightning, where the client retains key material and the LSP provides operational services) is the active design frontier.

Routing-concentration dynamics

Empirical observation of Lightning’s deployed topology reveals a hub-and-spoke structure:

  • A small number of well-connected high-capacity nodes route the majority of payments.
  • Many smaller leaf nodes maintain single or few channels and rely on the hubs for connectivity.
  • The largest few hundred nodes account for the substantial majority of routable network capacity.

The concentration is not arbitrary. Pathfinding favors high-capacity well-connected nodes because they offer shorter paths and higher success probability. Channel-open economics favor connecting to hubs because hub connections route to many other nodes. The network’s structural incentives reward concentration.

The decentralization concern. A hub-and-spoke topology has fewer practical points of failure than a fully-distributed mesh would; an adversarial actor targeting the few largest hubs could materially disrupt routing. The concern is real and is engaged substantively in Lightning Network operational critiques.

The defense. The hub-and-spoke topology is not custody-centralizing in the way that exchange concentration is — channels are non-custodial; users retain key control. Routing concentration is operational concentration, not custodial concentration. Plus, the network-level decentralization can be increased without reorganizing protocol-level mechanics (e.g., users can choose smaller-hub paths; LSP competition keeps individual hubs accountable).

Tradeoffs and design choices

Source routing vs broadcast routing. Source routing requires the sender to know enough of the network’s topology to compute paths. This has privacy benefits (intermediate hops don’t know full paths) but bandwidth costs (gossip propagation) and computational costs (pathfinding latency). Alternative architectures (broadcast routing, network-mediated routing) would shift these costs differently. The Lightning design chose source-routing-with-onion-encryption as the privacy-vs-performance compromise.

Liquidity-information opacity vs payment-routing efficiency. Channels do not publish live balance information; this is a privacy choice. The cost is that pathfinding cannot directly know which channels have sufficient outbound balance and must infer or attempt-and-retry. Some proposals (e.g., probabilistic liquidity advertisements) would surface live-balance probabilities; the design tradeoff between routing efficiency and balance privacy is unsettled.

Routing concentration as an emergent property. The hub-and-spoke topology is not designed; it emerges from individual node-operator choices about channel partners and capacity. The design choice was decentralization-by-construction — every node is equal at the protocol level — but the equilibrium is structurally hubs-and-spokes. This is the unavoidable consequence of payment-network economics. See Lightning Network operational critiques for the substantive engagement.

LSP-mediated UX vs pure self-sovereignty. The Lightning protocol assumes participants can operate full nodes with persistent online status. Real-world casual users cannot. LSPs fill the gap, but introduce trusted intermediaries that the maximalist position is uncomfortable with. The Bitcoin-self-custody-discipline ladder applies recursively to Lightning: hot custodial wallet < LSP-assisted hot self-custody < full self-sovereign node operation. See Self-custody configuration ladder for the analogous on-chain framework.

Substantive analytical critique of routing concentration, LSP centralization, and the payment-failure UX lives in Lightning Network operational critiques and Custody concentration risks for the LSP-as-quasi-custodian concerns.

Open questions for further development

  • Will blinded paths (BOLT 12) become the default invoice format? The privacy improvement is real; the adoption barrier is wallet-and-LSP support. Trajectory is favorable but not complete.
  • Can the LSP architecture evolve to reduce trust requirements substantively? The collaborative-signing and channel-factory proposals would meaningfully reduce LSP custody exposure. Implementation timelines are uncertain.
  • How does atomic multi-path payment (AMP) adoption affect routing-failure UX? AMP improves the routing-failure profile but has not been universally adopted in the implementation ecosystem.
  • What is the trajectory of trampoline routing’s adoption? Trampoline reduces sender-side bandwidth requirements; mobile-Lightning adoption depends on it but the implementation rollout has been uneven.
  • How does Lightning’s privacy compare in practice to alternatives (statechains, Ark, on-chain Coinjoin)? Lightning’s hop-level privacy is structurally good; payment-level privacy depends on routing-graph anonymity that is empirically partial. See Lightning privacy properties for the dedicated treatment.

Canonical sources for this note

Specifications

  • BOLT 04 — Onion Routing Protocol: github.com/lightning/bolts/blob/master/04-onion-routing.md
  • BOLT 07 — P2P Node and Channel Discovery: github.com/lightning/bolts/blob/master/07-routing-gossip.md
  • BOLT 11 — Invoice Protocol for Lightning Payments: github.com/lightning/bolts/blob/master/11-payment-encoding.md
  • BOLT 12 — Flexible Protocol for Lightning Payments (offers, blinded paths): bolt12.org

Foundational and analytical references

  • Mastering the Lightning Network — Chapters 10-13 treat routing, gossip, and pathfinding at depth
  • “Lightning Network Path-Finding: A Review and a Proposal” — René Pickhardt and Stefan Richter analytical work on minimum-cost-flow routing
  • “Sphinx: A Compact and Provably Secure Mix Format” — George Danezis and Ian Goldberg (2009) — the onion-routing construction Lightning uses

Graph View

Backlinks