Multi-Hop Payment

What Is a Multi-Hop Payment?

A multi-hop payment is a transaction that travels through one or more intermediary nodes in a payment channel network to reach its destination. When a sender and receiver do not share a direct payment channel, the payment is relayed across a chain of connected channels, with each node along the path forwarding it to the next. This mechanism is fundamental to how the Lightning Network and similar layer-2 protocols scale: instead of requiring a channel with every counterparty, users connect to the broader network through a handful of channels and rely on multi-hop routing to reach anyone.

The concept mirrors how packets move through the internet. Your data does not travel on a direct wire from your computer to the destination server: it hops through routers, each one forwarding the packet closer to its destination. Similarly, a multi-hop payment hops through routing nodes, each one forwarding the value one step closer to the final recipient. The critical difference is that multi-hop payments are trustless: cryptographic contracts guarantee that intermediaries cannot steal funds or selectively fail the payment.

How It Works

Multi-hop payments rely on a chain of Hash Time-Locked Contracts (HTLCs) to enforce atomicity. The entire process is source-routed: the sender computes the full path and constructs all forwarding instructions before initiating the payment.

1. The receiver generates a random secret (the preimage) and computes its payment hash. This hash is embedded in a Lightning invoice sent to the payer.
2. The sender uses path-finding to select a route through the network, then constructs an onion-encrypted packet containing per-hop forwarding instructions.
3. The sender creates an HTLC with the first intermediary, locking funds that can only be claimed by revealing the preimage before a timelock expires.
4. Each intermediary peels one layer of the onion, learns the next hop, and creates a new HTLC on the outgoing channel with a slightly reduced amount (retaining a routing fee) and a shorter timelock.
5. When the HTLC chain reaches the receiver, they reveal the preimage to claim the final HTLC.
6. The preimage propagates backward through the chain: each intermediary uses it to claim their incoming HTLC, collecting their routing fee in the process.

Because every HTLC in the chain uses the same payment hash, the payment is atomic: either all hops settle (everyone gets paid) or none do (the sender recovers their funds via timelock expiry). No intermediary can steal funds or selectively withhold the preimage.

HTLC Timelock Decrements

Each hop in the route decrements the timelock by a configurable CLTV delta, typically 40 to 144 blocks. This staggering ensures each intermediary has enough time to claim their incoming HTLC before their outgoing HTLC expires. For example, if the final hop expires at block 800,000, the previous hop might use 800,050, and the one before that 800,100. This cascading structure prevents a scenario where an intermediary's outgoing HTLC expires before they can claim their incoming one.

Onion Routing and Privacy

Lightning uses a protocol derived from the Sphinx cryptographic packet format for onion routing. The sender constructs a 1,366-byte encrypted packet with up to 20 layers of encryption, one per hop. Each intermediary can only decrypt their own layer, which reveals:

• The amount to forward to the next hop
• The outgoing channel to use
• The timelock value for the next HTLC

Each intermediary does not learn the payment's origin, final destination, their position in the route, or the total number of hops. This design provides strong privacy guarantees, though it is not perfect: balance probing and timing analysis can leak information. Blinded paths further strengthen receiver privacy by hiding the last few hops from the sender entirely.

Path-Finding Algorithms

All major Lightning implementations use variants of Dijkstra's shortest-path algorithm, but with different cost functions reflecting different optimization priorities. For a deeper exploration of Lightning routing, each implementation takes a distinct approach:

• LND uses a modified Dijkstra with a Mission Control system that records past success and failure amounts per channel. Its cost function incorporates fees, timelock risk, and an a priori success probability (starting at 60% for untried channels), prioritizing reliability.
• Core Lightning uses standard Dijkstra with additive costs that weight timelock exposure alongside fees, prioritizing minimal capital lock duration.
• Eclair uses Yen's K-shortest path algorithm, evaluating multiple candidate routes to find the lowest-fee option.
• LDK balances reliability with fees using additive costs and penalty scoring for unreliable channels.

A fundamental challenge for all implementations is that channel balances are private. Senders must estimate whether intermediate channels have sufficient liquidity on the correct side, making path-finding inherently probabilistic. Failed attempts require retries on alternative routes, adding latency.

Routing Fee Structure

Each intermediary in a multi-hop payment charges a routing fee for forwarding the payment. The fee has two components:

total_fee = base_fee + (amount × fee_rate_ppm / 1,000,000)

Example: 3-hop payment of 100,000 sats
  Base fee per hop:      1 sat
  Fee rate per hop:      100 ppm (0.01%)
  Per-hop fee:           1 + (100,000 × 100 / 1,000,000) = 11 sats
  Total across 3 hops:   ~33 sats (0.033%)

