BOLT 12 Offers: Static Payment Codes for Lightning

Every Lightning payment today starts with an invoice. The sender asks the receiver for one, the receiver generates it, the sender copies it, and the payment goes through. This works, but it introduces friction that traditional payment systems solved decades ago: you cannot print a static payment code on a website, embed one in a podcast feed, or attach one to a recurring subscription. BOLT 12 changes this by introducing offers: reusable, static payment codes that work natively within the Lightning protocol.

The Problem with BOLT 11 Invoices

The current Lightning invoice format, BOLT 11, was designed for one-time use. Each invoice contains a unique payment hash tied to a specific preimage that the receiver generates. Once the invoice is paid, the preimage is revealed and the hash cannot be reused securely. If a sender pays the same invoice twice, only the first payment can be proven cryptographically.

This design creates several practical problems:

• Invoices expire, typically within minutes to hours, requiring real-time coordination between sender and receiver
• The receiver must be online to generate each invoice, ruling out static donation pages or offline merchants
• There is no native mechanism for subscriptions, recurring billing, or refunds within the protocol
• BOLT 11 invoices encode the receiver's node public key in plaintext, revealing exactly who is being paid to every routing node along the path
• Invoice strings are long and error-prone to share manually

Why not just reuse a BOLT 11 invoice? Reusing a BOLT 11 invoice means reusing a payment hash. After the first payment, every routing node that forwarded the original payment knows the preimage. Any of them could intercept the second payment and claim it before it reaches the receiver. Single-use hashes are a security requirement, not a design oversight.

What BOLT 12 Introduces

BOLT 12 was proposed by Rusty Russell of Blockstream in 2020 as a native protocol extension to the BOLT specifications. Rather than replacing invoices entirely, it adds a layer on top: a static offer that triggers an automated invoice negotiation between sender and receiver, all happening over the Lightning Network itself using onion-routed messages.

The core specification is defined in BOLT 12: Offer Encoding, with the messaging layer specified in BOLT 4 (onion messages). The key primitives are offers, invoice requests, and invoices.

The Offer Flow

A BOLT 12 payment follows a three-step protocol:

1. The receiver publishes a static offer (a short, reusable string starting with lno1). This offer contains the receiver's terms: accepted currency, optional amount, description, and a blinded path to reach the receiver's node
2. The sender's wallet reads the offer and sends an invoice_request message over the Lightning Network's onion message layer. This message travels through the blinded path to reach the receiver without revealing the receiver's node identity to the sender
3. The receiver's node automatically generates a fresh BOLT 12 invoice (with a unique payment hash) and returns it through an onion message. The sender then pays this invoice using standard Lightning HTLC forwarding

Because each payment triggers a fresh invoice, every payment gets its own hash and preimage. The offer itself never expires by default (though expiration can be set), making it safe to print on a webpage, encode in a QR code, or embed in a podcast RSS feed.

Blinded Paths and Receiver Privacy

One of BOLT 12's most significant improvements is receiver privacy through blinded paths. In BOLT 11, the receiver's node public key is embedded directly in the invoice. Every routing node, and the sender, knows exactly which node is receiving the payment. This leaks information about merchant identities, payment volumes, and business relationships.

Blinded paths (sometimes called route blinding) encrypt the last several hops of the path to the receiver. The offer contains an introduction point: a node that knows how to forward to the next hop, but subsequent nodes only see encrypted forwarding instructions. The sender constructs a route to the introduction point, then appends the blinded segment. Neither the sender nor any intermediate routing node learns the receiver's actual node identity.

This works using the same onion routing principles already used for payment forwarding, extended to the message layer. The receiver constructs the blinded path by selecting intermediate nodes and encrypting hop-specific data with each node's public key. Each node in the blinded segment can only decrypt its own forwarding instructions and the encrypted blob for the next hop.

Privacy improvement over route hints: BOLT 11 route hints were designed to help senders find private channels, but they inadvertently reveal the receiver's channel partners and liquidity information. Blinded paths solve the same reachability problem without leaking this data.

How Blinded Paths Compare to Route Hints

Use Cases Enabled by BOLT 12

Static Donation Buttons

