Lightning Routing Algorithms: Pathfinding and MPP Explained

How Lightning Payments Find Their Path

Every Lightning payment must traverse a path of payment channels from sender to receiver. Unlike on-chain Bitcoin transactions that broadcast to the entire network, Lightning payments are routed hop-by-hop through specific intermediary nodes. The sender is responsible for computing the full route before dispatching the payment, which means pathfinding quality directly determines whether the payment succeeds, how much it costs, and how fast it settles.

All major Lightning implementations use variants of Dijkstra's shortest-path algorithm, but each applies a different cost function to balance fees, reliability, and privacy. The differences are significant: one implementation may favor the cheapest route, another may favor the most reliable, and a third may compute an optimal split across multiple paths simultaneously.

Pathfinding by Implementation

The four major Lightning implementations: LND, Core Lightning (CLN), Eclair, and LDK each take a distinct approach to pathfinding. The following table summarizes their strategies.

LND: Mission Control and Route Scoring

LND's pathfinding uses a modified Dijkstra algorithm that searches backward from the destination to the source (standard for Lightning since fees are direction-dependent). The cost function combines fees with a reliability penalty:

cost = base_fee + fee_rate × amount + (attempt_cost + attempt_cost_ppm × amount) / P

In this formula, P is the estimated success probability for that hop. The attempt_cost parameter (default: 100 sats) controls the tradeoff between reliability and fees: higher values cause the pathfinder to favor proven-reliable routes even when they charge more.

Mission Control is the subsystem that estimates P. It tracks success and failure history per channel pair, recording the amounts that succeeded (lower bound on available liquidity) and the amounts that failed (upper bound). LND offers two probability models:

• Apriori model: assigns a base success probability of 60% per hop, adjusting to 95% after a successful payment through that hop and 0% for amounts above a failed threshold. Penalties decay with a configurable half-life (default: 1 hour).
• Bimodal model (recommended since LND v0.19, June 2025): assumes channel liquidity is skewed to one side based on Pickhardt's research. Uses a 7-day decay period and produces more accurate probability estimates for amounts that differ from previous attempts.

For a deeper look at how LND manages channel state, see our guide on Lightning Network routing.

Core Lightning: Minimum-Cost Flow

CLN has undergone the most radical evolution in routing strategy. The legacy pay plugin used standard Dijkstra, but CLN v23.08 introduced renepay, based on the Pickhardt-Richter research paper ("Optimally Reliable and Cheap Payment Flows on the Lightning Network"). Since v24.08, this has been further split into two plugins: xpay (payment execution) and askrene (routing advice via the MCF solver).

The minimum-cost flow approach is fundamentally different from single-path Dijkstra. Instead of finding one shortest path and then retrying on failure, the MCF solver models the entire payment as a flow problem across the network graph. It computes an optimal split across multiple paths simultaneously, minimizing both fees and failure probability in a single computation. When a payment attempt partially fails, the result is fed back into the MCF solver to refine the next attempt.

CLN v25.09 added limits on the maximum number of parts a payment can be split into, preventing excessive fragmentation that increases overall failure risk.

LDK: Probabilistic Scoring

LDK's ProbabilisticScorer maintains per-channel liquidity bounds and a histogram of observed liquidity states. For each channel direction, it tracks a lower bound (updated on HTLC success) and an upper bound (updated on HTLC failure due to insufficient liquidity). These bounds decay back to defaults over time.

The historical tracking system stores 32 variable-sized buckets per channel direction. The first bucket covers the first 1/16,384th of channel capacity, providing extremely fine granularity near the edges where most liquidity tends to concentrate. Key scoring parameters include:

• base_penalty_msat: fixed penalty per hop
• liquidity_penalty_multiplier_msat: multiplied by the negative log-probability of success
• historical_liquidity_penalty_multiplier_msat: penalty based on historical bucket data
• anti_probing_penalty_msat: extra penalty to discourage channel probing

LDK v0.1 (January 2025) adjusted default penalty values to allow higher fees in exchange for reduced payment latency, reflecting a shift toward prioritizing reliability over minimizing cost.

Eclair: K-Shortest Paths

Eclair uses Yen's K-shortest paths algorithm, which finds multiple candidate routes rather than a single best path. This approach is unique among the four implementations and tends to produce paths with the lowest fees in benchmarks. The weight function includes a logarithmic success probability term combined with fixed and proportional virtual cost components.

