Skip to content

LUD-XX: Add multi-rail payment options to LNURL-pay (LUD-06) - #303

Open
andrerfneves wants to merge 2 commits into
ludsfrom
lud-payment-options
Open

LUD-XX: Add multi-rail payment options to LNURL-pay (LUD-06)#303
andrerfneves wants to merge 2 commits into
ludsfrom
lud-payment-options

Conversation

@andrerfneves

Copy link
Copy Markdown
Collaborator

Bitcoin and Lightning payments have expanded—like it or not—across multiple rails, chains, sidechains, and offchain systems. Unless these flows are abstracted and unified from the user’s perspective, the resulting experience will be fragmented and confusing. We risk repeating the same usability problems that have constrained Bitcoin payment adoption for more than a decade.

LNURL is already deployed across virtually all Lightning-capable wallets, while most new Bitcoin payment wallets also provide Lightning interoperability. LNURL-pay is therefore a practical compatibility layer through which these payment methods can be presented as one coherent flow rather than a collection of unrelated protocols.

Each payment rail has distinct properties, trade-offs, and benefits. This proposal preserves that choice while keeping the payment experience familiar: users can continue scanning existing LUD-06 lnurl1 QR codes or using LUD-16 Lightning Addresses, then select from the payment options supported by both the service and their wallet.

This PR introduces paymentOptions as a backward-compatible extension to LUD-06. Services can advertise supported payment methods, and compatible wallets can select one through the existing LNURL-pay callback flow. Users do not need to understand the technical distinctions between BOLT11, BOLT12, onchain Bitcoin, Liquid, Arkade, Bark, Spark, and future payment methods simply to complete a payment.

Wallets that do not support this extension continue using the standard BOLT11 flow unchanged. This provides an incremental path for introducing multi-rail payments without breaking the LNURL infrastructure already deployed throughout the Lightning ecosystem.

The proposal also extends LUD-21 verification semantics for payment options that do not return a BOLT11 invoice. Its scope is deliberately limited to payment-method selection; assets, currency conversion, quotes, and rail-specific fees remain outside this LUD. The initial registry covers Lightning, onchain Bitcoin, Liquid, Arkade, Bark, BOLT12, and Spark while remaining extensible to future payment methods.

@hsjoberg
hsjoberg self-requested a review August 6, 2026 20:50
@andrerfneves
andrerfneves requested review from Kukks and dni August 6, 2026 20:51
@andrerfneves andrerfneves self-assigned this Aug 6, 2026
@andrerfneves andrerfneves added enhancement New feature or request ready Author considers it final, needs review/merge decision new-lud Brand new protocol extension proposal labels Aug 6, 2026
@shocknet-justin

shocknet-justin commented Aug 7, 2026

Copy link
Copy Markdown
Contributor

concept nack

The beauty of LN (and bolt11 specifically) is that it's the lingua franca, fake layer2's already shim in bolt11 support because they are not lightning and have no choice to expose their closed networks to Lightning's open network. Support for these closed networks is dillution of the "LN" in LNURL and muddles the case for Lightning as the lingua franca.

Even bolt12 is positioned to obviate LNURL, doing so poorly through a Tor-like mechanism. Delivering bolt12 via LNURL is adding yet another round-trip on top of the one Bolt12 already creates, adding yet another failure point in an already failure prone protocol.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request new-lud Brand new protocol extension proposal ready Author considers it final, needs review/merge decision

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants