Multi-Path Payments (MPP)

What Are Multi-Path Payments?

Multi-path payments (MPP) are a Lightning Network feature that allows a single payment to be split into multiple smaller parts, each routed independently through different channel paths. The receiving node collects all parts and only settles the payment once every part has arrived. Think of it like paying a $100 bill using five $20 bills handed to different couriers: the recipient waits until all five arrive before acknowledging full payment.

Before MPP, every Lightning payment had to traverse a single route from sender to receiver. This meant the entire amount had to fit through every channel along that path. On a network where individual channels might hold anywhere from a few thousand to a few million satoshis, finding a single route with sufficient capacity for larger payments was often impossible. MPP was introduced in BOLT 11 and BOLT 4 amendments to address this fundamental limitation.

The feature is sometimes referred to as MPP in shorthand. It represents one of the most impactful routing improvements to the Lightning Network, directly addressing the tension between channel capacity constraints and real-world payment sizes.

How It Works

A standard (single-path) Lightning payment routes the full amount through one chain of channels using a single HTLC. If any channel along the route lacks sufficient capacity, the payment fails and the sender must find an alternative route or give up. With MPP, the process changes significantly:

1. The sender determines the total payment amount and the payment hash from the invoice
2. The sender's routing algorithm splits the total into multiple partial amounts (for example, a 500,000 sat payment might become three parts: 200,000 + 180,000 + 120,000)
3. Each part is sent as an independent HTLC along a different route through the network
4. The receiver identifies that all parts belong to the same payment using the shared payment hash and the total amount field
5. Once all parts arrive and the total matches the invoice amount, the receiver releases the preimage to settle every part simultaneously
6. The preimage propagates back through each route, settling the HTLCs at every hop

The receiver enforces atomicity: it will not release the preimage until all parts have arrived. If some parts arrive but others fail, the receiver waits. Parts that do not arrive will eventually time out via their HTLC timelocks, and the sender can retry those parts through alternative routes.

Base MPP vs. AMP

There are two distinct multi-path payment protocols, each with different trust and privacy properties:

Base MPP is simpler and widely deployed. Because all parts share the same payment hash, an intermediate node that appears on two different paths could correlate the parts as belonging to one payment. This is a minor privacy concern in practice, but it exists.

AMP solves this by deriving unique preimages for each part from a shared secret, and can even be combined with keysend-style spontaneous payments. The sender splits a root secret into shares using a method where the receiver can only reconstruct the root (and thus derive all preimages) once every share has arrived. This provides cryptographic atomicity rather than relying on receiver cooperation, and eliminates cross-path correlation. However, AMP is more complex and does not produce a single proof-of-payment preimage that the receiver generates, which changes the trust model for some use cases.

Routing Algorithm Changes

MPP fundamentally changes how pathfinding works. Single-path routing searches for one route where every channel has enough capacity. MPP routing must solve a more complex problem: how to optimally split a payment and find routes for each part.

Modern Lightning implementations typically use one of two approaches:

• Sequential splitting: attempt to route the full amount first. If that fails at a specific channel, split the payment at that bottleneck and retry the parts through separate routes
• Proactive splitting: analyze available channel capacities upfront and pre-compute an optimal split before sending any HTLCs. This approach uses techniques like minimum-cost flow algorithms to find the best distribution across paths

The routing algorithm must also decide how many parts to create. Fewer parts means fewer HTLCs and lower routing fees, but each part is larger and harder to route. More parts are easier to route individually but increase total fees and the chance of partial failure. Most implementations target somewhere between 2 and 6 parts depending on the amount and known network topology.

# Simplified MPP flow (pseudocode)
total_amount = 500_000  # sats
invoice_hash = decode_invoice(bolt11).payment_hash

# Attempt full-amount route first
route = find_route(destination, total_amount)
if route:
    send_htlc(route, total_amount, invoice_hash)
else:
    # Split into parts based on available capacity
    splits = compute_splits(destination, total_amount)
    # e.g., splits = [(route_a, 200_000), (route_b, 180_000), (route_c, 120_000)]

    for route, amount in splits:
        send_htlc(route, amount, invoice_hash, total_msat=total_amount)

    # Receiver holds all parts until total_amount is met
    # Then releases preimage for all parts simultaneously

