Yes — BOLT12 is safe to use for everyday Lightning payments as of 2026. The specification has been merged into the official Lightning bolts repository, and at least three production wallets (Phoenix, Zeus, and Strike via the LNDK runtime) ship working implementations on mainnet. The cryptographic primitives BOLT12 introduces — onion messages, blinded paths, offer signatures — have been live on the Lightning network since 2024, and there are no known protocol-level vulnerabilities. The remaining caveats are interoperability and ecosystem coverage, not safety.
To understand what BOLT12 changes, contrast it with the original Lightning invoice format, BOLT11. A BOLT11 invoice is a one-shot, one-recipient, single-amount string that expires after a few minutes. If you want to be paid twice, you generate two invoices. If you want to publish a “tip jar” QR code on a website, you can’t — you’d have to update the QR every few minutes. BOLT11 was elegant for what it was, but the user experience is “give me your invoice each time I want to pay you”, which is awkward at exactly the moments where Bitcoin should feel like cash.
BOLT12 introduces offers: reusable, signed payment requests. You generate one offer, encode it as a QR code or string starting with lno1..., and put it on your website, on a tip card, in a bio. Every payer who scans that offer initiates an onion message to the node behind the offer, asking for a fresh invoice; the receiving node responds with a normal payment hash and an HTLC stream is set up. The offer itself never expires, never reveals the recipient’s node ID directly (it can hide behind a blinded path), and supports recurring or amount-flexible payments out of the box.
Three concrete safety considerations are worth understanding before you start using offers in production:
Privacy is better than BOLT11 by default, but only if the implementation actually uses blinded paths. A BOLT12 offer can either expose the recipient’s node ID or hide it behind a one-to-many blinded path. Phoenix uses blinded paths from day one. Zeus offers a toggle. Self-hosted LND-via-LNDK currently still publishes the raw node ID by default (this is a roadmap item). If you care about which Lightning node receives your payments staying private, verify the implementation defaults before assuming “BOLT12 = privacy”. The protocol enables privacy; the default config in your wallet decides whether you get it.
Onion-message reachability is good but not yet universal. BOLT12 payment setup requires the recipient’s node to be reachable via onion messages, which propagate through the network differently than HTLCs. As of mid-2026, the major routing nodes carry onion messages, but a small fraction of older nodes still do not, and some private nodes may have onion message forwarding disabled. In practice, most senders to most receivers work fine, but if you’re building a service that depends on 100% delivery, fall back to a BOLT11 invoice if the offer-fetch fails. Wallets like Phoenix and Zeus do this transparently.
Spec versioning is real. The BOLT12 specification has gone through multiple draft iterations since 2022, including breaking changes to the offer encoding. The version that was merged into the official spec in late 2025 is the “stable” version. If you generate offers with an old wallet that hasn’t been updated past spec finalization, those offers may not be parseable by current senders. Update your wallet, and verify the encoding version in the offer string if you’re integrating at a low level. For end users this is invisible — keep your wallet updated and you’re fine.
For day-to-day use cases, BOLT12 unlocks things that were genuinely awkward before:
- Static QR tip jars. Phoenix lets you generate a permanent offer, slap it on a sticker, and put it on your laptop or in a bar. Anyone with a BOLT12-capable wallet pays in two clicks; the offer never expires and the funds land in your wallet directly.
- Recurring payments. A subscription service can issue one offer, and the wallet on the customer side initiates the payment fetch on a schedule. No more “your invoice expired, please refresh”.
- Send to a name. When combined with Lightning addresses (LNURL-pay) or DNS-based human-readable identifiers, BOLT12 offers can be resolved from a friendly string. This is where the user experience starts to feel like email-for-money instead of a 200-character base58 string.
Wallets and services that support BOLT12 in production today: Phoenix, Zeus, Strike (via LNDK), Cake Wallet, and self-hosted Core Lightning installations (which had BOLT12 support before merge as the reference implementation). Wallets and services that do not yet support BOLT12 at the time of writing: Wallet of Satoshi, BlueWallet, Muun, and most exchange withdrawal flows. If you’re sending from a wallet that doesn’t support offers, the receiver needs to fall back to a one-shot BOLT11 invoice, which they can usually generate through the same wallet that issued the offer.
If you want to verify a Lightning offer or address before sending to it, paste the string into our Lightning address verifier. It checks the encoding, identifies whether it’s a BOLT11 invoice, a BOLT12 offer, or an LNURL-pay address, and flags common phishing patterns (lookalike domains, malformed payloads). For the underlying invoice payload, our BOLT-11 decoder and BOLT-12 decoder show every field — destination, amount, expiry, route hints, signature validity — without ever attempting a payment. Verify the destination matches what you intended before signing the send.
The short version: yes, BOLT12 is safe and useful enough to be worth setting as your default receive method on a wallet that supports it. The biggest risk in 2026 is not protocol safety — it’s that the person you’re trying to pay is on a wallet that doesn’t support offers yet. Keep a BOLT11 fallback option available, and the rest of the upgrade is invisible upside.