Multi-Path Payments (MPP)

Multi-Path Payments (MPP) let a single Lightning payment be split into several smaller pieces, or "shards," that travel over different routes and are reassembled at the destination. MPP solves a stubborn liquidity problem: a sender may hold enough total bitcoin across their channels to cover a payment, yet no individual channel has enough outbound capacity on its own. By dividing the amount, the sender can draw on the combined capacity of many channels at once — turning a wallet full of medium-sized channels into one large effective balance.

How splitting works

The sending node breaks the target amount into multiple HTLCs (Hashed Time-Locked Contracts), each carrying the same payment hash, and dispatches them along independent routes through the Lightning Network. The recipient holds the incoming HTLCs without settling until shards summing to the full invoice amount have arrived, then releases the preimage once — which, because every shard locks to the same hash, claims all of them together. If enough shards never arrive, the recipient simply never reveals the preimage, the pending HTLCs time out, and every locked satoshi returns to the sender: the payment as a whole either completes or fails cleanly. Base MPP, introduced in LND v0.10 and implemented across the major node software, is the form of multi-part payment included in the official Lightning specification (the BOLTs).

MPP versus AMP

A related variant, Atomic Multi-Path Payments (AMP), uses a different cryptographic construction in which each shard carries a distinct hash derived from shared secret material, so the pieces cannot be trivially correlated by observers along the route, and settlement is guaranteed all-or-nothing by construction rather than by the recipient's patience. Plain MPP's reuse of one hash across shards is simpler and spec-standard, but it means an intermediary seeing two shards with the same hash knows they belong to the same payment. Both approaches raise the effective payment ceiling of the network and materially improve reliability for larger transfers — big payments stop failing just because no single path could carry them.

What it changes in practice

MPP quietly rehabilitated Lightning for real commerce. Success rates for payments in the hundreds of dollars improved dramatically once wallets could shard automatically, and modern pathfinding treats splitting as a first-class strategy, probing multiple routes and retrying failed shards along alternatives. There are costs: each shard pays its own routing fees, occupies an HTLC slot in every channel it crosses, and multiplies the pathfinding work, so wallets cap the number of parts. For a node runner, MPP is also a reason channel diversity matters as much as channel size — five well-placed channels can collectively route what no single one could.

The costs are bounded but real. Every shard pays its own base and proportional routing fees, so splitting a payment into many small parts can cost more in fees than one large part would — wallets weigh this in their splitting decisions. Each in-flight shard also occupies an HTLC slot in every channel it crosses, and channels support only a protocol-limited number of concurrent HTLCs (a few hundred per direction), so pathological over-splitting wastes shared network resources; implementations impose sane caps on parts per payment. And because shards share the payment's timeout budget, a few slow routes can hold funds locked briefly even when the payment ultimately fails. None of this changes the verdict — MPP made large Lightning payments dependable — it just explains why wallets split as little as necessary rather than as much as possible.

Liquidity is still the law

Splitting does not create capacity; it only aggregates what exists. A recipient still needs sufficient total inbound liquidity across their channels, senders still need outbound, and tools like a submarine swap or services from a Lightning Service Provider remain the levers for rebalancing. MPP pairs naturally with larger channels such as a Wumbo Channel: one raises the ceiling of a single pipe, the other lets many pipes act as one.