Lightning Async Payments: Receiving Bitcoin While Your Wallet Is Offline

Lightning Network payments are fast, but they come with a hidden requirement: the receiver must be online. When Alice sends Bob a payment, Bob's node needs to be running and connected to reveal the preimage that settles the HTLC. For a server in a data center, that is fine. For a phone in someone's pocket, it breaks the experience.

Async payments are the protocol-level fix. They let a sender push funds into the network even when the receiver is offline, with the payment held at an intermediate node until the receiver reconnects. The idea has been in development for years, and in 2026, real implementations are shipping. This article covers why the problem exists, how the proposed solutions work, what trade-offs they introduce, and where each major Lightning implementation stands.

Why Lightning Requires the Receiver to Be Online

To understand async payments, you first need to understand why Lightning payments require both parties to be present. The answer lies in how HTLCs settle.

A Lightning payment is routed as a chain of HTLCs from sender to receiver through intermediate nodes. Each HTLC is locked with a cryptographic hash. The only way to unlock it is to reveal the corresponding preimage: a secret that only the final receiver knows.

The settlement flow

1. The sender creates an HTLC locked to a payment hash and forwards it along the route.
2. Each intermediate node adds an HTLC to the next hop, forming a chain from sender to receiver.
3. The receiver sees the incoming HTLC and reveals the preimage to claim the funds.
4. The preimage propagates backward through the route: each node reveals it to the previous hop to claim its own HTLC.

Step 3 is the bottleneck. If the receiver is offline, the preimage is never revealed. The HTLCs sit unresolved, locking capital across every node in the route. If the receiver stays offline past the CLTV timeout, the payment fails and funds return to the sender. In the worst case, unresolved HTLCs can trigger a force-close of the channel between the receiver and their peer.

Why this matters for mobile: A mobile Lightning wallet cannot maintain a persistent connection to the network. The app might be backgrounded, the phone asleep, or the user simply not looking at their screen. Any payment sent during that window fails unless the wallet has a workaround in place. This is the core UX barrier for Lightning mobile wallets.

Current Workarounds for Offline Receiving

The Lightning ecosystem has not waited for a formal specification. Several practical workarounds exist today, each with distinct trust assumptions and limitations.

LSP-held payments

The most common approach relies on a Lightning Service Provider (LSP) acting as the receiver's last hop. When a payment arrives and the receiver is offline, the LSP intercepts the HTLC and holds it. The receiver's wallet uses push notifications or background polling to wake up and complete the settlement before the HTLC times out.

Phoenix Wallet (built by ACINQ on Eclair) is the most prominent example. All Phoenix payments route through ACINQ's trampoline node, which holds incoming HTLCs when the user is offline. When the app opens, the HTLC settles normally. If the user never opens the app before timeout, the payment fails and the sender's funds are returned.

Webhook and push notification patterns

Breez developed the Lightning Rod protocol, which uses a Notification Delivery Service (NDS) to wake mobile clients. When a payment reaches the LSP, the LSP calls the NDS via webhook. The NDS sends a push notification to the receiver's phone, waking the app just long enough to complete settlement. This avoids the need for the app to be in the foreground but still requires the phone to be powered on and connected to the internet.

HODL invoices

HODL invoices (also called hold invoices) let a receiver generate an invoice but deliberately withhold the preimage. The HTLC locks on the network, and the receiver can settle or cancel later. While not designed specifically for offline receiving, some applications use HODL invoices as a building block for async patterns.

The problems are significant. Unsettled HODL invoices lock liquidity across every routing node in the path, not just at the last hop. Each Lightning channel supports a maximum of 483 concurrent HTLCs in each direction. A small number of unsettled HODL invoices can saturate a channel, creating a channel jamming vector. And if the HTLC is not resolved before its CLTV expiry, the channel peer will force-close the channel to reclaim its funds.

The BOLT 12 Async Payments Proposal

The formal solution being standardized is BOLTs PR #1149, authored by Valentine Wallace and building on PR #989 (held HTLCs, by Matt Corallo). The proposal integrates with BOLT 12 offers, which were merged into the Lightning specification in October 2025. As of June 2026, PR #1149 is marked ready for review but has not yet been merged into the BOLT specification.

