Lightning Network Routing: Pathfinding, Fees, and Optimization

Every Lightning payment faces the same fundamental challenge: finding a path through a network of private channels where no single participant knows the full state. Unlike on-chain Bitcoin transactions that broadcast to every node, Lightning Network routing requires the sender to construct a complete route before the payment leaves their wallet. The sender must guess which channels along the path have enough liquidity to forward the payment, and a wrong guess means the payment fails and must be retried on a different route.

This article breaks down how Lightning onion routing actually works at the implementation level: the algorithms each major client uses, the fee structures that shape the network, the economics of running a routing node, and the recent advances in multipath payments that have pushed success rates above 99%.

Why Routing Is Hard

Lightning channels are funded with a fixed capacity, but the balance on each side shifts with every payment forwarded. A channel with 1 BTC total capacity might have 0.3 BTC on the local side and 0.7 BTC on the remote side at any given moment. Only the two channel partners know the current split. Everyone else sees the total capacity via the gossip protocol but has no visibility into the balance distribution.

This creates an information asymmetry at the core of the routing problem. The sender needs to find a path where every hop has sufficient inbound liquidity on the receiving side, but the sender cannot observe those balances directly. Publicly disclosing channel balances would make routing trivial, but it would also allow anyone to trace payments by watching balance changes across the network: a direct conflict between routing efficiency and payment privacy.

The core tradeoff: Hidden channel balances protect user privacy but force routing algorithms to operate with incomplete information. Every pathfinding implementation is fundamentally a system for making educated guesses about liquidity distribution.

Pathfinding Algorithms by Implementation

The four major Lightning implementations each take a different approach to solving the same problem. All build on Dijkstra's shortest-path algorithm, but they diverge significantly in how they model success probability, penalize risk, and learn from past failures.

LND: Mission Control and Bimodal Probability

LND uses a modified Dijkstra implementation with a composite cost function that combines fees, timelock risk, and success probability. The cost for a given path is calculated as:

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

The critical term is the inverse probability (1/P). Unlike other implementations that use -log(P), LND's inverse penalization creates a steeper penalty curve for unreliable channels. A channel with a 10% estimated success rate costs 10x more than a channel with 100%: the logarithmic approach would only add 2.3x. This makes LND more aggressive at avoiding channels that have recently failed.

LND's Mission Control system records the result of every routing attempt: the amount, timestamp, and whether each hop succeeded or failed. It offers two probability models. The older apriori model assigns a flat 60% success probability to untested channels. The newer bimodal model, introduced in LND v0.16, assumes channel liquidity follows an exponential distribution skewed toward the edges (channels tend to be mostly full or mostly empty). Learnings decay with a configurable half-life defaulting to 7 days.

Core Lightning: Renepay and Minimum Cost Flow

CLN's default pathfinding uses standard Dijkstra with a uniform liquidity distribution model: the probability that a channel can forward amount a through a channel with capacity c is simply (c - a) / c. This enables fully additive costs with logarithmic penalization (-log(P)), which guarantees optimal solutions.

The more interesting development is CLN's renepay plugin, introduced in v23.08. Based on the Pickhardt-Richter payment optimization framework, renepay treats payment delivery as a minimum cost flow problem. Rather than finding a single best path, it computes the optimal way to split a payment across multiple channels simultaneously. It collects feedback from failures and iterates, with knowledge decaying after one hour. In CLN v24.08, the probability cost function was refined to include a constant term for the probability that a remote channel rejects forwarding independently of its liquidity.

Eclair: K-Shortest Paths and Channel Age

Eclair (which powers the Phoenix wallet) is unique among implementations in two ways. First, it implements Yen's K-shortest path algorithm, returning a ranked list of the best routes rather than a single shortest path. Second, it incorporates channel age as a reliability indicator: older channels are assumed to be more stable and better maintained. No other major implementation uses channel age as a routing signal.

Eclair uses logarithmic probability penalization like CLN and LDK, with a lockedFundsRisk parameter instead of the riskfactor used by LND and CLN. Research from an October 2024 academic analysis found that Eclair empirically produces the lowest-fee paths among all implementations, while LND produces paths with the shortest timelocks.

