AMP (Atomic Multi-Path Payment)

What Is AMP?

AMP (Atomic Multi-Path Payment) is a Lightning Network protocol that allows a sender to split a single payment into multiple parts routed across different channels, where each part carries a unique payment hash derived from a shared secret. Unlike standard base MPP, which reuses a single payment hash from the recipient's invoice, AMP uses sender-generated cryptographic material that makes each shard independently unlinkable while enforcing atomic settlement.

AMP was proposed in February 2018 by Conner Fromknecht and Olaoluwa Osuntokun of Lightning Labs. It is sometimes called "Original AMP" or "OG AMP" to distinguish it from the simpler base MPP that was standardized first in the BOLT specification. The formal specification was proposed as BOLT #21 (feature bits 30/31, option_amp) but remains unmerged into the official BOLT standard as of 2026. LND has supported AMP as a first-class feature since v0.13.0-beta in 2021.

The core innovation is that AMP requires no prior communication with the recipient. A sender can push funds to any node that advertises AMP support, making it a protocol for spontaneous payments similar to keysend but with multi-path capability and cryptographic atomicity.

How It Works

AMP uses an additive secret sharing scheme (XOR-based) combined with hash derivation to ensure that the recipient can only settle the payment once all shards have arrived. The process involves five steps.

Root Seed Generation

The sender generates a 32-byte root seed S uniformly at random. This seed is the master secret from which all child preimages will be derived. The sender never transmits S directly: it is reconstructed by the recipient from shares.

Additive Secret Sharing

The sender splits S into n shares using XOR, where n is the number of payment shards:

s_1 XOR s_2 XOR ... XOR s_n = S

// The sender picks (n-1) random 32-byte values
// and computes the final share as:
s_n = s_1 XOR s_2 XOR ... XOR s_{n-1} XOR S

Each share is 32 bytes. No individual share (or any subset smaller than all n) reveals any information about S. The recipient must collect every share to reconstruct the root seed.

Child Preimage Derivation

For each shard i, the sender derives a unique child preimage:

r_i = SHA256(S || s_i || child_index_i)

// S: the root seed (commits the recipient to the full secret)
// s_i: the share for this shard (makes each preimage unique)
// child_index_i: a 4-byte index (allows re-randomization on retry)

The corresponding payment hash for each shard is:

h_i = SHA256(r_i)

Each shard carries a unique payment hash, which means intermediary routing nodes cannot correlate shards as belonging to the same payment. This is a significant privacy improvement over base MPP, where all shards share a single hash. For a deeper analysis of routing privacy, see the Lightning Network privacy analysis.

Onion Payload Delivery

Each shard is routed through the network using standard onion routing. The final-hop onion payload for each shard includes an amp_record TLV (type-length-value) containing three fields:

• root_share (32 bytes): the share s_i for this shard
• set_id (32 bytes): a unique identifier grouping all shards of the same payment
• child_index (4 bytes): the index used in preimage derivation

Intermediary nodes see only standard HTLCs with unique hashes. Only the recipient receives the AMP-specific data in the encrypted onion payload.

Recipient Reconstruction and Settlement

As shards arrive, the recipient accumulates shares. Once all n shards with the same set_id have been received, the recipient:

1. Reconstructs the root seed: S = s_1 XOR s_2 XOR ... XOR s_n
2. Derives each child preimage: r_i = SHA256(S || s_i || child_index_i)
3. Verifies each derived hash matches the corresponding HTLC's payment hash
4. Settles all HTLCs atomically by revealing the preimages

If any shard is missing, the recipient cannot reconstruct S and therefore cannot derive any valid preimage. This provides cryptographic atomicity: all-or-nothing settlement is enforced by the math, not by economic incentive.

AMP vs Base MPP

Both AMP and base MPP split payments across multiple routes, but they differ in fundamental ways:

Base MPP atomicity relies on the recipient waiting until all shards arrive before claiming any of them. The recipient is economically incentivized to wait (they want the full amount) but is not cryptographically prevented from claiming partial payment. AMP eliminates this trust assumption entirely. For a comprehensive look at how routing works across both protocols, see the Lightning Network routing deep dive.

AMP vs Keysend

Both AMP and keysend enable spontaneous payments (no invoice required), but they solve different problems:

Keysend is simpler and more widely supported across implementations. Core Lightning uses keysend as its primary spontaneous payment mechanism. AMP is more powerful (multi-path, cryptographic atomicity) but is primarily an LND feature due to its unmerged specification status.

