Multipath Payments (MPP)

Multipath Payments (MPP) let a Lightning node split a single payment into several smaller shards and route each one over a different path before they are recombined by the recipient. The technique exists because no single channel may hold enough outbound liquidity to carry a large payment on its own, while the network as a whole usually does. By using many thin paths instead of one fat path, MPP raises the effective payment size a node can send and makes routing markedly more reliable.

Why splitting helps

Each shard travels as its own onion-routed hop sequence, and every shard shares the same payment hash as the others. The receiver waits until shards summing to the full invoice amount arrive, then releases the preimage to claim all of them at once. Because the shards reuse one hash, an observer can in principle correlate them, and a receiver could in theory reveal the preimage before the full sum lands. That is the key distinction from Atomic Multipath Payments, which give each shard a unique hash and a cryptographic all-or-nothing guarantee. A sender's node decides how to split — often starting with a single-path attempt and shattering it into smaller pieces only when that fails — and it can retry individual shards along fresh routes without restarting the whole payment. Each failed shard returns an error that hints at where liquidity ran out, so the sender's pathfinding gets smarter with every attempt within the same payment.

Practical impact for node runners

MPP improves the success rate of larger transfers and helps drain or rebalance liquidity across several channels in one payment. Most wallets and routing nodes enable it by default, splitting opportunistically the moment a single path proves too small. Sovereign Bitcoiners running their own node benefit directly, because MPP reduces dependence on any one well-funded channel and lets a modest set of channels carry meaningful payment volume. For a miner taking pool payouts or settling supplier invoices over Lightning, that is the difference between a five-figure-sat transfer failing outright and it quietly succeeding across four or five routes.

The limits worth knowing

Splitting is not free of trade-offs. More shards mean more hops to lock and unlock, so a heavily fragmented payment can be slightly slower and ties up liquidity across more channels while it is in flight. Very small shards can also run into per-channel minimums or dust limits, which is why implementations cap how finely they will split. And because shard sizes and timing can leak information, aggressive splitting is a mild privacy trade against reliability. In practice the defaults are tuned to send as few shards as will get the job done, escalating only when the network forces it — a pragmatic balance rather than a maximalist one. There is also a coordination cost on the receiving side, which must track partial arrivals and hold them until the total lands or a timeout forces the pieces to be released, so a receiver that drops offline mid-payment can stall an otherwise healthy transfer. None of this outweighs the reliability gain for large payments, but it explains why single-path routing is still preferred whenever one clean path exists.

Where the primitive comes from

MPP builds directly on the conditional-payment primitive described in our HTLC entry: every shard is just another hashed time-locked contract that clears or expires on its own. What MPP adds is the coordination layer that lets many such contracts, spread across independent paths, settle together as one logical payment. The result is that Lightning behaves less like a collection of isolated pipes and more like a single fungible pool of capacity — the property that makes it usable for real commerce rather than only tiny tips, without surrendering the peer-to-peer, non-custodial character that sovereign users insist on.