LDK: Bounded Probability with Probing Resistance

LDK (Lightning Development Kit) maintains upper and lower bounds on channel liquidity, adjusted dynamically from payment histories with time decay. The probability estimate uses these bounds: P = (upper_bound - amount) / (upper_bound - lower_bound). This creates a tighter estimate than CLN's uniform model as the bounds narrow with more observations.

A notable LDK-specific feature: it penalizes channels where HTLC maximum values exceed 50% of channel capacity. This serves as a probing deterrent, since channels that accept very large HTLCs relative to their capacity are more useful for balance discovery attacks.

Pathfinding Comparison

How Lightning Fees Work

Every routing node sets two fee parameters for each of its channels. The routing fee charged per forwarded HTLC is:

fee = base_fee_msat + (amount_msat × fee_rate_ppm / 1,000,000)

The base_fee_msat is a flat charge per forwarded payment, denominated in millisatoshis. A base fee of 1000 msat equals 1 satoshi per routed payment regardless of size. The fee_rate_ppm is a proportional charge in parts per million: 100 ppm means 100 satoshis per 1,000,000 satoshis forwarded, or 0.01%. For a multi-hop payment, fees accumulate across all intermediate nodes.

Default Values and Network Norms

LND ships with a default base fee of 1000 msat (1 sat) and a fee rate of 1 ppm: effectively free for proportional fees but with a fixed floor per payment. Roughly two-thirds of Lightning nodes run on these LND defaults. CLN and Eclair have moved toward lower or zero base fees, reflecting an industry trend to eliminate the fixed per-transaction charge that disproportionately burdens micropayments.

As of May 2026, the median base fee across the network is approximately 0.444 satoshis, and the median fee rate is roughly 143 ppm (0.0143%), according to 1ML network statistics. In practice, a three-hop payment of 100,000 satoshis typically costs around 26 satoshis in total routing fees: orders of magnitude cheaper than on-chain transaction fees.

Fees as liquidity signals: Research from Lightning Labs shows that routing fees serve as an indirect signal of channel liquidity. Nodes charge more when liquidity is scarce and discount unused capacity. LND's pathfinding data reveals continuously decreasing success probabilities at higher fee rate buckets, meaning expensive channels often correlate with tighter liquidity.

The Base Fee Debate

A long-running debate in the Lightning community centers on whether base fees should exist at all. The argument against: base fees make the routing cost function non-linear, which technically makes optimal pathfinding NP-complete in LND's formulation. They also penalize small payments disproportionately: a 1-satoshi base fee on a 100-sat micropayment is a 1% charge, while the same fee on a 1,000,000-sat payment is negligible.

The argument for: base fees compensate node operators for the fixed cost of processing each HTLC, which consumes memory, CPU, and on-chain commitment transaction space regardless of payment size. Without base fees, routing nodes would have no protection against being flooded with dust-sized payments that consume resources without generating meaningful revenue.

Route Selection Heuristics

Beyond the core algorithms, implementations use a range of heuristics to filter and rank candidate routes. Understanding these heuristics matters for both wallet developers tuning payment reliability and routing node operators optimizing their fee policies.

Success Probability Estimation

Each implementation maintains a memory of past routing attempts and uses it to update its belief about channel liquidity. LND's Mission Control records the most recent successful and failed amounts per node pair, with a configurable half-life of 3,600 seconds by default. CLN's renepay collects partial network state knowledge from payment responses and decays it after one hour. LDK adjusts its upper and lower liquidity bounds based on attempt outcomes with time decay. All four implementations agree on one principle: recent information is more valuable than stale information.

Timelock Risk

Every hop in a Lightning route adds to the total timelock duration. If a payment gets stuck mid-route, the sender's funds are locked for the cumulative HTLC timeout across all hops. A route with six hops and 40-block timelock deltas per hop means the sender's funds could be locked for 240 blocks (roughly 40 hours) in the worst case. All implementations penalize longer timelocks in their cost functions, though the weight varies: LND's riskfactor converts timelock duration into virtual fees proportional to the payment amount.

Hop Count Limits

