Lightning Multi-Path Payments: How Splitting Transactions Improves Reliability at Scale

The Lightning Network handles small payments well. A 1,000 sat transfer typically succeeds on the first attempt, settling in under a second. But as payment amounts grow, reliability degrades sharply. A 5,000,000 sat payment routed through a single path faces a high probability of failure because individual channels rarely have enough liquidity on the right side to forward large amounts. Lightning multi-path payments (MPP) solve this by splitting a single large payment into smaller pieces that travel independently across different routes, then recombine atomically at the recipient.

MPP became part of the BOLT specification as feature bits 16/17, and all major Lightning implementations now support it. Understanding how splitting works, why it matters, and where its limits lie is essential for anyone building on or evaluating Lightning for payments beyond micropayment scale.

Why Single-Path Payments Fail at Scale

Every Lightning payment channel has a total capacity that is publicly visible on the network graph. What is not visible is how that capacity is distributed between the two channel partners. A channel with 10,000,000 sats of total capacity might have 9,000,000 on one side and 1,000,000 on the other, or any distribution in between. Senders cannot know this balance split before attempting a payment.

In 2021, researcher René Pickhardt formalized this uncertainty as a probability model. Assuming a uniform distribution of channel balances, the probability that a single channel with capacity c can forward a payment of amount a is:

Pickhardt's forwarding probability: P(success) = (c − a + 1) / (c + 1). For a 1,000,000 sat channel, a 100,000 sat payment has roughly 90% odds per hop. A 500,000 sat payment drops to about 50%. A 900,000 sat payment has only a 10% chance of getting through.

The critical insight is that these probabilities multiply across hops. A three-hop route where each channel has a 90% forwarding probability yields an end-to-end success rate of just 72.9% (0.9 × 0.9 × 0.9). For larger amounts that push per-hop probability down to 50%, a three-hop path succeeds only 12.5% of the time. This exponential decay is the fundamental reason large Lightning payments fail so frequently.

Channel Capacity Distribution on the Network

The problem compounds because Lightning's channel capacity follows a power-law distribution. Most channels are relatively small (under 5,000,000 sats), while a minority of large hub channels carry disproportionate traffic. When routing a payment of 2,000,000 sats, many potential paths are immediately eliminated because intermediate channels lack sufficient capacity, let alone the right balance distribution. The sender's pathfinding algorithm must find not just any path, but one where every hop has enough liquidity on the correct side.

How Multi-Path Payments Work

MPP addresses the capacity bottleneck by decomposing a payment into multiple smaller HTLCs (hash time-locked contracts) that travel through the network independently. Instead of requiring a single path with enough liquidity for the full amount, the sender distributes the payment across several routes where each individual piece is small enough to succeed reliably.

The Splitting Process

When a sender initiates an MPP, the process unfolds in distinct phases:

1. The sender's node examines the payment amount and network graph to determine how to split the total into parts. Each part gets its own route through the network.
2. All parts share the same payment_hash (derived from the recipient's invoice) and a payment_secret that proves they belong to the same logical payment.
3. Each part is dispatched as a separate HTLC through its designated route. These HTLCs travel independently and may arrive at the recipient at different times.
4. The recipient's node holds each incoming partial HTLC without settling it, accumulating parts until the total received matches the invoice's total_msat value.
5. Once all parts arrive, the recipient reveals the payment preimage to settle all HTLCs simultaneously. If a timeout expires before all parts arrive, the recipient fails all partial HTLCs and the entire payment reverts.

This design maintains atomicity: either the full payment amount is delivered and settled, or nothing is. The recipient never ends up with a partial payment. From the recipient's perspective, an MPP looks identical to a single-path payment once settled.

Why Splitting Improves Reliability

Consider sending 2,000,000 sats through a network where the median channel capacity is around 2,000,000 sats. A single-path payment must find a route where every channel can forward the full amount, giving each hop roughly a 50% success probability under Pickhardt's model. Over three hops, that's about 12.5%.

Splitting the same payment into four parts of 500,000 sats each changes the math dramatically. Each part now needs only 500,000 sats of forwarding capacity per hop, raising the per-hop probability to roughly 75%. A three-hop route for each part succeeds about 42% of the time. With four independent paths and retry logic, the overall payment success rate climbs well above 90%. The sender trades one low-probability attempt for multiple high-probability attempts.

Payment Success Rates: Single-Path vs Multi-Path

Empirical data and simulations confirm the theoretical advantage. River Financial reported payment success rates ranging from 96.5% to 99.6% across their Lightning infrastructure, but these figures reflect an operation with direct channels to major counterparties. For payments routed across the general network, the picture is less favorable, particularly as amounts increase.

These estimates are based on Pickhardt's uniform balance model applied to typical network topology. Actual success rates vary based on the sender's channel connectivity, the specific routes available, and how recently channel balances were probed. Nodes with direct channels to major routing hubs see significantly better results. The key takeaway is that MPP provides a meaningful improvement at every payment size, but even with splitting, payments above a few million sats remain unreliable on the general Lightning Network.

Basic MPP vs Atomic Multi-Path Payments (AMP)

Two distinct multi-path protocols exist in Lightning, each with different trust assumptions and use cases: basic MPP (also called simplified multi-path payments) and Atomic Multi-Path Payments (AMP). Despite similar names, they differ significantly in how they achieve atomicity.

Basic MPP (Simplified Multi-Path Payments)

Basic MPP is the more widely deployed variant. It requires a standard BOLT 11 invoice from the recipient. All payment parts share the same payment_hash derived from the invoice, and the recipient settles them by revealing a single payment preimage. The payment_secret field (introduced in the invoice) prevents intermediate nodes from probing whether partial payments have arrived.

The atomicity guarantee in basic MPP is enforced by the recipient: the receiving node holds partial HTLCs and only settles once the full amount arrives. This means the recipient could theoretically settle with fewer parts than intended if the total_msat threshold is met, though compliant implementations enforce exact matching.

AMP (Atomic Multi-Path Payments)

AMP, proposed by Conner Fromknecht and Olaoluwa Osuntokun of Lightning Labs, takes a different approach. The sender generates a root secret and derives a unique payment hash for each shard. The recipient can only reconstruct the root secret (and thus the preimages needed to settle) once all shards have arrived. This provides cryptographic atomicity rather than relying on recipient behavior.

AMP also enables spontaneous payments (keysend-style) without requiring an invoice. The sender only needs the recipient's public key. This makes AMP suitable for donations, tips, and push payments where generating an invoice is impractical.

Correlation risk: Because basic MPP uses the same payment_hash across all shards, a routing node that appears on multiple paths can link the parts together. AMP eliminates this by using unique hashes per shard, improving payment privacy. However, basic MPP remains the de facto standard due to broader implementation support and compatibility with existing invoices.

Fee Implications of Splitting Payments

Splitting a payment across multiple routes introduces additional routing fee overhead. Lightning routing fees have two components: a base fee (a fixed cost per forwarded HTLC, regardless of amount) and a proportional fee rate (typically expressed in parts per million of the forwarded amount).

Base Fee Overhead

The proportional fee component scales linearly with the total amount regardless of how many splits are used, so it adds no MPP-specific overhead. The base fee, however, is charged per HTLC per hop. Splitting a payment into four parts across three-hop routes means paying 12 base fees instead of 3. Historically, LND defaulted to a 1,000 millisatoshi base fee, which made excessive splitting expensive. The ecosystem has since shifted: LND now defaults to 1 msat, and Core Lightning defaults to zero.

Practical Fee Impact

With the median Lightning routing fee rate at approximately 6.3 ppm (0.00063%) as of 2025, the proportional component dominates for meaningful payment amounts. For a 2,000,000 sat payment split into four parts, the additional base fee overhead is typically under 100 sats total, while the proportional fees remain constant at roughly 1,260 sats regardless of splitting strategy. The reliability improvement from MPP far outweighs the marginal fee increase in most scenarios.

The more significant cost of splitting is operational: each shard consumes HTLC slots in channels along its route, and channels have a finite number of concurrent HTLC slots (typically 483 per direction). Aggressive splitting by many senders simultaneously can contribute to channel jamming concerns.

Implementation Status Across Lightning Nodes

All four major Lightning implementations support multi-path payments, though they take notably different approaches to the splitting and pathfinding algorithms that determine how payments are divided.

LND (Lightning Labs)

LND shipped basic MPP sending in v0.10-beta (April 2020) and added AMP support in v0.13-beta (June 2021). LND's splitting strategy first attempts a single path. If that fails, it applies a "presplit modifier" that divides the payment into approximately 10,000 sat chunks, each small enough to succeed roughly 80% of the time on typical network paths. LND allows up to 16 concurrent splits per payment.

Core Lightning (CLN)

CLN added MPP sending support in 2020. Its approach is distinctive: CLN uses a minimum-cost flow (MCF) solver based on the Pickhardt-Richter research to compute optimal multi-path splits upfront rather than using trial-and-error. This algorithm jointly optimizes for reliability and fee cost, treating the problem as a network flow computation. CLN's approach tends to produce fewer, better-targeted splits compared to LND's fixed-size chunking.

Eclair (ACINQ)

Eclair added MPP support in its v0.4.x releases in 2020. Eclair uses Yen's K-shortest paths algorithm to find multiple candidate routes, then distributes the payment amount across these routes. ACINQ's Phoenix wallet, built on Eclair, makes extensive use of MPP to improve the mobile payment experience.

LDK (Lightning Dev Kit)

LDK supports simplified multi-path payments with its ProbabilisticScorer, which maintains per-channel liquidity histograms to estimate forwarding probabilities. LDK's approach updates these estimates after each payment attempt, learning from both successes and failures to improve future routing decisions. This makes LDK particularly effective for applications that send payments repeatedly to similar destinations.

Limitations of Multi-Path Payments

MPP significantly improves Lightning's payment reliability, but it does not eliminate the fundamental constraints of a channel-based network. Several limitations remain.

Diminishing Returns at Scale

Even with optimal splitting, payments above roughly 5,000,000 sats (~$5,000) remain challenging on the general Lightning Network. The problem shifts from per-path capacity to aggregate network liquidity: the sender may not have enough total outbound capacity across all their channels, or there may not be enough independent routes to the recipient. Splitting into 20 parts does not help if only 3 viable route families exist.

Latency and Complexity

Multi-path payments are inherently slower than single-path payments. The total settlement time is bounded by the slowest shard, and if any shard fails, the sender must retry that portion. Failed shards also tie up liquidity in the successful shards' HTLCs while the recipient waits for the full amount. In the worst case, a partially-delivered MPP can lock up channel liquidity for minutes before the timeout releases it.

Probing and Privacy

As noted earlier, basic MPP uses the same payment_hash across all shards. A routing node that forwards multiple shards of the same payment can trivially link them. Even with AMP's unique hashes, timing correlation and amount analysis can reveal that separate HTLCs belong to the same logical payment. Techniques like onion routing and blinded paths help, but MPP inherently increases the network's observability surface.

Channel Jamming Amplification

Each shard of an MPP occupies an HTLC slot in every channel along its route. A payment split into 8 parts across 3-hop routes consumes 24 HTLC slots across the network, compared to 3 for a single-path payment. This amplification makes MPP a vector for channel jamming attacks, where an adversary intentionally sends payments that never settle to exhaust HTLC slots and block legitimate traffic.

The Bigger Picture: Channels as a Scaling Bottleneck

Multi-path payments are fundamentally a workaround for the channel capacity constraint that defines Lightning's architecture. Channels require locked capital, balance management, and online coordination between partners. MPP makes the best of this model by distributing payments across multiple channels, but it cannot overcome the underlying limitation: every sat sent through Lightning must traverse channels with finite, unknown balances.

This is why alternative Layer 2 designs have emerged that avoid channels entirely. Spark, for example, uses a statechain-based architecture where transfers happen by reassigning ownership of existing UTXOs rather than routing through a network of channels. There is no channel capacity to worry about, no balance uncertainty to model, and no splitting required. A 10,000,000 sat transfer on Spark settles with the same reliability and speed as a 1,000 sat transfer, because the mechanism does not depend on finding a viable path through intermediary nodes.

Different tradeoffs: Spark trades Lightning's fully trustless channel model for a 1-of-n operator trust assumption, where at least one honest operator ensures fund safety. The benefit is that payment reliability becomes independent of amount size, channel liquidity, and routing complexity. For applications that need to move larger values reliably, this tradeoff can be worth evaluating.

What Comes Next for Multi-Path Payments

Research and development on MPP continue along several fronts. The Pickhardt-Richter min-cost flow approach, already adopted by CLN, is being explored by other implementations. Improvements to BOLT 12 offers will enable more seamless recurring multi-path payments. Work on PTLCs (point time-locked contracts) promises to replace HTLCs with a construction that eliminates payment_hash correlation across shards entirely, effectively giving every multi-path payment AMP-level privacy without AMP's implementation complexity.

Meanwhile, the shift toward lower or zero base fees across the network reduces the cost overhead of splitting. Inbound fee discounts (negative fees), now supported in CLN and LND, further improve MPP economics by letting routing nodes signal that they want traffic in a particular direction. These improvements collectively push Lightning toward better large-payment support, though the channel capacity constraint remains structural.

For developers building payment infrastructure, the choice between relying on MPP-enhanced Lightning and alternatives like Spark depends on the payment sizes involved. MPP works well for amounts under a few hundred dollars on well-connected nodes. For larger amounts or applications that need consistent reliability regardless of size, exploring Spark's SDK offers a path that sidesteps routing complexity entirely. Wallets like General Bread already demonstrate how Spark-powered payments deliver consistent reliability at any amount.

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.