BOLT12 Adoption in 2026: Reusable Payment Offers and the End of Single-Use Invoices

For most of its history, the Lightning Network has relied on BOLT11 invoices: single-use payment requests that expire, cannot be reused, and expose the recipient's node identity. BOLT12 replaces this model with offers, reusable payment codes that generate fresh invoices on demand through onion messages. After years of development, BOLT12 was formally merged into the Lightning specification in September 2024: the first new BOLT since 2017. By mid-2026, three of four major implementations support it in production, wallets are shipping it to end users, and mining pools are using it for payouts.

But adoption is uneven. LND, the most widely deployed implementation, still lacks native support. Cross-implementation compatibility issues persist. And the existing LNURL ecosystem creates inertia that slows migration. This article examines where BOLT12 stands, what works, what does not, and what remains before single-use invoices can finally be retired.

How BOLT12 Offers Work

A BOLT12 offer is a lightweight, static payment pointer. Unlike a BOLT11 invoice, an offer contains no payment hash. Instead, it says: “contact this node to get an invoice.” The payment hash is generated dynamically when the payee creates an invoice in response to a request. This is what makes offers reusable: a single offer can produce unlimited invoices, each with a unique hash.

The Negotiation Flow

The protocol works through four steps, all conducted over onion messages within the Lightning Network itself.

1. The merchant publishes an offer (QR code, webpage, NFC tag). The offer encodes a node identifier, an optional description, and optionally a price in millisatoshis or a fiat currency code.
2. The payer scans the offer and sends an invoice_request via onion message, including a reply_path so the merchant can respond.
3. The merchant's node validates the request, generates a unique invoice with a fresh payment hash, and sends it back through the reply path.
4. The payer pays the invoice via standard HTLC routing.

This entire flow happens without HTTP servers, without exposing IP addresses, and without any infrastructure outside the Lightning Network. BOLT12 also supports a reverse flow: the merchant publishes an invoice_request and the user responds with an invoice, enabling native refunds without additional protocol layers.

Fiat-denominated offers: BOLT12 offers can specify amounts in ISO 4217 currency codes (USD, EUR, etc.). The payee's node converts to the current BTC exchange rate when generating each invoice. BOLT11 only supports amounts in bitcoin.

What BOLT12 Fixes About BOLT11

BOLT11 has served the Lightning Network since 2017. It works, but its design creates friction that BOLT12 eliminates across multiple dimensions.

The encoding difference is worth noting: BOLT12 offers use TLV (type-length-value) encoding with a bech32-style data string but deliberately omit the bech32 checksum. The rationale is that QR codes have built-in error detection, and encoding errors do not lose funds since no payment hash exists in the offer itself.

How Blinded Paths Improve Privacy

The most significant privacy upgrade in BOLT12 is blinded paths, also called route blinding. In BOLT11, the recipient's 33-byte node public key is directly embedded in the invoice or recoverable from its ECDSA signature. Anyone who sees the invoice can identify the receiving node, look it up in the gossip network, and potentially correlate payments.

How Route Blinding Works

The recipient constructs an encrypted path from a publicly reachable “introduction node” to itself. Each hop in the path receives a blinded node ID computed as: B(i) = HMAC256("blinded_node_id", ss(i)) * N(i), where ss(i) is a shared secret derived through ECDH with a blinding point and N(i) is the real node ID. Each hop's routing information is encrypted using ChaCha20-Poly1305 so only that specific hop can decrypt its forwarding instructions.

The sender sees only the introduction node and a blob of encrypted data. It cannot determine the final recipient's node identity, network position, or how many hops lie beyond the introduction point.

Payer Privacy

BOLT12 also protects the sender. Each invoice_request includes an invreq_payer_id: a fresh ephemeral key generated per payment. Unlike BOLT11, where the sender's identity can be correlated across payments to the same recipient, BOLT12 prevents cross-payment sender correlation by default.

Selective Disclosure via Merkle Signatures

BOLT12 invoices use a Schnorr signature over a Merkle tree where each TLV field occupies two leaves. In a dispute, the payer can reveal specific invoice fields (such as the amount and description) while keeping others hidden, and a third party can still validate the signature against the Merkle root. This enables proof-of-payment without full invoice disclosure: a capability BOLT11 does not support.

Privacy tradeoff: Longer blinded path segments improve anonymity but increase routing fees and reduce payment success probability. Implementations must balance privacy against reliability, and the optimal path length depends on network topology around the recipient.

Implementation Support in 2026

