Intro
Businesses and developers now leverage BOLT 12 offers to automate subscription billing on the Bitcoin lightning network. This protocol upgrade enables merchants to generate reusable payment requests without exposing sensitive invoice data. The system eliminates manual invoice generation for each transaction cycle. Users gain a streamlined experience for recurring payments across services, donations, and subscriptions.
Key Takeaways
BOLT 12 introduces offer-based payments that replace traditional static invoices. The protocol supports unlimited identical payments to the same offer. Privacy improves through blinded paths that hide recipient details. Merchants can embed offers directly into apps or websites without server-side invoice management. The system builds upon Lightning Network infrastructure while adding subscription-native features.
What is BOLT 12
BOLT 12 defines a new offer protocol for the Lightning Network that enables persistent payment requests. The specification introduces two primary constructs: offers and their corresponding redemptions. An offer represents a reusable request that payers can fulfill multiple times using the same cryptographic proof. Unlike traditional invoices that expire after single use, offers remain valid until revoked by the creator. The protocol uses BOLT 12 encoding to structure these payment requests in a standardized format.
Why BOLT 12 Matters
Traditional Lightning invoices require servers to generate unique identifiers for each transaction, creating operational overhead. Businesses must maintain database infrastructure to track payment states and regenerate invoices on schedule. BOLT 12 shifts this burden to client software, enabling true peer-to-peer recurring payments. The Lightning Network’s scalability advantages multiply when merchants avoid per-transaction invoice generation. Users benefit from one-click subscription activations without trusting merchant servers with payment credentials.
How BOLT 12 Works
The mechanism operates through a structured offer lifecycle that handles payment authorization and fulfillment.
Offer Creation:
Merchant → [Offer ID, Amount, Currency, Description, Timeout] → Encoded Offer String
Offer Acceptance:
Payer → [Signature over Offer ID + Payer Key] → Creates Bound Invoice
Payment Redemption:
Payer → [Bound Invoice + HTLC] → Merchant verifies signature → Payment completes
The formula for offer derivation follows: OfferHash = SHA256(Chain || OfferData). Each payment increments a counter in the blinded path, preventing correlation between transactions. The payer generates a unique keypair for each offer acceptance, ensuring that multiple payments to the same offer appear unrelated on-chain. Merchants verify signatures using the offer’s base point without learning the payer’s node public key.
Used in Practice
Real-world implementations demonstrate BOLT 12’s viability across multiple use cases. Streaming services can embed monthly subscription offers directly into mobile apps, allowing instant activation without registration flows. Content creators generate lifetime donation offers that supporters fulfill at their preferred intervals. SaaS platforms integrate offers for metered billing, where each payment represents accumulated usage units.
Implementation requires wallet support and merchant infrastructure updates. Popular Lightning wallets including Phoenix, Electrum, and BlueWallet have begun integrating offer functionality. Developers use libraries like ldk-node or rust-lightning to embed offer generation in backend systems. The protocol works across federated sidechains and mainnet Bitcoin, providing consistent behavior regardless of underlying chain characteristics.
Risks / Limitations
BOLT 12 adoption remains constrained by wallet ecosystem fragmentation. Not all Lightning wallets support offer acceptance, limiting potential payer pools. Merchants must implement fallback invoice systems for users without offer-capable wallets. The specification continues evolving, creating compatibility risks for early adopters.
Privacy guarantees depend on payer behavior during offer acceptance. Repeated payments to the same offer may leak correlation data if payers reuse key material. The blinded path mechanism mitigates this risk but requires proper implementation in wallet software. Additionally, offer revocation requires on-chain transactions for certain revocation methods, adding cost considerations for high-frequency payment scenarios.
BOLT 12 vs Traditional Invoices
Traditional Lightning invoices serve single payments and expire after use or timeout. Merchants generate unique invoices through backend services that maintain state databases. Each invoice requires separate HTLC negotiation and on-chain gossip propagation.
BOLT 12 offers enable multiple payments to identical requests without merchant-side state management. The payer maintains offer acceptance records locally, reducing merchant infrastructure requirements. Offers propagate through different network channels than standard invoices, with blinded path forwarding hiding recipient identities. Traditional invoices remain necessary for one-time payments, while offers excel at subscription models where payment amounts remain consistent.
What to Watch
The Lightning Network community continues refining offer specifications through BOLT improvement proposals. Upcoming versions may add invoice-less offers that allow payments without prior offer creation. Multi-path offer redemption could enable larger recurring payments exceeding single channel limits. Watch for wallet announcements expanding offer support to mobile and hardware implementations.
Regulatory developments may impact recurring crypto payment adoption in certain jurisdictions. Tax reporting requirements for subscription payments using Bitcoin vary by country. Merchants should evaluate compliance obligations before deploying offer-based billing systems. The intersection of Lightning’s privacy features and regulatory transparency requirements remains an evolving landscape for businesses.
FAQ
Can BOLT 12 offers expire?
Yes. Offers include an optional timeout parameter that invalidates the offer after a specified timestamp. Merchants set expiration periods based on their business requirements.
How do refunds work with BOLT 12 offers?
The current specification does not define refund mechanisms. Offer-based payments are atomic by design. Refund scenarios require separate out-of-band agreements between parties.
What happens if a payment fails mid-transaction?
HTLC mechanics ensure that failed payments revert automatically. The payer can retry using the same bound invoice without generating new offer acceptance. Offer state remains consistent across failed attempts.
Do both parties need BOLT 12 support?
The payer must use a compatible wallet to accept offers. Merchants can create offers without recipient wallet support, but payers need offer-capable software to fulfill payments.
Can offers specify variable payment amounts?
BOLT 12 supports both fixed and variable amount offers. Variable offers use amt fields that payers populate before payment. This enables usage-based subscription models where each payment reflects actual consumption.
How does BOLT 12 improve merchant privacy?
Blinded paths prevent payers from learning merchant node details. Each offer generates unique blinded route information that breaks correlation between multiple payments to the same recipient.
Are BOLT 12 payments reversible?
No. Like all Lightning payments, BOLT 12 transactions settle immediately and irreversibly on the Lightning Network. Merchants should establish clear refund policies before accepting offer-based subscriptions.
Leave a Reply