Async Payments

What Are Async Payments?

Async payments (short for asynchronous payments) are a proposed extension to the Lightning Network that allows a recipient to receive payments even when their node is temporarily offline. In standard Lightning, both the sender and receiver must be online at the same moment for a payment to complete. The receiver needs to be present to provide an invoice, accept the incoming HTLC, and release the preimage that settles the payment.

This simultaneous-online requirement works fine for always-on server nodes but creates a serious usability problem for mobile wallets. A phone might be asleep, disconnected, or in airplane mode when someone tries to send it sats. Without async payments, the sender simply gets a routing failure and has to retry later, hoping the recipient happens to be online.

Async payments address this by introducing a holding mechanism: a Lightning Service Provider (LSP) or trampoline node acts as an intermediary, accepting the payment on behalf of the offline recipient and completing the handoff once the recipient reconnects. The key constraint is that this intermediary must never be able to steal the funds.

How It Works

The async payments protocol combines several Lightning primitives to enable offline receiving without sacrificing self-custody. The flow relies on BOLT12 offers, static invoices, and trampoline or onion-message-based coordination between the sender and the recipient's LSP.

Setup Phase

Before going offline, the recipient prepares their LSP to receive payments on their behalf:

1. The recipient creates a BOLT12 offer containing blinded paths that terminate at their LSP's always-online node
2. The recipient generates a static invoice (a BOLT12 invoice without a payment hash) and provides it to the LSP for storage
3. The recipient can now go offline. The offer remains valid as a reusable payment endpoint, similar to a static address

Payment Flow

When a sender wants to pay the offline recipient:

1. The sender fetches the recipient's BOLT12 offer (for example, via a BIP-353 DNS-based address)
2. The sender sends an invoice request via onion message, which reaches the recipient's LSP
3. The LSP returns the static invoice it holds on behalf of the offline recipient
4. The sender prepares the payment but does not immediately forward the HTLC. Instead, it holds the payment until the LSP signals that the recipient is back online
5. When the recipient reconnects, their LSP sends an onion message to the sender (or the sender's trampoline node) indicating the recipient is available
6. The sender (or trampoline) forwards the HTLC. The recipient receives it and releases the preimage, settling the payment normally

The Role of Trampoline Routing

Trampoline routing plays a critical role in making async payments practical. In a trampoline payment, the sender delegates pathfinding to an intermediate node. For async payments, this trampoline node (often the sender's own LSP) can hold the outgoing payment until it receives a signal that the recipient is available.

Without trampoline routing, the sender's node itself would need to remain online and waiting, which defeats the purpose for mobile-to-mobile payments where both parties may be intermittently connected. With trampoline, both the sender and receiver can go offline after initiating and preparing the payment, respectively, while their always-online LSPs coordinate the handoff.

Static Invoices vs. Standard Invoices

A standard BOLT11 invoice contains a unique payment hash for each payment. The receiver generates a random preimage, hashes it, and embeds the hash in the invoice. This requires the receiver to be online at invoice-creation time.

Static invoices used in async payments work differently. Under the BOLT12 specification being developed (lightning/bolts #1149), the static invoice omits the payment hash entirely. Instead, the payment is secured through a combination of the recipient's node key and the offer's blinded paths. The payment hash is only generated when the recipient actually comes online and the HTLC is forwarded, preserving proof-of-payment guarantees.

Why It Matters

The online-receiver requirement is one of the biggest UX barriers to self-custodial Lightning adoption on mobile devices. Users accustomed to traditional payment apps expect to receive money at any time, regardless of whether their phone is actively connected. Async payments close this gap without requiring users to trust a custodian with their funds.

For a deeper look at the architectural challenges of running Lightning on mobile devices, see the Lightning mobile wallets architecture research article.

• Mobile-first adoption: async payments make self-custodial Lightning wallets viable for everyday users who cannot keep their phone online 24/7
• Reduced reliance on custodians: without async payments, the easiest workaround for offline receiving is to use a custodial wallet. Async payments offer a non-custodial alternative
• Compatibility with static payment codes: combined with BOLT12 offers and BIP-353 human-readable addresses, async payments enable a Venmo-like experience where users share a static username and receive payments whenever they next come online

Use Cases

Mobile Self-Custodial Wallets

The primary use case for async payments is enabling self-custodial mobile wallets to receive payments reliably. A user can share their BOLT12 offer or Lightning address, put their phone away, and know that any incoming payments will be waiting for them when they next open the app. Implementations like LDK have already merged both client-side and server-side async payment logic.

Point-of-Sale Fallback

A merchant running a Lightning node on a tablet or phone might experience brief connectivity interruptions. Async payments provide a safety net: if the merchant's node drops offline momentarily during a customer payment, the LSP can buffer the incoming payment and deliver it when the connection restores, rather than failing the entire transaction.

Cross-Timezone Payments

When a sender and recipient are in different time zones, the chance that both are online simultaneously shrinks. Async payments allow someone in Tokyo to pay someone in New York without needing to coordinate timing: the payment simply waits until the recipient's wallet reconnects.

Security Model

The critical security property of async payments is that the LSP holding the payment must never be able to steal funds. Several mechanisms enforce this:

HTLC-Based Security

In the current HTLC-based approach, the LSP never learns the preimage needed to claim the payment. The preimage is generated by the recipient and only revealed when the recipient comes online and accepts the HTLC. The LSP sees the payment hash but cannot reverse it to derive the preimage.

Timelock Expiry

Every async payment carries a timelock: a deadline by which the recipient must come online and claim the funds. If the recipient fails to reconnect before the timelock expires, the payment automatically fails back to the sender. This prevents funds from being locked indefinitely.

The timelock duration creates a tradeoff: longer timelocks give recipients more time to reconnect but lock the sender's liquidity for longer. Shorter timelocks free up liquidity faster but increase the chance that the recipient misses the payment window.

Future PTLC Improvements

A more advanced approach uses Point Time Locked Contracts (PTLCs) instead of HTLCs. With PTLCs, the payment is locked to a public key rather than a hash. The recipient unlocks it with the corresponding signature when they come back online. PTLCs offer stronger privacy because intermediate routing nodes cannot correlate payments by matching hashes, and they enable more elegant async payment constructions that do not require the sender to remain online.

Risks and Considerations

LSP Trust Assumptions

While the LSP cannot steal funds, it can censor them: a malicious or unreliable LSP could simply not forward the payment notification when the recipient comes online. The recipient would never know a payment was attempted. Mitigations include using multiple LSPs, monitoring for expected payments, and reputation systems.

Liquidity Lock During Hold Period

Async payments lock the sender's channel liquidity for the duration of the hold period. If the recipient stays offline for hours or days, that liquidity is unavailable for other payments. Every routing node along the path also has liquidity tied up, which can strain network capacity.

Proof of Payment Challenges

Standard Lightning payments provide proof of payment via the preimage: once the sender receives the preimage back, they know the recipient was paid. Async payments complicate this because the static invoice used during the hold period does not contain a per-payment hash. Ongoing research is exploring ways to preserve proof-of-payment guarantees for async payments while maintaining the static invoice model.

Implementation Maturity

Async payments remain an active area of development. The BOLT specification (lightning/bolts #1149) is still being refined, and not all Lightning implementations support the full async payment flow. LDK has merged core support, and Eclair has added basic trampoline-based async payments, but LND support depends on completing its onion messaging and BOLT12 implementation.

Async Payments vs. Spark's Approach

Async payments are a protocol-level solution to a problem that Spark avoids by design. In Spark's architecture, the operator network is always available to receive payments on behalf of users. There is no online-receiver requirement because Spark uses a stateless, operator-assisted model rather than Lightning channels that require both parties to be online for HTLC settlement.

This means a Spark wallet can receive Bitcoin or stablecoin payments at any time, regardless of whether the user's device is connected. The user's funds remain self-custodial because the operator cannot unilaterally spend them: the user retains the keys needed for unilateral exit to the Bitcoin base layer at any time.

For applications building with the Spark Wallet SDK, this architectural choice eliminates the need to implement async payment logic, manage trampoline coordination, or worry about timelock expiry windows. Payments simply arrive.

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.