Atomic Multi-Path (AMP)

What Is Atomic Multi-Path (AMP)?

Atomic Multi-Path Payments (AMP) is a payment protocol for the Lightning Network that splits a single payment into multiple smaller pieces routed independently across the network, with a cryptographic guarantee that either all pieces settle or none do. Specified in BOLT 21 by Conner Fromknecht and Olaoluwa Osuntokun, AMP solves two problems at once: it lets senders exceed the capacity of any single channel by spreading funds across multiple routes, and it does so without requiring an invoice from the receiver.

The Lightning Network already supports a simpler form of multi-path payments known as base MPP (or Simplified Multipath Payments). In base MPP, all shards share the same payment hash, which means the receiver generates an invoice, and any individual shard can theoretically be settled independently. AMP takes a different approach: each shard uses a unique payment hash, making individual shards uncorrelatable and unsettleable until the full set arrives. This true atomicity is what gives AMP its name.

Because AMP does not require the receiver to create an invoice beforehand, it functions as a sharded version of keysend. The sender only needs the receiver's public key to initiate payment, enabling spontaneous payments that can leverage the full capacity of multiple channels simultaneously.

How It Works

AMP's cryptographic design ensures that the receiver gains the ability to settle each shard only after collecting all of them. The mechanism relies on XOR-based secret sharing and deterministic preimage derivation.

Step-by-Step Process

1. The sender decides to split the payment into N shards and generates a uniformly random 32-byte root seed S
2. The sender creates N additive shares using XOR, such that s_1 XOR s_2 XOR ... XOR s_N = S. The shares are random except for the last one, which is derived to make the XOR equation hold
3. For each shard i, the sender derives a child preimage: r_i = SHA-256(S || s_i || child_index). Since this derivation requires the root seed S, only someone who possesses all shares can compute any preimage
4. The sender computes each payment hash as p_i = SHA-256(r_i) and constructs an HTLC for each shard, each locked to its unique payment hash
5. Each shard's onion-routed payload carries the root share s_i and child index in an amp_record TLV field
6. The receiver collects incoming shards. Once all N shares arrive, the receiver reconstructs the root seed S via XOR, derives each child preimage r_i, and settles all HTLCs

Cryptographic Guarantee

The security of AMP rests on a simple property: without the complete set of XOR shares, the root seed S cannot be reconstructed. Without S, none of the child preimages can be derived. This means a receiver who has received only some shards cannot settle any of them. They must wait for the full set, ensuring atomic all-or-nothing settlement.

This contrasts with base MPP, where all shards share one payment hash and one preimage. In base MPP, a routing node that learns the preimage from one shard could theoretically use it to claim other shards, and the receiver can settle any shard independently once they have the preimage.

The AMP Record

Each AMP shard carries metadata in a TLV (type-length-value) extension within the onion payload. The amp_record contains three fields:

amp_record {
  root_share: [32]byte   // XOR share of the root seed
  set_id:     [32]byte   // Identifies which payment set this shard belongs to
  child_index: uint32    // Index for deterministic preimage derivation
}

The set_id groups shards belonging to the same payment. This lets the receiver distinguish between concurrent AMP payments from different senders. The child_index ensures each shard's preimage is unique even if the same root seed were reused (though in practice each payment uses a fresh seed).

AMP vs. Base MPP

Both AMP and base MPP (also called simplified multipath payments) split a payment across multiple routes. The differences are fundamental:

For a deeper analysis of how multi-path routing works across the Lightning Network, see the Lightning Network routing deep dive.

Implementation

AMP is currently implemented in LND (v0.13.0-beta and later). Since AMP is an end-to-end protocol, only the sender and receiver need to support it. Intermediate routing nodes process each shard as a standard HTLC and do not need AMP awareness.

Sending an AMP Payment

In LND, sending an AMP payment requires only the destination public key and amount:

# Send an AMP payment (no invoice needed)
lncli sendpayment --amp --dest <receiver_pubkey> --amt 500000

# Send AMP with a custom timeout
lncli sendpayment --amp --dest <receiver_pubkey> --amt 500000 \
  --timeout 120s

Receiving AMP Payments

