Lightning Address

What Is a Lightning Address?

A Lightning Address is a human-readable payment identifier for the Lightning Network that uses the familiar email format: user@domain.com. Instead of sharing a one-time invoice string or scanning a QR code for every payment, a recipient can share a single static address that anyone can pay repeatedly.

The protocol was created by Andre Neves and is formally specified as LUD-16 within the LNURL specification suite. It works by mapping the email-like identifier to an HTTPS endpoint on the recipient's domain. When someone sends a payment to satoshi@example.com, their wallet fetches a fresh BOLT11 invoice from https://example.com/.well-known/lnurlp/satoshi and pays it over the Lightning Network.

Lightning Addresses solve a major UX friction point. Standard Lightning invoices are single-use, expire quickly, and consist of long strings of characters that are impractical to share in profiles, business cards, or social media bios. A Lightning Address gives users a permanent, memorable payment identifier comparable to an email address or bank account number.

How It Works

Lightning Address is not a standalone protocol: it is a thin layer on top of LNURL-pay that converts a human-readable address into the correct HTTPS URL. The entire payment flow involves two HTTP requests followed by a standard Lightning payment.

Resolution Flow

When a sender enters a Lightning Address, their wallet follows these steps:

1. Parse the address into username and domain: alice@example.com becomes username alice and domain example.com
2. Construct the well-known URL: https://example.com/.well-known/lnurlp/alice
3. Make an HTTP GET request to that URL
4. Receive a JSON response containing payment parameters (minimum and maximum amounts, a callback URL, and metadata)
5. Display the payment details to the sender, who enters the amount
6. Make a second HTTP GET request to the callback URL with the amount in millisatoshis
7. Receive a fresh BOLT11 invoice in the response
8. Verify the invoice's description hash matches the metadata, then pay the invoice over Lightning

Technical Response Format

The first HTTP response from the well-known endpoint returns a JSON object following the LNURL-pay specification (LUD-06):

// GET https://example.com/.well-known/lnurlp/alice
{
  "tag": "payRequest",
  "callback": "https://example.com/lnurlp/alice/callback",
  "minSendable": 1000,
  "maxSendable": 100000000,
  "metadata": "[["text/plain","Pay alice@example.com"],["text/identifier","alice@example.com"]]",
  "commentAllowed": 255
}

The minSendable and maxSendable fields are denominated in millisatoshis. The metadata field is a JSON-encoded string containing at least a plain text description and a text/identifier entry with the Lightning Address itself.

The second request hits the callback URL with the chosen amount:

// GET https://example.com/lnurlp/alice/callback?amount=50000
{
  "pr": "lnbc500n1pj9...",
  "routes": []
}

The pr field contains a standard BOLT11 invoice. The sender's wallet verifies that the invoice's description hash equals the SHA-256 hash of the metadata from the first response, ensuring the server has not tampered with the payment details. If verification passes, the wallet pays the invoice through the normal HTLC routing process.

Self-Hosting a Lightning Address

Any domain owner can serve Lightning Addresses by hosting a simple HTTPS endpoint. The server needs to respond to GET requests at the well-known path and return valid LNURL-pay JSON. Several open-source tools simplify this:

# Bridgeaddr: connects to your own Lightning node
# Serves Lightning Addresses from your domain

# LNbits: self-hosted Lightning accounts system
# Provides LNURL endpoints including Lightning Address

# phoenixd-lnurl: LNURL server for the Phoenix daemon
# Non-custodial Lightning Address via phoenixd

Why It Matters

Lightning Addresses transformed the Lightning Network's user experience by solving the reusability problem. Before Lightning Addresses, receiving a payment required generating a new invoice for each transaction: a workflow that works for point-of-sale terminals but fails for tips, donations, recurring payments, and any scenario where the recipient is not actively online to create an invoice.

The email-like format also dramatically lowers the barrier to adoption. Users do not need to understand invoices, payment hashes, or onion routing. They simply enter an address that looks familiar from decades of email usage. This simplicity has made Lightning Addresses the most widely adopted LNURL specification, supported by over 40 wallets and services.