BOLT12 support varies significantly across the four major Lightning implementations. Three now ship it in production; one does not.

Core Lightning (CLN)

CLN has been the driving force behind BOLT12, authored primarily by Rusty Russell at Blockstream. Experimental support appeared in c-lightning v0.10.2 in 2021, requiring an --experimental-offers flag. CLN v24.08 (August 2024) made BOLT12 fully production-ready, and CLN v24.11 (December 2024) enabled it by default with no flag required. CLN v25.09 added BIP 353 human-readable address resolution, allowing commands like lightning-cli xpay user@domain 200sat.

LDK (Lightning Dev Kit)

LDK added BOLT12 structs and builders in v0.0.114 (March 2023), progressed through alpha support in v0.0.118, and reached stable support in LDK v0.1 (January 2025): its first stable release, which included BIP 353 resolution and a security fix for a BOLT12 overpayment vulnerability. The higher-level ldk-node v0.3.0 (June 2024) provides full support for creating and paying offers and refunds.

Eclair

ACINQ's Eclair shipped experimental BOLT12 support in v0.10.0 (February 2024), promoted it to official support in v0.11.0 (December 2024), and added full offer management RPCs in v0.12.0 (March 2025): create, list, and disable offers with configurable blinded path parameters.

LND: The Missing Piece