The receiver must opt in to accepting AMP payments by enabling the feature in their LND configuration:

# lnd.conf
[Application Options]
accept-amp=true

Once enabled, the node automatically handles shard collection, root seed reconstruction, and HTLC settlement when a complete AMP payment set arrives.

Use Cases

Large Spontaneous Payments

Standard keysend payments are limited by the capacity of a single channel route. AMP removes this constraint by splitting across multiple paths. This makes it practical to send large spontaneous tips, donations, or peer-to-peer transfers without the receiver needing to generate an invoice first.

Reusable Payment Addresses

Because AMP does not rely on a single-use invoice, it supports static payment identifiers. A merchant or content creator can publish their node public key once, and senders can pay it repeatedly. Each payment uses a fresh root seed, so there is no invoice management overhead.

Privacy-Preserving Payments

Each AMP shard carries a unique payment hash, which means an intermediate routing node processing one shard cannot link it to other shards of the same payment. This improves payment privacy compared to base MPP, where shared hashes let any node along two shard paths correlate them. Combined with onion routing, AMP provides stronger sender and receiver unlinkability.

Streaming and Recurring Payments

Applications like podcast streaming payments (value-for-value) benefit from AMP because they can send frequent small payments without invoice round-trips. The sender fires payments at the receiver's public key whenever a payment is due, using multiple paths to maintain reliability even as individual channels become congested.

Risks and Considerations

Latency and Stuck Payments

AMP's atomicity means all shards must arrive before any can settle. The slowest shard determines the overall payment time. If one shard gets stuck due to an unresponsive intermediate node, all other shards remain locked in their respective HTLCs until the stuck shard either resolves or times out. This "wait for the slowest" property can increase payment latency compared to single-path payments.

The BOLT 21 specification recommends receivers wait at least 60 seconds before timing out an incomplete shard set. In practice, LND uses approximately a two-minute timeout per HTLC set.

Channel Liquidity Lock

While AMP shards are in flight, liquidity is locked along each route. If a shard gets stuck, the locked liquidity along that path (and the corresponding locked liquidity for the other waiting shards) reduces the available capacity for other payments across the network. This is the same channel jamming risk that affects all HTLC-based payments, but AMP's multi-path nature means a single stuck payment can tie up liquidity across more channels simultaneously.

Limited Implementation Support

As of mid-2026, AMP (BOLT 21) is only implemented in LND. Core Lightning, Eclair, and LDK support base MPP and keysend but have not adopted the AMP protocol. This means AMP payments can only be sent to and from LND nodes with accept-amp enabled.

The broader Lightning ecosystem has been moving toward BOLT 12 offers as the standard for invoice-less and reusable payment flows. BOLT 12 is being adopted across CLN, LDK, and Eclair, which may reduce AMP's practical relevance for some use cases over time.

Proof-of-Payment Limitations

In standard Lightning payments, the receiver's preimage serves as a cryptographic receipt proving that payment was delivered. With AMP, the sender generates the root seed and can derive the preimages themselves, which weakens the proof-of-payment guarantee. The receiver did receive funds (they could only settle by reconstructing the seed from all shards), but the sender could have computed the preimages independently.

Retry Complexity

When an AMP shard fails, the sender can re-split and retry with different child indexes. However, any in-flight shards from the original attempt remain locked until they resolve. The sender must carefully track which shards are pending, which have failed, and whether to cancel the entire payment or retry individual paths. This state management is more complex than single-path payment retries.

AMP and the Future of Lightning Payments

AMP represents an important innovation in Lightning payment reliability and privacy. By enabling spontaneous multi-path payments with true atomicity, it addresses real limitations of both basic keysend (single-path capacity constraint) and base MPP (weak atomicity, invoice requirement). For applications building on the Lightning Network, understanding the tradeoffs between AMP, base MPP, and emerging standards like BOLT 12 is essential for choosing the right payment flow.

The evolution toward PTLCs (point time-locked contracts) may eventually supersede HTLC-based multi-path designs entirely, offering even stronger privacy through decorrelation at every hop. For more on this trajectory, see the research on PTLCs as the next evolution of Lightning.

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.