LUD-XX: Add multi-rail payment options to LNURL-pay (LUD-06) - #303
Open
andrerfneves wants to merge 2 commits into
Open
LUD-XX: Add multi-rail payment options to LNURL-pay (LUD-06)#303andrerfneves wants to merge 2 commits into
andrerfneves wants to merge 2 commits into
Conversation
hsjoberg
self-requested a review
August 6, 2026 20:50
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. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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
lnurl1QR codes or using LUD-16 Lightning Addresses, then select from the payment options supported by both the service and their wallet.This PR introduces
paymentOptionsas 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.