The base fee is a flat charge per forwarded payment, covering fixed overhead like HTLC verification and commitment transaction updates. The proportional fee compensates routing nodes for the opportunity cost of locked capital. The network trend is moving toward zero base fees, which simplifies path-finding by converting the cost model from additive-plus-multiplicative to purely multiplicative.

Use Cases

Everyday Lightning Payments

The most common use case is routine: any payment between two parties that do not share a direct channel. When you pay a merchant, tip a content creator, or send sats to a friend, the payment almost certainly traverses multiple hops. With well-connected nodes, typical payments complete in under a second across roughly three hops, with fees often below 0.05% of the payment amount.

Cross-Network Routing

Multi-hop routing enables value transfer across entire networks without requiring direct relationships. A user in Brazil can pay a merchant in Nigeria if a connected path exists between their nodes, making Lightning a viable cross-border payment rail without correspondent banking intermediaries.

Multi-Path Payments

Multi-path payments (MPP) split a single payment across multiple multi-hop routes simultaneously. Instead of finding one path with enough capacity for the full amount, the sender divides the payment into smaller parts and routes each through independent paths. This significantly improves success rates for larger payments: the total payable amount becomes the sum of all available route capacities rather than the maximum single-channel balance. For more on how this works, see the research on multipath payment reliability.

Trampoline Routing

Trampoline routing delegates path-finding to intermediate nodes. Mobile wallets with limited network graph data can specify a few well-connected trampoline nodes and let those nodes compute the detailed multi-hop path for the remaining route, reducing the computational and bandwidth requirements on resource-limited devices.

Why It Matters

Multi-hop routing is what transforms isolated payment channels into a global payment network. Without it, every pair of transacting parties would need a direct channel funded with sufficient liquidity in both directions: an impractical O(n²) scaling problem. Multi-hop routing reduces this to O(n): each participant needs only a few well-connected channels to reach any other participant in the network.

This architecture enables the Lightning Network to support millions of users with far fewer on-chain transactions than direct settlement would require. Platforms like Spark build on this foundation to deliver instant settlement and low fees for Bitcoin and stablecoin payments at scale.

The Future: PTLCs

Point Time-Locked Contracts (PTLCs) are a proposed upgrade that replaces hash-based locks with elliptic curve point-based locks using adaptor signatures. The key improvement is privacy: with HTLCs, the same payment hash appears at every hop, allowing an adversary controlling two non-adjacent nodes to correlate the payment. PTLCs use a unique cryptographic value at each hop, breaking this correlation entirely.

PTLCs also prevent wormhole attacks, where a malicious actor controlling two nodes on a route bypasses honest intermediaries to steal their routing fees. Additionally, settled PTLCs appear as standard Taproot transactions on-chain, indistinguishable from regular single-signature spends. While PTLCs became technically feasible after the Taproot activation in November 2021, no major Lightning implementation has shipped production PTLC support as of 2026.

Risks and Considerations

Routing Failures

Because channel balances are private, senders cannot know with certainty whether a chosen route has sufficient liquidity. A payment may fail partway through the route and require retries on alternative paths. Well-configured nodes report success rates above 99% for typical payment sizes, but larger payments see significantly lower reliability: simulations show that 100,000-sat payments on random paths average only one successful transfer before the first failure.

Channel Jamming

Channel jamming attacks exploit the multi-hop structure by flooding channels with fake HTLCs or holding HTLCs open until near-expiry. This locks up channel capacity and prevents legitimate payments from routing through affected nodes. The Lightning community is developing mitigations including HTLC endorsement and reputation-based forwarding, but channel jamming remains a largely unsolved denial-of-service vector.

Privacy Limitations

While onion routing hides the full path from intermediaries, HTLC-based payments share the same hash across all hops. An adversary operating multiple routing nodes can correlate payments by matching hash values, potentially de-anonymizing senders and receivers. Balance probing (sending payments of varying amounts to infer channel states) and timing analysis further erode privacy. For a detailed analysis, see the research on Lightning privacy.

Fee Accumulation

Fees accumulate at each hop in a multi-hop payment. While typical three-hop payments incur negligible fees (around 0.03%), longer routes or channels with aggressive fee policies can become expensive, particularly for larger amounts. Payments traversing five or more hops have been observed to incur average fees approaching 7%, compared to roughly 0.15% for single-hop transfers.

Liquidity Lock and Timelocks

Every pending HTLC in a multi-hop payment locks liquidity not just for the sender but for every routing node along the path. With CLTV deltas of 40 to 144 blocks per hop and up to 20 possible hops, the total timelock for the sender can be substantial. If an intermediate node goes offline or a channel must be force-closed, funds may remain locked for days while timelocks expire.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.