How it works

The design introduces the concept of an always-online intermediary node (typically the receiver's LSP) that can accept and hold payments on the receiver's behalf. The flow works as follows:

1. The receiver (often offline) publishes a BOLT 12 offer containing blinded paths that terminate at their always-online intermediary node.
2. The receiver pre-supplies the intermediary with a static keysend invoice that the intermediary can return to payers.
3. When a sender wants to pay, they request an invoice via the offer. If the receiver is offline, the intermediary returns the static invoice instead.
4. The sender pays the static invoice. The HTLC arrives at the intermediary, which holds it rather than forwarding.
5. When the receiver comes online, the intermediary detects the reconnection and forwards the held HTLC.
6. The receiver reveals the preimage and the payment settles normally.

A key design detail: the original invoice request from the sender is embedded in the HTLC onion payload. This lets the receiver validate the payment when they come online, since they never saw the original request.

The role of trampoline routing

Trampoline routing is closely tied to the async payment design. In a trampoline payment, lightweight clients delegate pathfinding to intermediate trampoline nodes rather than computing the full route themselves. For async payments, the trampoline node serves a dual purpose: it handles routing and acts as the payment holding point.

This matters because it limits the capital lockup. In a standard HODL invoice, every node along the route has an unresolved HTLC locking their channel capacity. With trampoline-based async payments, the HTLC is held only at the first trampoline hop (the receiver's LSP). The upstream route settles normally, and only the last-hop capital is locked while waiting for the receiver.

Trampoline support today: Eclair is the primary champion of trampoline routing, with Phoenix Wallet using it for all payments. LND and Core Lightning do not natively support trampoline routing, which limits how they can participate in the async payment flow.

Onion messages for coordination

The proposal uses onion messages for out-of-band coordination between nodes. When the receiver comes online, their node can send an onion message to the intermediary signaling readiness. The intermediary then releases the held HTLC. Onion messages are lightweight (they do not lock any capital) and use the same onion routing privacy guarantees as regular payments.

Trade-offs and Risks

Async payments solve a real UX problem, but they introduce new trust assumptions and attack surfaces that do not exist in standard Lightning payments.

Trust in the intermediary

The receiver must trust the intermediary node to hold payments honestly and forward them when the receiver reconnects. The intermediary cannot steal funds (it does not know the preimage), but it can selectively drop or delay payments. This is a censorship risk, not a theft risk: the intermediary is typically the receiver's own LSP, so the relationship is already one of service dependency.

Timeout risk

Every HTLC has a CLTV expiry measured in Bitcoin blocks. If the receiver does not come online before the expiry, the payment fails. With Bitcoin blocks averaging roughly 10 minutes, typical CLTV deltas of 40 to 144 blocks give the receiver a window of approximately 7 to 24 hours. For a mobile user who checks their phone daily, this is usually sufficient. For someone traveling without connectivity for days, payments will bounce.

Capital lockup

Even with trampoline-based designs that limit lockup to the last hop, the intermediary's channel liquidity is tied up for the duration. For an LSP processing thousands of payments, this represents real opportunity cost. Capital locked in held HTLCs cannot be used for routing other payments. LSPs may charge higher fees for async payments to compensate, or impose limits on how long they will hold.

Channel jamming amplification

Async payments can amplify existing channel jamming attacks. An attacker could create many async payments to a node they control but never come online to settle them, consuming the intermediary's HTLC slots (capped at 483 per channel direction) and locking its liquidity until timeout. The BOLT 12 proposal mitigates this by limiting held HTLCs to the last hop, but the intermediary remains vulnerable.

Implementation Status Across Lightning

Development is uneven across the four major Lightning implementations. As of mid-2026, LDK leads, with Eclair close behind in experimental support.

LDK: furthest along

The Lightning Dev Kit has the most complete async payment implementation. Server-side logic (PR #3628) and client-side logic (PR #3618) are merged. Receiving support via static BOLT 12 invoices (PR #3440) has also been merged. LDK v0.7.0 shipped with async payment support, and the newly announced LDK Server (revealed at Bitcoin 2026) includes async payments alongside splicing, BOLT 12, and full LSPS support out of the box.

Eclair: trampoline-first approach

ACINQ's Eclair implementation uses a custom async_payment TLV in trampoline onion payloads. When Phoenix Wallet receives a trampoline payment with this TLV, the ACINQ trampoline node holds the HTLC until Phoenix signals it is online. The implementation currently uses proprietary messages between Eclair and Phoenix rather than standardized onion messages. ACINQ tracks full async payment support in Eclair issue #2424, with plans to migrate to the standardized protocol once the BOLT specification is finalized.

LND and Core Lightning

LND introduced async payment support in version 0.17, allowing senders to push payments that receivers can claim when coming online. However, LND lacks native trampoline routing support, which limits its async payment design to LSP-mediated patterns. Core Lightning has not shipped dedicated async payment features, with its recent v25.09 release focusing on BIP353 human-readable names and the xpay payment engine instead.

PTLCs: A Better Foundation for Async

Point Time-Locked Contracts (PTLCs) are the next-generation replacement for HTLCs. Instead of locking payments with a hash and preimage, PTLCs use elliptic curve points and adaptor signatures. This has specific advantages for async payment designs.

With PTLCs, each hop in the payment route calculates its own secret independently. The payment no longer relies on a single preimage that only the receiver knows. This opens the door to more flexible holding mechanisms: an intermediary can commit to forwarding a payment without needing the receiver's specific preimage at hold time. Matt Corallo (Bitcoin Optech, Spiral) has advocated for PTLCs as potentially superior to trampoline-based relay for offline payments.

PTLCs require Taproot channel support across the network. While Taproot has been active on Bitcoin since November 2021, Taproot channel adoption across Lightning implementations is still progressing. PTLCs remain a medium-term improvement rather than an immediate solution.

What the Specification Gap Means

A notable tension exists between implementation and standardization. LDK is shipping async payments in production. Eclair has experimental support via custom messages. But the underlying BOLT specification (PR #1149) remains unmerged. This means different implementations may handle edge cases differently: timeout behavior, error codes, feature bit negotiation, and retry logic could vary across wallets and nodes.

Interoperability is the eventual goal. The BOLT 12 async payment proposal defines a common protocol that all implementations can converge on. But until the spec is finalized, early adopters are building on experimental TLV types and feature bits that may change. Wallet developers integrating async payments today should expect some protocol churn.

How Spark Handles Offline Receiving

Spark sidesteps the async payment problem entirely because it does not use payment channels. Spark is a Bitcoin Layer 2 built on statechains: transfers happen by rotating signing keys rather than routing HTLCs through a channel network. There is no preimage to reveal, no HTLC to settle, and no requirement for the receiver to be online at the moment of transfer.

When someone sends Bitcoin or stablecoins on Spark, the transfer completes on the protocol side regardless of whether the receiver's wallet is open. The receiver sees the funds when they next open their app. No LSP needs to hold a payment. No timeout window constrains when the receiver must appear. No capital is locked waiting for a preimage.

This is not a workaround or an experimental feature: it is a consequence of the architecture. Spark's self-custodial model using FROST threshold signatures means offline receiving works the same way that receiving an email works: the message arrives whether or not you are looking at your inbox.

Looking Ahead

Async payments represent one of the most important UX improvements on Lightning's roadmap. The combination of BOLT 12 offers, trampoline routing, and onion messages creates a viable protocol-level solution. But the timeline for full standardization and cross-implementation interoperability remains uncertain.

For developers building mobile Lightning wallets today, the practical options are LSP-mediated holding (Phoenix model) or webhook-based wakeup (Breez model). Both require an LSP relationship and introduce trust assumptions that do not exist in standard Lightning payments.

For developers who want offline receiving without the complexity, the Spark SDK provides a self-custodial Bitcoin and stablecoin wallet that handles offline receiving natively. Wallets built on Spark, like General Bread, demonstrate what the UX looks like when offline receiving is not a feature to be added but a property of the protocol itself.

This article is for educational purposes only. It does not constitute financial or investment advice. Bitcoin and Layer 2 protocols involve technical and financial risk. Always do your own research and understand the tradeoffs before using any protocol.