The BOLT 4 specification limits onion packets to 20 hops. In practice, implementations constrain paths further: most payments use 2 to 5 hops. Research shows that payment failure rates increase 4 to 8 percent with each additional hop, creating a strong incentive to minimize route length even when longer paths offer lower fees.

Multipath Payments

Multipath payments (MPP) were introduced in LND v0.10 in May 2020 and are now supported by all major implementations. The idea is straightforward: instead of routing a large payment through a single path (which requires every channel along the way to have sufficient liquidity), split the payment into smaller shards and route each shard independently.

How MPP Works

All shards of a Basic MPP payment share the same payment hash. The recipient holds each incoming HTLC without settling it until all parts arrive. Once the full amount is collected, the recipient reveals the preimage and all shards settle atomically. If any shard fails or the full amount does not arrive before the timeout, all pending HTLCs are cancelled: either the entire payment succeeds or nothing moves.

The splitting strategy varies by implementation. CLN's renepay uses minimum cost flow computation to determine the optimal split across channels. LND creates multiple candidate paths and tries them sequentially. The sender has limited visibility into remote channel balances, so the split often involves trial and error: send smaller amounts along several routes and adjust based on which ones succeed.

Atomic Multipath Payments

Atomic Multipath Payments (AMP) are a Lightning Labs extension that uses different payment hashes per shard, derived from a shared secret. This provides stronger proof-of-payment guarantees and supports spontaneous payments (keysend-style). AMP is not part of the official BOLT specifications but is supported by LND.

Impact on Routing Success

MPP significantly improved payment reliability across the network. Smaller shards are easier to route because they require less liquidity at each hop. A 1,000,000-sat payment that would fail on any single path can succeed when split into ten 100,000-sat shards across different routes. Well-configured implementations now achieve payment success rates between 98.7% and 99.7% for standard payment sizes: a dramatic improvement from the sub-95% rates common before MPP adoption.

Trampoline Routing

Standard Lightning routing requires the sender to store the complete network graph (tens of thousands of channels and their fee policies) and compute the full route locally. Trampoline routing delegates route computation to intermediate nodes with better network visibility.

The sender constructs a layered onion: the outer onion routes to a trampoline node, which unwraps it to find a smaller inner onion specifying the next trampoline or the final destination. The trampoline node fills in the missing route segments. This is ideal for mobile wallets that cannot maintain a full channel graph or perform intensive pathfinding.

