Atomic Multipath Payments (AMP)

What Are Atomic Multipath Payments?

Atomic Multipath Payments (AMP) solve one of the Lightning Network's core scaling challenges: sending payments larger than any single channel can handle. When you need to send 100,000 sats but your largest channel only has 60,000 sats of outbound capacity, AMP lets you split the payment across multiple channels and routes.

The "atomic" part is crucial. AMP guarantees that either all payment parts complete successfully, or none do. The recipient cannot claim partial payment. This is achieved through a cryptographic technique called additive secret sharing, where the secret needed to claim funds is split into pieces that must all be combined.

AMP was proposed by Conner Fromknecht and Olaoluwa Osuntokun (roasbeef) of Lightning Labs in 2018. It represents the "original" approach to multipath payments, designed before the simpler Base AMP (now called MPP) was standardized. While MPP has become more widely deployed due to its simplicity, AMP offers unique properties that make it valuable for specific use cases.

How AMP Works

AMP's core innovation is using additive secret sharing to create atomicity without requiring coordination between payment paths. Here's the process:

1. Sender generates a root secret: The sender creates a random 32-byte value that will serve as the basis for all payment parts.
2. Secret shares are derived: Using the root secret, the sender generates n child secrets (one per payment path). These are constructed so they add together to recreate the original preimage.
3. Payment hashes are computed: Each path gets its own unique payment hash, derived from that path's secret share. This means each HTLC in the payment uses a different hash.
4. HTLCs are sent in parallel: The sender dispatches all payment parts simultaneously across different routes. Each part carries its secret share in the onion payload.
5. Recipient collects shares: As HTLCs arrive, the recipient accumulates the secret shares. They cannot claim any individual HTLC because they do not know that HTLC's preimage yet.
6. Reconstruction and settlement: Once all shares arrive, the recipient combines them to reconstruct the root preimage. With this, they can derive every individual preimage and settle all HTLCs atomically.

The cryptographic construction ensures that knowing n-1 shares reveals nothing about the nth share. The recipient must wait for all parts before they can claim anything.

AMP vs MPP (Base AMP)

The Lightning Network has two multipath payment protocols with confusingly similar names. Understanding the differences is important:

MPP (Multi-Path Payments / Base AMP)

MPP, standardized in BOLT specifications, uses the same payment hash for all parts of a split payment. The recipient generates an invoice with a single payment hash, and the sender can split payment across multiple paths, all using that same hash. Atomicity comes from the recipient waiting until sufficient payment parts arrive before releasing the preimage.

• Requires an invoice from the recipient
• All payment parts share the same payment hash
• Recipient controls atomicity by waiting to reveal the preimage
• Widely supported across Lightning implementations
• Simpler cryptographic construction

AMP (Original/OG AMP)

AMP uses different payment hashes for each path, with atomicity enforced cryptographically through secret sharing. The sender can initiate payment without an invoice since they generate all the cryptographic material.

• Enables spontaneous payments (no invoice required)
• Each payment part has a unique payment hash
• Atomicity is cryptographically enforced
• More complex implementation
• Better privacy since payment parts are unlinkable on-chain

When to Use Each

MPP is the standard choice for invoice-based payments and has broader wallet support. AMP shines when you need spontaneous payments (sending without asking for an invoice first) or want the privacy benefits of unlinkable payment parts.

Technical Deep Dive

Additive Secret Sharing

AMP uses a form of additive secret sharing. The sender generates a root preimage BP (base preimage) and derives child preimages for each payment part using a deterministic process:

// For n payment parts:
child_preimage[i] = SHA256(root_seed || i)

// The final preimage is the XOR of all children:
BP = child_preimage[0] XOR child_preimage[1] XOR ... XOR child_preimage[n-1]

The XOR operation ensures that knowing any subset of child preimages reveals nothing about the base preimage. Only with all pieces can the recipient reconstruct BP.

Hash Derivation

Each payment part uses its own payment hash, derived from that part's child preimage:

payment_hash[i] = SHA256(child_preimage[i])

// Recipient learns child_preimage[i] from the onion payload
// But cannot compute payment_hash[j] for other parts

This construction means each HTLC in the multipath payment is cryptographically independent. Network observers cannot link the payment parts together by examining payment hashes.

Onion Payload Structure

AMP extends the standard HTLC onion payload with additional fields in the TLV (Type-Length-Value) section:

• root_share: The XOR share this part contributes to the base preimage
• set_id: Identifies which payment set this part belongs to
• child_index: The index of this part within the set
• total_parts: How many parts to expect before settling

Benefits of AMP

Spontaneous Payments

AMP enables keysend-style spontaneous payments with multipath splitting. You can send to any node without requesting an invoice first, and still split the payment across multiple channels. This is useful for tips, donations, and programmatic payments.

Enhanced Privacy

Because each payment part uses a different hash, observers cannot trivially link the parts together. In MPP, all parts share the same hash, making correlation straightforward for routing nodes. AMP's unlinkable parts provide stronger payment privacy.

Larger Payment Capacity

By aggregating liquidity across multiple channels and routes, AMP allows payments that would be impossible through any single path. A user with ten 100,000 sat channels can send a 500,000 sat payment by utilizing five of them simultaneously.

Cryptographic Atomicity

Unlike MPP where atomicity depends on recipient behavior, AMP's atomicity is mathematically guaranteed. The recipient literally cannot claim partial payment since they need all shares to derive any preimage.

Use Cases

High-Value Transfers

Businesses and exchanges moving significant value benefit from AMP's ability to route around single-channel capacity limits. Instead of failing when one channel lacks liquidity, the payment finds multiple paths.

Streaming Payments

Applications like podcast streaming sats can use AMP to send accumulated micropayments in batches, splitting across available channels for reliability.

Privacy-Sensitive Applications

When payment privacy matters, AMP's unlinkable payment parts provide better protection against network analysis than MPP's shared hash approach.

Automated Systems

Systems that need to send payments without user interaction benefit from AMP's spontaneous payment capability. No invoice exchange required means simpler automation.

Limitations

Implementation Complexity

AMP requires more sophisticated cryptographic handling than MPP. Wallet developers must implement secret sharing, coordinate multiple HTLCs, and handle the additional onion payload fields. This complexity has slowed adoption.

Limited Wallet Support

As of 2026, AMP support is primarily found in LND. Other implementations like Core Lightning and Eclair have focused on MPP. This means AMP payments may fail if the recipient's node does not support the protocol.

No Proof of Payment by Default

Standard AMP spontaneous payments do not provide the same proof of payment that invoice-based payments offer. The sender knows they sent funds, but lacks a signed invoice proving the recipient requested a specific amount.

Stuck Payments

If some payment parts succeed in reaching the recipient but others fail, the successful parts remain pending until timeout. The recipient cannot claim partial payment, but the sender's funds are locked until HTLCs expire. Proper timeout handling is essential.

FAQ