BOLT 12

• Name: BOLT 12
• URL: https://bolt12.org/
• Category: Lightning payment negotiation standard / reusable payment-request standard / route-blinded invoice-and-refund infrastructure
• Tags: bitcoin-ecosystem bitcoin-standards
• Summary: BOLT 12 is a reusable Lightning payment-request standard, not a wallet feature or merchant plugin. The important shift is from one-shot invoice strings toward long-lived offers, invoice requests, refunds, and route-blinded delivery, so wallets and services can negotiate fresh payment objects instead of minting a new static artifact for every interaction.
• What it does:
  • Defines reusable offer objects that can be published once and used to request fresh invoices repeatedly
  • Introduces an invoice-request flow so merchants do not need to mint a new static invoice for every payer up front
  • Adds refund and merchant-pays-user flows alongside the normal payer-to-merchant flow
  • Uses route blinding and onion-message-based request delivery to improve receiver privacy and reduce direct endpoint exposure
  • Supports selective disclosure and payer-proof concepts through its invoice-request and Merkle-signature design
  • Serves as a protocol substrate for higher-level payment identifiers and integrations, including BIP-353-style human-readable names and wallet/app integrations highlighted by the BOLT 12 ecosystem site
• Key claims:
  • The canonical lightning/bolts specification calls BOLT 12 a “Negotiation Protocol for Lightning Payments” and explicitly frames it as addressing multiple BOLT 11 limitations, including one-time invoices, awkward encoding constraints, and weak extensibility
  • The spec says the general payment flow is merchant-published offers → payer invoice requests → merchant-issued invoices → payment, which is the clearest sign that BOLT 12 is a reusable request/negotiation layer rather than just a new invoice string format
  • The same spec describes a separate merchant-pays-user flow for refunds or ATM-style interactions, showing that BOLT 12 is broader than simple customer checkout
  • The specification highlights route blinding, onion-message delivery, and payer-proof/selective-disclosure properties, which makes privacy-preserving request negotiation part of the standard’s core value proposition
  • The BOLT 12 ecosystem site emphasizes reusable payment requests, receiver privacy, social integration, auto-withdrawals, and censorship resistance as the headline user-facing improvements over older Lightning payment flows
  • The developer page shows that support is spreading through concrete implementations rather than a single reference client: Core Lightning exposes experimental offers support, Eclair exposes payoffer, LDK supports creating and paying offers, and LND users can experiment through LNDK
• Whitepaper: No separate standalone BOLT 12 whitepaper or litepaper surfaced in this pass. The canonical source of truth is the BOLT 12 spec in the lightning/bolts repository, supplemented by the community-facing explainer site and implementation notes; see ../../whitepapers/bolt-12-primary-sources-2026-05-02.md.
• Sources:
  • https://bolt12.org/
  • https://bolt12.org/developers
  • https://github.com/lightning/bolts
  • https://raw.githubusercontent.com/lightning/bolts/master/README.md
  • https://raw.githubusercontent.com/lightning/bolts/master/12-offer-encoding.md

Internal linkages

• Static-identifier naming layer that can carry BOLT 12 offers: bip-353
• Callback-based predecessor and contrast where request state is fetched from a service URL rather than negotiated through offers and invoice requests: lnurl
• Concrete implementation note in this corpus: eclair

Control surface

• The leverage sits with whoever publishes the offer, rotates or reuses blinded paths, defines amount and recurrence terms, handles invoice-request policy, and decides how refund flows are exposed.

• That is the real shift from BOLT 11. The durable object is no longer a one-shot invoice string but an offer lifecycle the receiver controls over time.

• Route blinding and onion-message delivery matter because they move privacy and reachability policy into the request path itself rather than leaving the receiver fully exposed.

• Last reviewed: 2026-06-16 UTC