LUD-21: Add Onchain Addresses as optional field in PayRequest response

21.md

@@ -0,0 +1,39 @@
+LUD-21: Onchain Addresses in LNURL Pay Response
+=====================================================
+
+`author: Sachin Meier`
+
+## Adding Onchain Addresses to LNURL Pay Response
+
+This optional property allows LNURL Pay responses to include an onchain address to pay to. This is useful for a few reasons, including privacy, fallback, and simple, standardized onchain address distribution.
+
+## Motivation
+
+Adding an optional onchain address to the LNURL Pay response is beneficial for a few reasons.
+
+LNURLPay allows a user to use a static payment code to receive a custom BOLT-11 invoice from a Lightning node, allowing the user to pay a new invoice each time. For BOLT-11, this is necessary. However, for onchain addresses, this is also desirable as it allows the receiver to distribute unique onchain addresses to each of their potential payers. This is beneficial for privacy. 
+
+The onchain address can also serve as a fallback address, allowing wallets that don't use Lightning to still pay an LNURL, allowing a wallet that supports both Lightning and onchain to choose which method to use based on the amount and fee rates, or allowing a wallet whose initial payment of the BOLT-11 invoice fails to fallback to the onchain address.
+
+Finally, this specification allows an LNURL code to be used exclusively for onchain address distribution in a simple, standardized, and well-adopted way. It fulfills a similar function to BIP47 Payment codes in that it exposes a static payment code while each payer pays to a unique address.
+
+## Specification
+
+The onchain address will be returned in the response to the callback request.
+
+```diff
+{
+    "pr": string, // bech32-serialized lightning invoice
+    "routes": [] // an empty array
++    "onchain": {
++       "network": string, // mainnet | testnet | regtest | signet,
++       "address": string, // The onchain address to pay to,
++   }
+}
+```
+
+## Notes
+
+The `maxSendable` and `minSendable` features are ignorable for payers using the onchain address. This is unavoidable. However, receiving amounts outside of this range should have no downsides for the receiver.
+
+The `metadata` field from the first request is also unverifiable. This is unavoidable.

README.md

@@ -25,6 +25,7 @@ These are all the individual documents describing each small piece of protocol t
 | [18][18] | Payer identity in `payRequest` protocol.                    | [Alby][alby], [BitBanana][bitbanana], [Blixt][blixt], [cliché][cliche], [OBW][obw], [ZBD Discord][zbd], [ZBD Telegram][zbd] |
 | [19][19] | Pay link discoverable from withdraw link.                   | [Blixt][blixt], [CoinCorner][coincorner], [OBW][obw] |
 | [20][20] | Long payment description for pay protocol.                  | [Alby][alby], [BitBanana][bitbanana], [Blixt][blixt], [Clams][clams], [cliché][cliche], [Mash][mash], [OneKey][onekey], [Phoenix][phoenix] |
+| [21][21] | Onchain Address in `payRequest` Response.                   | |
 
 [alby]: https://github.com/getAlby/lightning-browser-extension
 [bitbanana]: https://bitbanana.app
@@ -214,6 +215,7 @@ Tools for developers
 [18]: 18.md
 [19]: 19.md
 [20]: 20.md
+[21]: 21.md
 
 Dependency Tree
 ---------------