Implementation

LND

LND implements both sending and receiving AMP payments. To accept spontaneous AMP payments, the node must be configured with accept-amp=true:

# Send a spontaneous AMP payment (no invoice needed)
lncli sendpayment --dest=<recipient_pubkey> --amt=50000 --amp

# Send to an AMP invoice (reusable)
lncli sendpayment --pay_req=<amp_invoice>

# Create a reusable AMP invoice
lncli addinvoice --amt=0 --amp

AMP invoices in LND are reusable: the same invoice can be paid multiple times, with each payment using a fresh set of shares and preimages. This is useful for donation pages, tipping, and recurring payments.

Retry and Share Splitting

When a shard fails mid-route, the sender does not need to restart the entire payment. The failed share can be split into two new sub-shares using XOR:

// If share s_i fails, split it:
l XOR r = s_i

// Re-route as two new shards with shares l and r
// The XOR constraint is preserved:
// s_1 XOR ... XOR l XOR r XOR ... XOR s_n = S

This recursive splitting allows adaptive re-routing without invalidating the root seed or requiring a fresh payment attempt. The child index field ensures each retry produces a unique preimage.

Use Cases

Spontaneous Multi-Path Payments

The most direct use case: sending a large payment to a node without first requesting an invoice. A wallet can push funds across multiple channels to any AMP-enabled node, overcoming single-channel capacity limits. This is particularly useful for donations, tips, and automated disbursements where the recipient cannot or does not generate invoices in advance.

Reusable Payment Codes

AMP invoices can be paid multiple times because each payment uses fresh cryptographic material. A merchant or content creator can publish a single AMP invoice (or just their node public key) and receive unlimited payments. This contrasts with standard Lightning invoices, which are single-use.

Streaming and Recurring Payments

Applications that stream sats (podcasting, pay-per-minute services) can use AMP to send periodic payments without round-trip invoice generation. The sender pushes funds on a schedule, and each push uses the full multi-path routing graph for reliability.

Privacy-Sensitive Transfers

Because each shard carries a unique payment hash, intermediary nodes cannot determine that two shards belong to the same payment. This decorrelation improves sender privacy compared to base MPP, where a routing node that sees two shards with the same hash knows they are part of one payment.

Why It Matters

Multi-path payments are essential for Lightning Network scalability. As the network grows, no single channel reliably has enough capacity to route large payments. Splitting payments across multiple routes increases success rates and makes larger payments practical. For more context on liquidity dynamics, see the Lightning Network liquidity guide.

AMP advances this by removing the invoice requirement and adding cryptographic atomicity. It represents a step toward a more flexible Lightning payment layer where senders can push funds without prior coordination with recipients. Layer 2 protocols like Spark build on similar principles of enabling efficient off-chain transfers, and understanding AMP's cryptographic design illustrates the broader evolution of Bitcoin payment protocols.

The future of AMP may involve PTLCs (Point Time-Locked Contracts), which use Schnorr signatures and elliptic curve point addition to achieve both multi-path atomicity and proof of payment. This theoretical extension, sometimes called "High AMP," would resolve AMP's primary tradeoff. For more on this direction, see the PTLCs research article.

Risks and Considerations

No Proof of Payment

The most significant tradeoff. In a standard Lightning payment, the sender learns the recipient's preimage only after the payment succeeds. This preimage serves as cryptographic evidence that the recipient was paid. With AMP, the sender generates all preimages, so possessing them proves nothing. This makes AMP unsuitable for scenarios requiring payment receipts, dispute resolution, or audit trails.

Limited Cross-Implementation Support

AMP remains primarily an LND feature. The BOLT #21 specification (PR #658) has been open since 2019 without being merged. Core Lightning, Eclair, and LDK primarily support keysend for spontaneous payments and base MPP for multi-path. This fragmentation means AMP payments only work reliably between LND nodes.

Liquidity Lock During Assembly

While the recipient waits for all shards to arrive, each received shard locks inbound liquidity along its entire route. If some shards arrive quickly and others are delayed or fail, routing nodes along the successful paths have capital locked unproductively. The specification recommends a 60-second timeout for shard assembly.

Complexity

AMP's cryptographic machinery (XOR secret sharing, child preimage derivation, recursive share splitting) adds implementation complexity compared to keysend or base MPP. This complexity has likely contributed to its slower adoption across Lightning implementations and the extended timeline for specification standardization.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.