Eclair is also the only implementation with production trampoline routing support. This powers the Phoenix mobile wallet: instead of syncing the full network graph, Phoenix constructs a simplified onion with only trampoline nodes, and each trampoline node computes the detailed route to the next hop. This drastically reduces bandwidth and storage requirements for mobile devices.

Gossip Protocol: Learning the Network Topology

Before a node can route payments, it needs a map of the network. The gossip protocol (defined in BOLT #7) is how nodes discover and maintain this map. Three message types carry routing information:

• channel_announcement (~430 bytes): proves a channel exists by referencing an on-chain funding transaction. Includes the short channel ID, both node public keys, and four signatures (both node keys and both funding keys).
• channel_update (~130 bytes per direction): carries the fee policy and constraints for one direction of a channel. Fields include fee_base_msat, fee_proportional_millionths, cltv_expiry_delta, and htlc_maximum_msat. Nodes should not send more than one update per channel per block (~10 minutes).
• node_announcement (~280 bytes): advertises node metadata (alias, color, addresses, supported features). Only valid if the node has at least one announced channel.

With roughly 40,000+ public channels on the network, initial graph sync requires approximately 34 MB of gossip data. The gossip_timestamp_filter message allows nodes to request only updates after a specific time, reducing ongoing bandwidth. Gossip v2 proposals based on set reconciliation (similar to Bitcoin's Erlay) are under active research to scale gossip to 100,000+ nodes.

For real-time network statistics, see our Lightning network statistics dashboard.

Multi-Path Payments

Multi-path payments (MPP) allow a single payment to be split across multiple routes, solving the fundamental problem that no single channel may have sufficient liquidity for a large payment. MPP is defined in the BOLT specifications (feature bits 16/17) and supported by all major implementations.

In base MPP, all parts share the same payment_hash and payment_secret. The receiver holds incoming HTLCs without settling until the total amount received matches the invoice's total_msat value. If a timeout expires before all parts arrive, the receiver fails all partial HTLCs.

Atomic Multi-Path Payments (AMP), implemented in LND, provide a stronger guarantee: each part uses a unique payment_hash derived from a shared root secret via additive secret sharing. The receiver can only reconstruct the preimage once all shares arrive, providing cryptographic all-or-nothing settlement.

Splitting strategies vary by implementation. LND first attempts a single path, then applies a "presplit modifier" that divides the payment into ~10,000 sat parts (roughly $1 each at early 2025 prices), which succeed about 80% of the time. Parts are fuzzed by +/-10% for privacy. If a part fails, LND's "adaptive splitter" halves it with random fuzz. CLN's MCF solver computes the optimal split upfront rather than using trial-and-error.

Onion Routing and Privacy

Lightning payments use onion routing (BOLT #4) to preserve privacy. The sender constructs a layered encrypted packet where each hop can only decrypt its own forwarding instructions. Intermediate nodes learn only the previous hop and the next hop: they cannot determine the sender, receiver, or total path length.

Blinded paths, formally merged into the spec with BOLT 12 (September 2024), extend this privacy to the receiver. The receiver constructs an encrypted path from an "introduction node" to themselves. The sender routes normally to the introduction node, which then forwards along the blinded segment. The sender never learns the receiver's node ID or channel structure. CLN, Eclair, and LDK all support blinded paths in production. LND support is improving incrementally.

For more on Lightning privacy techniques, see our research on onion routing and Lightning privacy.

Routing Failures and Error Codes

Routing failures are inevitable on Lightning. Channels run out of liquidity, nodes go offline, and fee policies change between gossip updates. BOLT #4 defines a structured set of failure codes that intermediary nodes return when they cannot forward an HTLC. These codes are encrypted in the onion return path so only the sender can read them.

Each implementation uses these failure codes to update its internal scoring model. On temporary_channel_failure, LND's Mission Control records the failed amount as a new upper bound on available liquidity for that channel. LDK adjusts its upper liquidity bound downward and updates historical buckets. On fee_insufficient, all implementations extract the included channel_update to refresh their local fee data. On unknown_next_peer, the hop is permanently removed from future route calculations.

Attributable failures (proposed feature bits 36/37) are an in-progress specification that would allow senders to definitively identify which node caused a failure, further improving routing decisions.

Routing Fees and Optimization

Routing fees on Lightning follow a two-part structure defined in channel_update messages:

fee = fee_base_msat + (amount × fee_proportional_millionths / 1,000,000)

Base fees typically range from 0 to 1,000 millisatoshis, while proportional fees range from 1 to 5,000 ppm (parts per million). A payment of 100,000 sats through a channel charging 1 sat base + 100 ppm would pay 11 sats in fees for that hop. Total fees accumulate across all hops in the route.

LND v0.18 (May 2024) introduced inbound fee discounts, allowing nodes to set negative inbound fees. These discounts signal that a node has available inbound liquidity and wants to attract payments in that direction, effectively helping the network self-balance. For current fee data across the network, see our Lightning routing fee comparison.

Building on Lightning Routing

Developers building Lightning applications need to choose a routing stack that matches their use case. Mobile wallets with limited bandwidth benefit from trampoline routing (Eclair/Phoenix) or delegating pathfinding to an LSP. Server-side applications that process high volumes may prefer LDK's fine-grained scoring controls or LND's mature Mission Control system.

Protocols like Spark take a different approach to Bitcoin payments by operating as a Layer 2 that does not require pre-funded channels or routing at all, eliminating the pathfinding complexity described in this guide. For applications where Lightning routing is the right fit, understanding these algorithms helps operators configure their nodes for better payment success rates and lower fees.

Frequently Asked Questions

How does Lightning Network routing work?

The sender computes a full route from itself to the receiver before dispatching the payment. Using its local copy of the network graph (learned via the gossip protocol), the sender runs a pathfinding algorithm (typically a variant of Dijkstra's algorithm) to find the lowest-cost path. The payment is then wrapped in an onion-encrypted packet so each intermediary node only knows the previous and next hop. If the payment fails at any point along the route, the sender updates its scoring model and retries with a different path.

What is Mission Control in LND?

Mission Control is LND's subsystem for tracking payment attempt outcomes and estimating route reliability. It records which amounts succeeded or failed through each channel pair and uses this history to assign success probabilities to future route candidates. LND v0.19 (June 2025) promoted the bimodal probability model as the recommended default, which assumes channel liquidity is skewed to one side and provides more accurate estimates than the older apriori model.

What are multi-path payments on Lightning?

Multi-path payments (MPP) split a single payment across multiple routes so that no single channel needs to have the full payment amount available. All parts share the same payment hash and the receiver waits until all parts arrive before settling. This significantly increases the maximum payment size and improves success rates for larger payments. MPP is supported by all major implementations and defined in the BOLT specifications.

Why do Lightning payments fail?

The most common cause is insufficient liquidity along the chosen route: a channel may have the capacity on paper but not enough balance on the correct side to forward the payment. Other causes include offline nodes, stale fee policies in the sender's local graph, CLTV delta mismatches, and disabled channels. Implementations mitigate failures through automatic retries with updated scoring, multi-path splitting, and payment probes that test routes before committing real funds.

What is the difference between LND, CLN, Eclair, and LDK routing?

LND uses a modified Dijkstra algorithm with Mission Control for probabilistic scoring. CLN uses a minimum-cost flow solver based on Pickhardt-Richter research, computing optimal multi-path splits in a single computation. Eclair uses Yen's K-shortest paths algorithm to find multiple candidate routes and is the only implementation with production trampoline routing. LDK uses Dijkstra with a ProbabilisticScorer that maintains per-channel liquidity histograms with 32 variable-sized buckets.

What is trampoline routing?

Trampoline routing allows a sender to delegate route computation to intermediate nodes. Instead of computing the full path, the sender constructs a simplified onion with only "trampoline nodes" that each compute the detailed route to the next trampoline hop. This is especially useful for mobile wallets that cannot store the full network graph. Eclair is the only implementation with full production support, powering the Phoenix wallet. LDK has added partial support for receiving trampoline payments.

How does the Lightning gossip protocol work?

Nodes exchange three types of messages defined in BOLT #7: channel_announcement (proves a channel exists on-chain), channel_update (carries fee policies and constraints per direction), and node_announcement (advertises node metadata). Initial graph sync requires roughly 34 MB of data for the current network. Nodes use gossip_timestamp_filter to request only recent updates, and gossip v2 proposals aim to reduce bandwidth further using set reconciliation techniques.

This tool is for informational purposes only and does not constitute financial advice. Technical details reflect the state of Lightning implementations as of mid-2026 and are based on publicly available documentation, release notes, and specification documents. Implementations evolve rapidly: always consult the latest release notes and BOLT specifications before making architectural decisions.