Atomic Multipath Payments (AMP)

Atomic Multipath Payments (AMP) extend the idea of splitting a Lightning payment across many routes, but add a cryptographic guarantee that either every shard settles or none does. Where ordinary Multipath Payments reuse one payment hash across all shards, AMP derives a distinct hash for each shard from a shared secret, so the receiver can only reconstruct the final preimage once enough shards have arrived. This closes the partial-settlement gap that plain multipath leaves open.

How atomicity is enforced

The sender splits a base secret into shares, one per shard, and commits to each share inside its own conditional contract. The receiver cannot redeem any single shard in isolation; it must combine the shares to reconstruct the preimage that unlocks the whole payment, which is why the scheme is atomic in the true database sense — all or nothing, with no intermediate state where the recipient has been paid half. Because each shard also carries a different hash, the shards are harder to correlate as they cross the network, giving a modest privacy improvement over reused-hash multipath. The cost is a little extra coordination between sender and receiver, but no new on-chain footprint: like its predecessor, AMP is enforced entirely by the conditional contracts already used for routing, so nothing about it changes how a channel is opened or closed.

Spontaneous and reusable payments

AMP also enables spontaneous payments without a pre-issued invoice, and it supports paying the same static identifier more than once — something classic single-use invoices forbid, since each BOLT11 invoice is meant to be paid exactly once. That makes AMP useful for donations, recurring transfers, and pooled payouts where the sender should not have to request a fresh invoice for every payment. It occupies similar territory to reusable static payment codes such as BOLT12 offers, though the two solve the reusability problem through different mechanisms and can complement one another rather than compete.

When atomicity is worth the cost

Atomicity is not always necessary — for a small tip, plain multipath is fine, and most everyday wallet payments never need the stronger guarantee. It earns its keep in higher-value and automated flows, where a payment stuck half-complete would be a genuine accounting problem rather than a minor annoyance. A self-hosted service accepting recurring support, or an operator sweeping many small channel balances into a single outgoing payment, wants certainty that the transfer is all-or-nothing before it reconciles its books. In those cases the modest extra coordination buys real peace of mind, and the fact that it costs nothing on-chain makes it an easy default for software that handles money without a human watching each transfer. The same property makes AMP a comfortable building block for pooled or streaming payouts, where a program fans a single logical payment out to many recipients or across many balances and needs each unit to either complete cleanly or roll back, rather than leaving a half-settled mess to reconcile by hand later.

Why sovereign operators care

For a node runner, AMP delivers the resilience of multipath routing with stronger settlement safety: you get the reach of many small paths without ever risking a state where a payment is stranded midway. It builds on the conditional-payment logic in our HTLC entry and, by making reusable and spontaneous payments practical, pushes Lightning a step closer to behaving like programmable, peer-to-peer cash that answers to no central clearinghouse. That combination — robustness plus reusability, with no custodian in the loop — is exactly what a sovereign operator wants from money they route on their own terms. It is a reminder that Lightning's safety properties are not bolted on afterward but engineered into the settlement primitive itself, which is precisely why they survive even when a single payment is scattered across a dozen independent routes.