Each HTLC part carries a total_msat field in its onion payload, telling the receiver the full expected payment amount. This prevents the receiver from settling early with only partial funds.

Probing and MPP

Probing becomes more nuanced with MPP. Senders can probe multiple routes simultaneously to discover available capacity before committing to a split strategy. Some implementations use probe results to inform their splitting decisions, pre-testing routes with zero-value or fake HTLCs before sending actual payment parts.

Use Cases

Large Payments

The most direct use case for MPP is enabling payments larger than any single channel on the route can support. Without MPP, a 1,000,000 sat payment requires every channel along the path to have at least 1,000,000 sats of capacity in the right direction. With MPP, the same payment can succeed even if the largest available channel only holds 300,000 sats: the payment simply splits across enough routes to cover the total.

For a deeper exploration of how channel liquidity affects payment success, see our research on Lightning Network liquidity. This is particularly important for Bitcoin Layer 2 solutions and protocols like Spark that aim to support real-world commerce where payment sizes vary widely.

Improved Reliability

Even for payments that could fit in a single route, MPP improves reliability. Channel liquidity is unevenly distributed and constantly shifting. A payment that barely fits through a single route has a high failure probability because any channel along the path might have slightly less capacity than expected. Splitting into smaller parts gives each part more routing options and a higher individual success probability.

Better Fee Optimization

Counter-intuitively, MPP can sometimes reduce total routing fees. If the only single-path route for a large payment goes through expensive high-capacity channels, splitting the payment might allow parts to travel through cheaper, lower-capacity routes that the full amount could never use. The total fee across multiple cheap routes can be less than a single expensive route.

Channel Rebalancing

MPP interacts beneficially with circular rebalancing and Loop operations. When nodes rebalance channels to improve their routing capacity, the payments involved often need to traverse the network in specific directions. MPP makes these rebalancing payments more likely to succeed by allowing them to split across available routes.

Risks and Considerations

Partial Payment Failures

The most complex failure mode in MPP is partial delivery: some parts reach the receiver while others fail en route. When this happens, the receiver holds the arrived parts without settling (waiting for the rest), and the failed parts time out at various points along their routes. The sender must then retry only the missing amount.

This creates a coordination challenge. The sender needs to track which parts succeeded, calculate the remaining amount, find new routes for the remainder, and send additional parts: all while the successfully-delivered parts are tying up liquidity at the receiver and along their routes. If retries also partially fail, the sender may need multiple rounds of splitting and retrying.

Increased HTLC Load

Each part of an MPP is a separate HTLC at every hop along its route. A payment split into 4 parts across 3-hop routes creates 12 HTLCs across the network (compared to 3 for a single-path payment). This increases the load on routing nodes, consumes more of their HTLC slots (channels have a maximum number of concurrent HTLCs, typically 483), and temporarily locks more total liquidity across the network.

Solutions like PTLCs may eventually improve efficiency, and trampoline routing can reduce the pathfinding burden on senders.

Privacy Trade-offs

With Base MPP, all parts share the same payment hash. A routing node that happens to forward two parts of the same payment (on different routes) can link them together, learning that the total payment amount is larger than either individual part. This reveals more about the payment than single-path routing would. AMP addresses this by using unique hashes per part, but at the cost of additional complexity.

Timing and Timeout Coordination

Each part has its own HTLC timelock, and these must be coordinated carefully. If early-arriving parts have short timelocks, they may expire before late-arriving parts reach the receiver. The receiver would then settle only the late parts (if the total still matches), but the early-part senders would have already reclaimed their funds: a dangerous inconsistency. Implementations handle this by ensuring all parts use compatible timelock values and by having the receiver track aggregate timeout deadlines.

Fee Estimation Complexity

Estimating total fees for an MPP is harder than for single-path payments. Each part incurs independent routing fees along its path, and the optimal split depends on the fee structures of available routes. A naive split might end up costing significantly more in total fees than a well-optimized one. This makes fee estimation less predictable for wallets and users, though most modern implementations handle this transparently.

This content is for informational purposes only and does not constitute financial, investment, or legal advice.