These are all the individual documents describing each small piece of protocol that can be implemented under the LNURL umbrella. Different wallets and services may implement different sets of protocols.
| Number | Description |
|---|---|
| 01 | Base LNURL encoding and decoding. |
| 02 | channelRequest base spec. |
| 03 | withdrawRequest base spec. |
| 04 | Auth base spec. |
| 05 | BIP32-based seed generation for auth protocol. |
| 06 | payRequest base spec. |
| 07 | hostedChannelRequest base spec. |
| 08 | Fast withdrawRequest. |
| 09 | successAction field for payRequest. |
| 10 | aes success action in payRequest. |
| 11 | Disposable and storeable payRequests. |
| 12 | Comments in payRequest. |
| 13 | signMessage-based seed generation for auth protocol. |
| 14 | balanceCheck: reusable withdrawRequests. |
| 15 | balanceNotify: services hurrying up the withdraw process. |
| 16 | Paying to static internet identifiers. |
| 17 | Scheme prefixes and raw (non bech32-encoded) URLs. |
| 18 | Payer identity in payRequest protocol. |
| 19 | Pay link discoverable from withdraw link. |
| 20 | Long payment description for pay protocol. |
| 21 | verify LNURL-pay payments |
| 23 | Request user's Lightning address |
| Name | LUDs |
|---|---|
| Addressless | 01 06 09 16 |
| Bleskomat | 01 03 |
| BTCPayServer | 01 06 16 17 |
| Citadel Bitcoin Node | 01 06 16 |
| Cypherapp | 01 03 |
| LNURL Daemon | 01 03 04 06 09 12 16 |
| LNURLPoS | 01 06 09 |
| LNURLp | 01 06 12 |
| LNURLw | 01 03 |
| LNbits.com | 01 03 04 14 15 |
| LightningATM | 01 03 |
| NextPay | 01 06 16 |
| OfflineShop | 01 06 09 |
| Satdress | 01 06 09 16 |
| Streamer Copilot | 01 06 12 |
| electrum-lnurl-server | 06 16 |
| go-host-lnaddr | 01 06 09 16 |
| ligess | 01 06 09 16 |
| lnme | 01 06 09 16 |
| Name | LUDs |
|---|---|
| IMMORTAN | 01 02 03 04 05 06 07 08 09 10 11 12 16 17 18 20 |
| LNURL C# | 01 02 03 04 06 07 08 09 10 11 12 14 15 16 17 18 19 |
| dart-lnurl | 01 02 03 04 05 06 09 10 11 12 14 17 18 19 |
| go-lnurl | 01 02 03 04 06 08 09 10 11 12 14 16 18 20 |
| js-lnurl | 01 02 03 04 06 08 09 10 11 12 |
| lnurl-node | 01 02 03 04 06 08 09 10 11 12 |
| lnurl-platformio | 01 03 |
| lnurl-ruby | 01 06 09 |
| lnurlauth | 01 04 |
| php-lnurl | 01 |
| python-lnurl | 01 02 03 04 06 |
| bitcoin-s | 01 03 06 09 |
| lnurl-rs | 01 03 06 |
| rust-lnurl | 01 03 04 |
| spring-lnurl | 01 04 |
| lnurl_client-ex | 01 06 |
| Name | LUDs |
|---|---|
| LNURLProxyAPI | 01 03 |
| Lightning Decoder | 01 02 03 04 06 16 |
| Lightning Login | 01 04 |
| bifrost | 01 02 |
| lnch-vekslak | 01 02 |
| lnurl codec JS | 01 |
| lnurl codec Scala | 01 |
| lnurl playground | 01 02 03 04 06 09 10 12 14 15 18 20 |
| lnurl-toolbox | 01 02 03 04 06 |
| passport-lnurl-auth | 01 04 |
| Zerologin | 01 04 |
The entire idea of the suite of LNURL protocols is that they are optional. Each new LUD may be implemented by some wallets and not others, some services and not others, but they should still maintain compatibility at all times (except, of course, if the service requires the new functionality).
There is also a hierarchy of internal dependencies between the LUDs -- for example, you cannot implement sending comments in payRequests if you haven't implemented the base payRequest spec also. The following graph displays that hierarchy of internal dependencies (you can safely ignore it though).
Open a pull request with your proposal. Pick the next unreserved number for your proposal. To be accepted, it just has to be generally decent and make sense and be implemented or currently being implemented by 2 or more wallets.
Join https://t.me/lnurl if you just want to talk about your ideas or chat about LNURL protocols in general.