For businesses and developers building on Bitcoin payment infrastructure, Lightning Addresses provide a stable identifier that can be integrated into payment forms, invoicing systems, and social platforms. Layer 2 protocols like Spark benefit from this broader ecosystem of reusable identifiers, as they push the Lightning Network toward mainstream payment usability.

Custodial vs Non-Custodial Implementations

Because Lightning Addresses require an HTTPS server to respond to payment requests, the question of who controls that server (and the underlying Lightning node) determines whether the implementation is custodial or self-custodial.

Custodial Providers

Most Lightning Addresses today are custodial. Services like Wallet of Satoshi, ZBD, Strike, and Cash App assign users an address on the provider's domain (for example, user@walletofsatoshi.com). The provider runs the LNURL server, controls the Lightning channels, and holds custody of user funds. This model is simple for end users but introduces counterparty risk: the provider can freeze funds, go offline, or be compelled to comply with regulatory actions.

Self-Custodial Options

Non-custodial Lightning Addresses require more infrastructure but preserve user sovereignty. Approaches include:

• Running your own LNURL server connected to a personal Lightning node on a domain you control
• Using self-custodial wallet services like Alby Hub, which transitioned fully to self-custody in January 2025, where users run their own node while Alby provides the LNURL endpoint
• Deploying lightweight bridge software (Bridgeaddr, lnurld) that proxies LNURL requests to your node without a third party holding your keys

The tradeoff is clear: custodial addresses work out of the box, while self-custodial setups require a domain, server, and node management. This tension mirrors the broader custodial vs self-custodial debate across Bitcoin infrastructure.

Use Cases

• Tips and donations: content creators, open-source developers, and musicians publish a Lightning Address in their profile or website, allowing anyone to send payments without coordinating invoice generation
• Social payments: platforms like Nostr integrate Lightning Addresses directly into user profiles (sharing the same user@domain.com format as NIP-05 verification), enabling in-app tipping
• E-commerce checkout: merchants accept Lightning payments by displaying a static address rather than generating per-session invoices, simplifying integration with existing payment flows
• Payroll and disbursements: organizations can pay contractors or employees to their Lightning Addresses, treating them like bank account details for streaming salary payments
• Cross-platform identity: a single Lightning Address can serve as a payment identity across multiple applications, wallets, and services

Lightning Address vs BOLT12 Offers

BOLT12 offers represent an alternative approach to reusable payment identifiers that operates entirely within the Lightning Network protocol, without requiring external web infrastructure.

A third approach, BIP 353 ("DNS Payment Instructions"), aims to bridge the gap by storing BOLT12 offers in DNSSEC-signed DNS TXT records. This would combine the human-readable address format with BOLT12's privacy properties, eliminating the need for an HTTP server. Read more about the technical evolution of Lightning invoices in our BOLT11 and BOLT12 deep dive.

Risks and Considerations

Privacy and IP Exposure

Every time a sender pays a Lightning Address, their wallet makes an HTTPS request to the recipient's domain. This exposes the sender's IP address to the recipient's web server (unless the sender routes through Tor). The server operator can log IP addresses, timestamps, requested amounts, and payment frequency: building a detailed profile of who pays whom and how often. For a deeper analysis, see our Lightning Network privacy guide.

DNS and Server Dependency

Lightning Addresses depend on DNS resolution and HTTPS availability. If the recipient's domain goes offline, DNS records expire, or the TLS certificate lapses, all payments to that address fail. This introduces a centralized point of failure that does not exist with native Lightning invoices or BOLT12 offers. Domain seizures or hosting provider actions could also disable an address without the recipient's consent.

Custodial Trust Requirements

The majority of Lightning Addresses in use today are custodial. Users of services like Wallet of Satoshi or Strike do not control their own keys. Regulatory actions have already impacted this ecosystem: Wallet of Satoshi withdrew from the US market in November 2024 and shut down EU custodial services in January 2026 due to MiCA compliance requirements. Users relying on custodial Lightning Addresses risk losing access if their provider exits a jurisdiction or shuts down.

No Offline Receiving

The recipient's LNURL server must be online to generate invoices. Unlike an on-chain Bitcoin address or a BOLT12 offer (which can use blinded paths for asynchronous receiving), a Lightning Address cannot receive payments if the backing server is unreachable. This makes reliability critical for anyone depending on a Lightning Address for business payments.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.