LND does not natively support BOLT12 as of mid-2026. This is the single largest gap in the ecosystem. The initial feature request (issue #5594) was opened in August 2021. An epic tracking issue (#10220, opened September 2025) outlines a phased approach: onion message forwarding, pathfinding, and offer creation. As of May 2026, graph-based pathfinding for onion messages was merged (PR #10612), but native offer support remains incomplete.

The gap matters because LND powers the majority of public Lightning nodes, largely through its inclusion in node management software like Umbrel and RaspiBlitz. Without native support, the LND ecosystem relies on LNDK, a standalone daemon that plugs into LND's gRPC APIs using LDK's BOLT12 implementation. LNDK requires LND v0.18.0 or later and is used by Strike in production. However, it generates a new key on each restart (preventing persistent offers) and is constrained by LND's API surface.

Wallet and Service Adoption

Implementation support is a prerequisite, but what matters for users is wallet adoption. Several wallets now support BOLT12 in production, though most still default to displaying BOLT11 invoices due to limited ecosystem compatibility.

Wallets Shipping BOLT12

Phoenix (built by ACINQ on Eclair) was among the first wallets to ship BOLT12 support, adding it in v2.3.1 (July 2024) for both Android and iOS. Zeus, which runs on CLN backends, followed in v0.8.5 the same month and includes BIP 353 support through Twelve.cash. Misty Breez, from the Breez SDK team, became the first wallet to support both customizable BIP 353 and LNURL Lightning Addresses simultaneously.

Strike enabled BOLT12 send support in August 2024 using the LNDK backend, allowing users to pay BOLT12 offers. Alby Hub added support in v1.18, though compatibility issues with some services surfaced in later versions.

Mining and Merchant Use

OCEAN, the mining pool, adopted BOLT12 for miner payouts, representing one of the first high-volume production deployments. This exposed real-world interoperability issues: Alby Hub v1.21.2 and later versions encountered decoding errors with OCEAN's BOLT12 payouts, demonstrating that cross-implementation compatibility still requires work.

The bolt12.org directory lists over 30 projects with BOLT12 integration in various stages, including Boltz, Fedimint, Cashu, and Lightspark.

BIP 353: Human-Readable Addresses for BOLT12

One of the usability breakthroughs built on BOLT12 is BIP 353, which maps human-readable identifiers like user@domain to BOLT12 offers using DNS TXT records. The records are stored at user._bitcoin-payment.domain and contain bitcoin: URIs with an lno= parameter pointing to the offer.

Unlike LNURL-based Lightning Addresses, which require an always-online HTTP server, BIP 353 addresses use DNS infrastructure that already exists. The records must be DNSSEC-signed, and clients must validate signatures locally. However, DNSSEC adoption remains limited: as of 2026, less than 1% of DNS queries are both signed and validated by resolvers, creating a practical deployment challenge.

The LNURL Question

BOLT12 does not exist in a vacuum. The LNURL protocol suite, developed outside the BOLT specification process, already provides much of what BOLT12 offers: reusable payment codes (LNURL-pay), withdrawal flows (LNURL-withdraw), and human-readable addresses (Lightning Addresses via LNURL).

The two approaches reflect different design philosophies. LNURL leverages existing web infrastructure (HTTPS, JSON, DNS) and is already deployed across dozens of wallets, exchanges, and services. BOLT12 keeps everything within the Lightning Network, avoiding web server dependencies and gaining privacy through onion messaging. Neither is strictly superior: they serve different deployment models and threat assumptions.

For services already running LNURL infrastructure, migration to BOLT12 offers limited immediate benefit and requires re-engineering. This creates ecosystem inertia that slows adoption, particularly among merchants and exchanges with working LNURL integrations.

Cross-Implementation Compatibility Issues

Despite the specification being formally merged, production deployments have revealed interoperability gaps between implementations.

• CLN cannot pay BOLT12 offers created by Phoenix, described by developers as a protocol-level incompatibility rather than a bug.
• CLN v24.05 could not fetch invoices from LDK-generated offers due to differences in how each implementation handles node ID hiding.
• CLN could not fetch invoices from offers lacking a description field, though the specification does not require one.
• Alby Hub v1.21.2 encountered decoding errors with OCEAN's BOLT12 payouts.
• Test vectors added to the specification in March 2026 revealed that both CLN and LDK accepted invalid bech32 padding, a parsing inconsistency that had gone undetected.

These issues are being resolved through specification clarifications and test vector additions, but they illustrate a fundamental challenge: BOLT12's onion-message-based flow is more complex than BOLT11's simple encode-and-pay model. More moving parts mean more surface area for implementation divergence.

Remaining Specification Gaps

Community discussion on Delving Bitcoin has identified several specification gaps that BOLT12 has not yet addressed.

• No expiration field for invoice requests, meaning a request can be replayed after the payer intended it to lapse.
• No maximum amount constraint on offers, preventing merchants from capping individual payment sizes.
• No standardized refund mechanism beyond the basic reverse flow.
• No bundled payment support for atomic multi-invoice transactions.

Additionally, onion messages are designed to be “inherently unreliable” with one-way delivery. A single onion message can traverse up to 468 hops, and forwarding is nearly free, creating a potential DoS vector. Current mitigations include rate limiting (10 messages per second for nodes with channels, 1 per second without), but these have acknowledged weaknesses.

Timeline of Key Milestones

BOLT12's path from proposal to production has been long, but the pace of adoption accelerated sharply in late 2024.

What BOLT12 Means for the Broader Bitcoin Payment Ecosystem

BOLT12 addresses real problems in Lightning's payment UX: invoice expiry, recipient privacy, and the inability to create static payment endpoints. For use cases like tipping, subscriptions, and point-of-sale payments, reusable offers are a meaningful improvement over the generate-copy-paste cycle of BOLT11.

However, BOLT12 operates within Lightning's fundamental architecture. Users still need channel liquidity, must be online to receive payments (or rely on Lightning Service Providers), and face the operational complexity of channel management. Offers improve the invoice layer but do not simplify the underlying channel infrastructure.

Alternative approaches to Bitcoin payment addressing take different paths. Spark, for instance, avoids the invoice and offer complexity entirely. Because Spark does not use payment channels, there are no invoices to manage, no channel capacity to worry about, and no requirement for the recipient to be online. Payments resolve through FROST threshold signatures and statechain transfers rather than HTLC routing. Both approaches push Bitcoin payments toward better UX, but they operate at different layers of the stack: BOLT12 improves Lightning's payment request format while Spark rethinks the payment architecture itself.

What Comes Next

Several developments will shape BOLT12's trajectory through the rest of 2026.

LND's native support is the most consequential pending milestone. The phased approach outlined in LND's tracking issue suggests onion message forwarding comes first, followed by pathfinding (partially merged), and finally offer creation. Until LND ships native BOLT12, the majority of Lightning nodes cannot create or receive offers without third-party software.

Payer proofs are an active area of specification work (BOLTs #1295), with CLN already implementing a createproof RPC. This would allow payers to cryptographically prove they made a specific payment, enabling dispute resolution and receipt verification.

BLIPs #42 proposes a BOLT12 contacts specification, laying groundwork for persistent payment relationships between nodes. And BIP 353 adoption depends on broader DNSSEC deployment, which remains slow but is being pushed forward by wallet implementations that bundle their own DNSSEC validation.

Developers building on Lightning can explore BOLT12 integration through Spark's documentation, which covers how Spark interoperates with Lightning including BOLT12 offers. For a deeper comparison of invoice protocols, see the BOLT11 vs BOLT12 explainer and the PTLCs article covering the next evolution of Lightning's payment primitives.

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.