Content creators, open-source projects, and nonprofits can publish a single offer string that accepts payments indefinitely. Unlike BOLT 11 invoices that require a server generating fresh invoices for each visitor, an offer works as long as the receiver's node is running. The node handles invoice generation automatically when a sender initiates payment.

Subscriptions and Recurring Payments

BOLT 12 offers support a recurrence field that specifies payment intervals (daily, weekly, monthly, or annual). A subscription offer encodes the terms once. The payer's wallet can then automatically send invoice requests at each interval, and the receiver's node generates invoices with the correct period index. This enables Lightning-native subscriptions without custodial payment processors.

The payer remains in control: their wallet must actively initiate each payment. There is no "pull" mechanism where the merchant debits the payer's balance. This is a fundamentally different model from credit card subscriptions, offering stronger consumer protection while enabling automated recurring flows.

Refunds and Payer-Initiated Offers

BOLT 12 supports "send invoices" in addition to "pay invoices." A merchant can issue an offer that lets the customer request a refund: the customer sends an invoice_request, and the merchant's node responds with a payment. This reverses the typical flow and enables native refund mechanisms without requiring the merchant to know the customer's node identity in advance.

Point-of-Sale and NFC

Offer strings are compact enough to encode in QR codes or NFC tags. A merchant can print a static QR code at the register. When a customer scans it, their wallet sends an invoice request, receives a fresh invoice with the exact amount, and completes payment. The merchant's node handles amount negotiation through the onion message exchange.

BOLT 12 vs LNURL

The Lightning community has not been waiting idly for BOLT 12. LNURL emerged as a practical workaround for BOLT 11's limitations, enabling reusable payment links through HTTP servers. LNURL-pay lets a sender hit a URL that returns a fresh BOLT 11 invoice. LNURL-withdraw enables refund-like flows. Lightning Addresses (user@domain.com format) build on LNURL-pay to provide human-readable identifiers.

LNURL works and is widely deployed, but it operates outside the Lightning protocol itself. This introduces important tradeoffs:

LNURL's reliance on HTTP means the web server sees the sender's IP address unless they use Tor. It also means the receiver must maintain web infrastructure in addition to their Lightning node, creating an additional attack surface and operational burden. BOLT 12 eliminates this by running everything through onion messages on the Lightning Network itself.

That said, LNURL has significant momentum. Lightning Addresses are intuitive and widely supported across wallets. The transition to BOLT 12 will likely be gradual, with both protocols coexisting for years. Some implementations are exploring hybrid approaches where Lightning Addresses resolve to BOLT 12 offers instead of LNURL endpoints.

Implementation Status

BOLT 12 support varies across Lightning implementations. Core Lightning (CLN), maintained by Blockstream, has been the primary driver of the specification and offers the most mature support.

Core Lightning (CLN)

CLN has supported offers since 2022 and has been instrumental in refining the specification. The offer, fetchinvoice, and sendinvoice commands provide full offer lifecycle management. CLN also implements onion messages and blinded paths as building blocks for the offer protocol. The CLN documentation provides detailed API references for building on offers.

LDK (Lightning Dev Kit)

LDK has added BOLT 12 support including offer creation, invoice request handling, and blinded paths. Because LDK is a library rather than a standalone node, its BOLT 12 support enables wallet developers to integrate offers into mobile and embedded applications without running a full node.

LND

LND, maintained by Lightning Labs, has taken a different approach to static payment codes. Rather than implementing BOLT 12 directly, LND has focused on its own BOLT 11-based solutions and other payment enhancements. LND does support keysend (spontaneous payments without invoices) and has implemented some privacy features independently. The question of BOLT 12 adoption in LND remains an active discussion in the community.

Eclair

Eclair, maintained by ACINQ, has implemented support for BOLT 12 including offers and onion messages. As the implementation behind the Phoenix wallet, Eclair's BOLT 12 support brings offers to one of the most popular mobile Lightning wallets.

Technical Details: Offer Encoding

