Asynchronous Payment Channel

What Is an Asynchronous Payment Channel?

An asynchronous payment channel is a payment channel design that allows one party to send funds even when the other party is offline. In traditional payment channels, both participants must be online to exchange signed state updates. An asynchronous payment channel relaxes this constraint, enabling payments that behave more like email: the sender dispatches a payment, and the recipient claims it whenever they next come online.

This concept addresses one of the most significant usability gaps in the Lightning Network. Mobile wallets, IoT devices, and users in regions with intermittent connectivity cannot maintain persistent online connections. Without asynchronous capability, a sender who tries to pay an offline recipient simply gets an error: the payment fails, and the funds never leave the sender's wallet. Asynchronous payment channels aim to make this scenario work seamlessly.

How It Works

The Online Requirement Problem

To understand why asynchronous channels matter, consider how a standard Lightning payment settles. The receiver generates a random secret (the preimage) and publishes a hash of it in a Lightning invoice. The sender locks funds in an HTLC conditional on that hash, routing it hop by hop through the network. When the HTLC reaches the receiver, the receiver must:

1. Accept the incoming HTLC update on their channel
2. Co-sign a new commitment transaction reflecting the updated balance
3. Reveal the preimage to claim the funds

All three steps require the receiver to be online and responsive. If the receiver is offline, the HTLC cannot settle. Liquidity remains locked at every hop along the route until the timelock expires and the payment fails back to the sender. This creates a poor user experience and wastes network resources.

Store-and-Forward via Trampoline Nodes

The first practical approach to asynchronous Lightning payments uses trampoline routing as a store-and-forward mechanism. Instead of routing the HTLC all the way to the offline receiver, the sender routes it to the receiver's Lightning Service Provider (LSP), which acts as a trampoline node:

1. The sender routes the payment to the recipient's LSP (the trampoline node)
2. The LSP holds the HTLC rather than forwarding it, since the recipient is offline
3. When the recipient's wallet reconnects, the LSP forwards the held HTLC to the recipient
4. The recipient reveals the preimage, and the payment settles normally back through the route

This approach, implemented by ACINQ in the Eclair Lightning node and used by the Phoenix wallet, avoids locking liquidity across the entire multi-hop route. Only the LSP's liquidity is locked during the hold period. However, the recipient must come back online before the HTLC timelock expires, or the payment fails.

BOLT12 Static Invoices

A second challenge with offline recipients is invoice generation. Standard BOLT11 invoices require the receiver to create a fresh invoice (with a unique payment hash) for each payment. This means the receiver must be online just to tell the sender where to pay.

BOLT12 offers solve this by introducing static invoices: a pre-generated invoice the receiver creates once and gives to their LSP for storage. The flow works as follows:

1. The recipient creates a BOLT12 offer with blinded paths pointing to their LSP
2. The recipient pre-generates a static invoice and gives it to the LSP
3. A sender fetches the offer (potentially via a DNS lookup per BIP-353), requests an invoice, and the LSP returns the stored static invoice
4. The sender pays the static invoice, and the LSP holds the HTLC until the recipient reconnects

The specification for this approach is defined in lightning/bolts PR #1149, authored by Valentine Wallace of the LDK team at Spiral. As of mid-2026, client and server-side async payment logic has been merged into LDK, while the specification itself remains under review.

Code Example: Trampoline Async Payment TLV

In the trampoline approach, a new TLV (type-length-value) field signals that a payment should be held for an offline recipient:

// Trampoline onion payload with async flag
{
  "amt_to_forward": 100000,
  "outgoing_cltv_value": 800000,
  "async_payment": {
    // Signals the trampoline node to hold the HTLC
    // rather than immediately forwarding
    "hold_until_online": true
  }
}

// The trampoline node stores the held HTLC
// and triggers delivery when the recipient reconnects

Spark's Approach: Async by Design

While Lightning retrofits asynchronous capability onto a synchronous channel model, Spark takes a fundamentally different approach. Built on statechains rather than payment channels, Spark supports asynchronous transfers as a native property of its architecture.

In Spark, a Bitcoin UTXO is locked under a 2-of-2 multisig between the user and the Spark Operators (a federation using FROST threshold signatures). Transfers happen through key rotation: when Alice sends to Bob, the Spark Operators generate a new key share for Bob and adjust their own share so the combined public key remains unchanged on-chain. No HTLC settlement, no preimage exchange, and no interactive channel state update is required.

This means the recipient never needs to be online at the moment of transfer. A Spark Service Provider (SSP) can receive the new key share on behalf of an offline user. When the recipient next opens their wallet, they verify their ownership and can spend their virtual UTXOs (vTXOs) freely.

Lightning vs. Spark Async Comparison

For a deeper comparison of these scaling approaches, see the statechains scaling deep dive and the Lightning async and offline payments research articles.

Use Cases

Asynchronous payment channels unlock scenarios that synchronous channels cannot serve reliably:

• Mobile wallets: smartphone users frequently close apps or lose connectivity, making them unreachable for standard Lightning payments. Async channels let them receive payments while their phone is in a pocket or airplane mode.
• IoT and machine-to-machine payments: connected devices may have intermittent network access. An async channel allows a sensor or meter to accumulate payments that settle whenever it next connects.
• Cross-timezone commerce: a merchant in Tokyo can receive a payment from a customer in New York without both parties needing to coordinate timing. The payment waits for the recipient rather than failing.
• Emerging markets: users in regions with unreliable internet infrastructure benefit from payment systems that tolerate connectivity gaps rather than requiring persistent connections.
• Tips and donations: content creators can publish a static payment address (via BOLT12 offers or a Lightning address) and receive tips even while offline, without needing to generate per-payment invoices.

Risks and Considerations

Timelock Expiry in Lightning

For Lightning-based async approaches, the held HTLC has a finite timelock. If the recipient does not come back online before the timelock expires, the payment fails and funds return to the sender. This creates a race condition: the hold period must be long enough for the recipient to reconnect, but shorter timelocks are better for network health because they reduce liquidity lock duration.

LSP Trust and Censorship

Both Lightning and Spark async models introduce a service provider in the payment path. In Lightning, the LSP can delay delivery or refuse to forward the held HTLC when the recipient reconnects, effectively censoring payments (though it cannot steal funds). In Spark, the Spark Operators collectively manage key shares. The security model relies on at least one operator out of the federation behaving honestly.

Channel Jamming Amplification

Holding HTLCs for extended periods exacerbates channel jamming risks. A malicious sender could create many async payments to offline recipients, locking up LSP liquidity indefinitely. Mitigations under development include HTLC endorsement proposals and reputation-based forwarding policies.

Privacy Tradeoffs

Async payment designs often reveal information to the intermediary. The LSP learns that a specific recipient is offline and when they reconnect. In the trampoline model, the LSP sees the payment amount and the recipient's identity. Blinded paths in BOLT12 help mitigate sender privacy concerns, but the recipient's LSP necessarily knows about incoming payments.

Specification Maturity

As of mid-2026, Lightning async payment support remains an active area of development. The primary specification (bolts PR #1149) has not been finalized, and implementation coverage varies across Lightning nodes. LDK has merged both client and server-side async payment logic, and Eclair supports trampoline-based async payments in production via Phoenix wallet. LND does not yet support async payments natively. Users should verify which implementations support async features before relying on them.

For more on how async payments work at the protocol level, and how PTLCs may further improve async constructions in the future, see the PTLCs research article.

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.