Currently, Eclair is the only implementation with trampoline routing support, powering the Phoenix wallet. A BOLT proposal (PR #829) exists but has not been merged into the specification. When combined with blinded paths from BOLT12, the final trampoline sends to an obfuscated route, preventing trampoline nodes from learning the recipient's identity.

Probing: The Privacy-Efficiency Tension

Payment probing exploits the routing infrastructure to discover channel balances. An attacker sends fake payments through target channels and uses binary search on error messages to deduce the balance distribution. This can reveal a channel's balance in under a minute per channel, requiring moderate capital commitment but no actual expenditure since failed payments are free.

The irony is that routing implementations themselves use a form of probing. When a payment attempt fails at a specific hop, the sender learns that the channel did not have enough liquidity for that amount: information it uses to update its probability model and retry. The same mechanism that makes pathfinding work also makes privacy attacks possible.

Countermeasures include route blinding (hiding the receiver's last few hops), shadow routing (adding dummy hops to obscure payment paths), and LDK's approach of penalizing channels with large HTLC maximums relative to capacity.

Routing Node Economics

Running a routing node on the Lightning Network is a capital-intensive operation. Operators lock bitcoin in channels, pay on-chain fees to open and close them, and earn routing fees from payments they forward. The economics vary dramatically depending on scale, connectivity, and fee policy.

Revenue and Returns

At the Bitcoin 2025 conference, Block's Bitcoin Product Lead Miles Suter revealed that Block's routing node generates 9.7% annual returns on approximately 184 BTC of deployed liquidity. Suter described this as "true non-custodial yield" from the economic utility of Bitcoin as payment infrastructure. However, researcher Riccardo Masutti noted that Block's yields rely on an aggressive fee structure, with Cash App nodes applying fee rates significantly above the network average.

For smaller operators, returns are more modest. Data from Amboss MAGMA marketplace shows that yields from routing and liquidity leases have ranged between 1% and 4% APY over four years. A mid-size operator with 10 BTC in channels might route roughly 2 BTC per day but earn only around 30,000 satoshis daily. After server hosting and on-chain channel management fees, the operation often approaches break-even.

Capital Efficiency Challenges

The network has consolidated around fewer, larger nodes. The top 10 Lightning nodes control approximately 85% of public capacity, and the node-capacity Gini coefficient reached roughly 0.97 in 2025: extreme concentration. This consolidation improves routing efficiency (fewer hops, more direct paths) but raises centralization concerns and creates barriers to entry for new routing node operators who cannot compete on channel capacity.

Network State in 2026

As of May 2026, the public Lightning Network comprises approximately 6,054 nodes and 19,812 channels with a total capacity of 2,889 BTC ($232 million), per 1ML. These figures only count publicly announced channels: private channels and unannounced nodes are excluded. The network hit a peak capacity of 5,637 BTC in late 2025, driven by institutional capital from companies like Block integrating Lightning into Square point-of-sale terminals.

Transaction volume has grown substantially. Lightning surpassed $1 billion in monthly transaction volume in 2025 and processed over 8 million monthly transactions in early 2025. The average channel age of 632 days (roughly 1.7 years) suggests a maturing network with stable, long-lived channels replacing the churn of earlier years.

Recent Advances in Routing

Several developments in 2025 and 2026 have improved routing reliability and expanded what Lightning can carry.

BOLT12 Offers and Blinded Paths

BOLT12 offers introduced reusable payment requests and blinded paths, where the receiver constructs the final hops of the route and encrypts them. The sender routes to an introduction point without learning the receiver's node identity. This is the most significant privacy improvement for Lightning routing since onion routing was first specified. Both Core Lightning and LDK have shipped BOLT12 support.

Channel Splicing

Channel splicing allows nodes to resize existing channels without closing and reopening them. This reduces the on-chain footprint of channel management and enables more efficient capital allocation. Splicing has been tested interoperably between Core Lightning and Eclair, with CLN introducing Splice Script for automating liquidity management tasks.

PTLCs: The Next Evolution

Point Time Locked Contracts (PTLCs) would replace HTLCs with adaptor signatures using elliptic curve points instead of hashes. The routing privacy improvement is significant: with HTLCs, every hop in a route uses the same payment hash, allowing colluding nodes to correlate payments. PTLCs give each hop a distinct point, breaking this correlation. PTLCs remain in the research and specification phase as of 2026 and depend on broader Taproot adoption across Lightning implementations.

The Alternative: No Routing at All

Lightning routing has improved enormously since the network launched, but it remains a complex system built on imperfect information. Every payment requires the sender to guess a viable path, manage timelock risk, and handle failures gracefully. Routing node operators must deploy significant capital and actively manage liquidity to remain competitive. The concentration of routing capacity among a handful of large nodes raises questions about whether the network's topology is converging toward the hub-and-spoke model it was designed to avoid.

Spark takes a fundamentally different approach to this problem. As a statechain-based Layer 2, Spark has no routing at all. Transfers go directly from the sender to Spark operators to the receiver: no pathfinding, no intermediate hops, no channel capacity constraints. There is no fee market to navigate and no liquidity to manage. The tradeoff is a different trust model (1-of-n honest operators during each transfer), but it eliminates an entire category of complexity that Lightning must continuously engineer around.

For developers building payment applications, the choice depends on the use case. Lightning offers a fully decentralized, trustless network with deep ecosystem support and interoperability. Spark offers operational simplicity and predictable transfer mechanics without the routing overhead. The Spark SDK provides a straightforward integration path for applications that want instant Bitcoin and stablecoin transfers without implementing pathfinding logic. For a deeper comparison of Bitcoin scaling approaches, see our Bitcoin Layer 2 comparison.

This article is for educational purposes only. It does not constitute financial or investment advice. Bitcoin and Layer 2 protocols involve technical and financial risk. Always do your own research and understand the tradeoffs before using any protocol.