An offer is a TLV (Type-Length-Value) encoded structure, similar to how Lightning invoices are encoded. The offer string uses a lno1 prefix (analogous to BOLT 11's lnbc1) and contains fields such as:

• An optional amount in millisatoshis or a specified currency code
• A human-readable description of what the payment is for
• The node ID of the offer creator, or a blinded path to reach them
• Optional expiration, quantity limits, and recurrence parameters
• A signature proving the offer was created by the claimed node

The resulting strings are shorter than BOLT 11 invoices because they omit per-payment fields like payment hash and expiry. A typical offer might be 50-100 characters for simple cases, compared to 200+ characters for BOLT 11 invoices.

Relationship to PTLCs and Future Upgrades

BOLT 12 pairs naturally with other proposed Lightning upgrades. PTLCs (Point Time Locked Contracts) would replace HTLCs with adaptor signatures based on Schnorr signatures, enabling payment decorrelation across hops. Today, every node in a payment route sees the same payment hash, allowing them to correlate hops of the same payment. PTLCs would give each hop a different point, breaking this correlation.

Combined with BOLT 12's blinded paths, PTLCs would create a Lightning Network where neither sender identity, receiver identity, nor payment correlation is visible to routing nodes. This represents a significant privacy upgrade over the current system.

PTLCs require Taproot support in Lightning channels, which is being actively developed. The combination of Taproot channels, BOLT 12, and PTLCs forms the next generation of Lightning privacy infrastructure.

Limitations and Tradeoffs

Receiver Must Be Online

While offers themselves are static, the invoice negotiation requires the receiver's node to be online to respond to invoice requests. This is the same limitation as LNURL: the infrastructure that generates invoices must be available. For always-on routing nodes, this is not an issue. For mobile wallets, it remains a challenge. Solutions like hodl invoices or LSP-mediated flows can bridge this gap, where a Lightning Service Provider holds the invoice request until the mobile user comes online.

Onion Message Routing

BOLT 12 depends on onion messages (defined in the updated BOLT 4), which are a separate message transport from payment HTLCs. Not all nodes support forwarding onion messages yet, so offer-based payments may fail if no onion message path exists between sender and receiver. As adoption grows, this becomes less of a concern, but it represents a bootstrap problem for early adopters.

No Proof of Payment by Default

BOLT 11 invoices inherently provide proof of payment: the revealed preimage proves the payment was received. BOLT 12 preserves this through the generated invoice, but the link between the static offer and the specific payment is more nuanced. Applications that need strong proof-of-payment semantics need to track the invoice request and response cycle.

How Spark Approaches Static Payments

Spark addresses the static payment problem from a different architectural direction. On Spark, every user has a reusable address that can receive payments at any time. There is no invoice negotiation step: the sender constructs a transfer directly to the recipient's address, and the transfer completes instantly. This is possible because Spark transfers do not use payment channels or hash-based routing. Instead, they operate by transferring ownership of off-chain leaves through cooperative key rotation with the Spark operators.

This means Spark users do not face the BOLT 11 problem in the first place: addresses are inherently reusable, payments do not expire, and recipients can receive while offline (SSPs hold transfers until the user comes online). BOLT 12's blinded paths did influence privacy thinking in the Spark ecosystem, where receiver privacy is achieved through the operator architecture rather than through onion-routed paths.

For users and applications that operate across both networks, Spark's Lightning interoperability means they can pay BOLT 12 offers from a Spark balance. The Spark Service Provider handles the Lightning-side mechanics, including the offer-to-invoice negotiation, transparently.

The Road Ahead

BOLT 12 represents a meaningful evolution of the Lightning protocol. By solving the single-use invoice problem natively, it removes one of the largest UX barriers to Lightning adoption. Static payment codes that preserve privacy, support subscriptions, and require no web infrastructure bring Lightning closer to the experience users expect from modern payment systems.

The path to full adoption involves continued implementation work across Lightning node software, wallet integration, and ecosystem tooling. Interoperability testing between CLN, LDK, and Eclair implementations will be critical. As Taproot channels and PTLCs mature, the privacy benefits of blinded paths will compound with payment decorrelation to create a substantially more private payment network.

For developers building on Lightning today, BOLT 12 support is worth prioritizing. The protocol addresses real user needs: reusable payment codes, better privacy, and native subscription support. Whether through direct node integration or through Layer 2 platforms like Spark that abstract away the complexity, static payment codes are becoming a foundational piece of Bitcoin's payment infrastructure.

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.