# Lightning Address
> Source: https://docs.barcoder.ai/docs/standards/lightning-address
> research date 2026-06-04 · extracted at 2026-10-06
> Publisher: Barcoder — encyclopedia of QR, barcode and payment-code standards
Specifications:
- [Lightning Address — like an email address, but for Bitcoin](https://github.com/andrerfneves/lightning-address)
- [LUD-16: Paying to static internet identifiers](https://github.com/lnurl/luds/blob/luds/16.md)
## Overview
A **Lightning Address** is a human-readable identifier in the familiar `user@domain` email-like form (e.g. `satoshi@bitcoin.org`) that resolves to an [LNURL](https://docs.barcoder.ai/docs/standards/lnurl)-pay endpoint, letting anyone receive Bitcoin Lightning payments without sharing a single-use [BOLT11](https://docs.barcoder.ai/docs/standards/bolt11) invoice or a raw [LNURL](https://docs.barcoder.ai/docs/standards/lnurl) string.[1][1][2][2] It is standardized as **LUD-16** ("Paying to static internet identifiers") in the [LNURL](https://docs.barcoder.ai/docs/standards/lnurl) spec set, and is effectively a friendly front-end over [LNURL](https://docs.barcoder.ai/docs/standards/lnurl)-pay (LUD-06).[2][2] Because the address itself is short ASCII text, it is also commonly published, shared as text, or embedded in a [QR Code](https://docs.barcoder.ai/docs/standards/qr-code) for scan-to-pay.[1][1]
## History
Lightning Address was created by **Andre Neves** (GitHub `andrerfneves`); the reference repository is `andrerfneves/lightning-address` and frames the idea as "like an email address, but for your Bitcoin," whose goal is to remove the friction of scanning QR codes or pasting invoices.[1][1] The protocol is built directly on the [LNURL](https://docs.barcoder.ai/docs/standards/lnurl)-pay specification.[1][1] It was subsequently captured as **LUD-16** in the canonical `lnurl/luds` repository, which defines the on-the-wire resolution and response rules.[2][2]
## Technical specification
### Resolution
Given an address `@`, a wallet constructs and GETs a `.well-known` URL:[1][1][2][2]
```
https:///.well-known/lnurlp/ (clearnet)
http:///.well-known/lnurlp/ (onion)
```
Per LUD-16, allowed username characters are `a-z0-9-_.` (lowercase), and a `username+tag@domain` form may be supported, with the tag optionally surfaced in metadata.[2][2]
### Mapping to [LNURL](https://docs.barcoder.ai/docs/standards/lnurl)-pay
The endpoint returns the **same JSON as [LNURL](https://docs.barcoder.ai/docs/standards/lnurl)-pay step 3 (LUD-06)**, and the flow proceeds identically thereafter:[2][2]
- `callback` — URL the wallet calls with an amount,
- `minSendable` / `maxSendable` — bounds in **millisatoshi**,
- `metadata` — a stringified array that, for Lightning Address, must include an identifier entry: `text/identifier` for a generic internet identifier or `text/email` for an actual email address,
- `tag: "payRequest"`.
The wallet then GETs `?amount=` and receives `{"pr": "", ...}`, which it pays.[2][2] In short, a Lightning Address is resolved to an [LNURL](https://docs.barcoder.ai/docs/standards/lnurl)-pay endpoint and from there is indistinguishable from any other [LNURL](https://docs.barcoder.ai/docs/standards/lnurl)-pay flow.[1][1][2][2]
## Use cases
- **Receive-anywhere identifier**: publish `you@wallet.com` on a profile, invoice or business card and accept Lightning payments without rotating invoices.[1][1]
- **Tips and donations**: a static, shareable address (or its [QR Code](https://docs.barcoder.ai/docs/standards/qr-code)) collects many payments.[1][1][2][2]
- **Streaming / value-for-value**: podcast and content platforms route sats to a creator's Lightning Address.[1][1]
## Implementations
- **andrerfneves/lightning-address** — the reference spec, primer and diagrams (JS/Markdown), active 2026.[1][1]
- **lnbits/lnurlp** — LNbits "Pay Links" extension that serves `.well-known/lnurlp/...` endpoints, i.e. hosts Lightning Addresses.[3][3]
- Most major Lightning custodial and self-hosted wallets/services issue and resolve Lightning Addresses via LUD-16.[1][1][2][2]
## Comparison
- **Lightning Address vs single-use [BOLT11](https://docs.barcoder.ai/docs/standards/bolt11)**: a [BOLT11](https://docs.barcoder.ai/docs/standards/bolt11) invoice is typically single-use with a fixed hash, amount and expiry; a Lightning Address is a permanent, reusable identifier that produces a fresh invoice per payment via [LNURL](https://docs.barcoder.ai/docs/standards/lnurl)-pay.[2][2]
- **Lightning Address vs raw [LNURL](https://docs.barcoder.ai/docs/standards/lnurl)**: both ultimately drive the [LNURL](https://docs.barcoder.ai/docs/standards/lnurl)-pay flow, but the address is short human-readable text (`user@domain`) instead of a long bech32 `lnurl1...` string, trading some QR compactness for memorability.[1][1][2][2]
- **vs [BIP-321 (Bitcoin unified QR)](https://docs.barcoder.ai/docs/standards/bip-321) `lightning=`**: [BIP-321 (Bitcoin unified QR)](https://docs.barcoder.ai/docs/standards/bip-321) embeds a concrete Lightning instruction (a [BOLT11](https://docs.barcoder.ai/docs/standards/bolt11) invoice or BOLT12 offer) inside a `bitcoin:` URI, whereas a Lightning Address is an indirection that must be resolved over HTTPS first.[1][1][2][2]
## Status
Lightning Address is an active, widely supported convention across the Lightning ecosystem, standardized as LUD-16 and maintained in 2026.[1][1][2][2]
## Sources
[1]: https://github.com/andrerfneves/lightning-address
[2]: https://github.com/lnurl/luds/blob/luds/16.md
[3]: https://github.com/lnbits/lnurlp
[1] [Lightning Address — like an email address, but for Bitcoin](https://github.com/andrerfneves/lightning-address) — Andre Neves / GitHub, 2026
[2] [LUD-16: Paying to static internet identifiers](https://github.com/lnurl/luds/blob/luds/16.md) — lnurl/luds, 2026
[3] [lnbits/lnurlp](https://github.com/lnbits/lnurlp) — GitHub, 2026
## Deployments
_No country reports mention this standard by name._
## Regions / aggregations not mapped to a single country
- Universal