Lightning Address: What It Is and How to Get One

The worst part of receiving Bitcoin used to be telling someone where to send it.

On-chain, you'd hand them a 34-character string of gibberish — bc1qxy2kgdygjrsqtzq2n0yrf2493p83kkfjhx0wlh — and hope they copied it right. On Lightning, it was even worse: invoices are longer, single-use, and expire. Want to get paid twice? Generate another invoice. Want to put a payment link in your Twitter bio? Can't — it'll be dead in an hour.

Lightning addresses fixed this by doing something obvious that took years for anyone to actually build: they made Bitcoin payments look like email.

alice@ln.bot

Share it once, receive payments forever. Any amount, any wallet, any time. Put it in your bio, print it on a business card, paste it in a group chat. If the sender has a Lightning wallet, they can pay it.

How it actually works

A Lightning address is not a Bitcoin primitive. It's not part of the Lightning protocol spec. It's an HTTP convention — and that's what makes it work everywhere.

When your wallet sees alice@ln.bot, it does something mundane: it makes a GET request to https://ln.bot/.well-known/lnurlp/alice. The server responds with JSON describing what payments it accepts — minimum amount, maximum amount, a callback URL. Your wallet posts the amount to the callback. The server mints a fresh Lightning invoice and sends it back. Your wallet pays it.

Two HTTP requests. One Lightning payment. That's the entire protocol.

Sender's wallet                    alice's server (ln.bot)
      │                                      │
      │  GET /.well-known/lnurlp/alice ─────▶│
      │                                      │
      │◀── { callback, min, max } ───────────│
      │                                      │
      │  GET callback?amount=5000 ──────────▶│
      │                                      │
      │◀── { pr: "lnbc50n1..." } ────────────│
      │                                      │
      │  [pays invoice]                      │
      │                                      │

This is part of a spec called LNURL-pay, which has been around since 2019. Phoenix, Strike, Zeus, Breez, Wallet of Satoshi, BlueWallet — if a wallet does Lightning, it almost certainly handles Lightning addresses. Interoperability isn't a concern. It just works.

The part worth appreciating: every incoming payment generates a new invoice. No address reuse, no expiry headaches, no amount locked in advance. The sender picks how much to send, the server creates an invoice for exactly that amount, and payment settles in under a second. The address itself never goes stale.

Where to get one

Most Lightning wallets hand you one when you sign up.

Strike — you@strike.me. Full-featured app with fiat conversion, so incoming sats can land as dollars if you prefer. Requires identity verification.

Wallet of Satoshi — you@walletofsatoshi.com. The low-friction option. Download the app, you have an address.

Cash App — cashtag@cash.app. Already used by millions for peer-to-peer payments. Lightning support means your Cash App balance can receive sats from any Lightning wallet.

ln.bot — you@ln.bot. Built for developers and software. Create a wallet through the API, get a Lightning address instantly. Useful when you need addresses for services, bots, or agents rather than individual humans.

If you already use one of these wallets, you probably already have a Lightning address. Check your receive screen — it's likely there.

Your domain, your address

A Lightning address on someone else's domain means they control the receiving infrastructure. If Wallet of Satoshi changes their terms or goes offline, you@walletofsatoshi.com stops working.

For personal use, that's the same bet you make with Gmail — probably fine. For a business accepting payments, you might want pay@yourbrand.com.

The good news: the LNURL-pay endpoint is just two HTTP routes. Here's a working implementation using ln.bot to handle the Lightning side:

import express from "express";
import { LnBot } from "@lnbot/sdk";

const app = express();
const ln = new LnBot({ apiKey: process.env.LNBOT_API_KEY });

// Step 1: tell the sender's wallet what we accept
app.get("/.well-known/lnurlp/:username", (req, res) => {
  res.json({
    tag: "payRequest",
    callback: `https://yourdomain.com/lnurlp/${req.params.username}/pay`,
    minSendable: 1000,      // 1 sat in millisats
    maxSendable: 100000000, // 100k sats
    metadata: JSON.stringify([["text/plain", `Pay ${req.params.username}`]]),
  });
});

// Step 2: mint a fresh invoice for the requested amount
app.get("/lnurlp/:username/pay", async (req, res) => {
  const sats = Math.floor(Number(req.query.amount) / 1000);
  const invoice = await ln.invoices.create({
    amount: sats,
    memo: `Payment to ${req.params.username}`,
  });
  res.json({ pr: invoice.bolt11, routes: [] });
});

app.listen(3000);

Deploy this behind your domain. Now anyone@yourdomain.com is a working Lightning address. The ln.bot SDK creates invoices and tracks payments — you never run a node or manage channels.

Programmatic addresses

Lightning addresses aren't just for humans with wallets. They're a stable payment endpoint, and anything that needs to receive money can have one.

A tipping bot. A donation jar for an open source project. An AI agent that earns revenue by selling compute. Each one just needs a wallet with an address, and wallets are cheap to create:

const wallet = await ln.wallets.create({ name: "agent-7" });
// wallet.address → "x4k7m2@ln.bot"

for await (const event of ln.events.stream()) {
  if (event.event === "invoice.settled") {
    console.log(`Received ${event.data.amount} sats`);
  }
}

Spin up a hundred wallets, each with its own address, each tracking its own balance. Money flows between services wallet to wallet — no shared billing system, no manual reconciliation.

The privacy tradeoff

Worth understanding before you post your Lightning address everywhere.

When someone pays alice@ln.bot, their wallet talks to ln.bot's server. That server sees the sender's IP address, the payment amount, and the timing. It doesn't know who the sender is (unless their wallet leaks identifying info), but it sees that a payment is coming from a particular IP.

For tipping, commerce, and payments from people you know, this is fine. Roughly the same privacy model as email: the server handles routing but doesn't see the rest of your life.

For high-privacy scenarios, sharing invoices directly over an encrypted channel — Signal, Matrix, whatever you trust — gives better metadata protection. Lightning addresses trade some privacy for convenience. Usually the right call, but it's a choice you should make knowingly.

Where this fits

Bitcoin's blockchain handles settlement — slow, expensive, and deliberately so. Lightning sits on top, handling payments — fast, cheap, final in seconds. Lightning addresses sit on top of that, handling the part nobody wants to think about: making it feel normal to send money to alice@ln.bot.

Each layer exists because the one below it was too hard to use directly. Most people never think about TCP/IP when they send an email. Lightning addresses are trying to reach that same invisibility for payments.

BOLT12 — a newer proposal baked into the Lightning protocol itself — aims to solve the same problem without HTTP servers. It's not widely deployed yet, but it's worth watching. For now, LNURL-pay and Lightning addresses are what every major wallet actually supports.

Someone puts alice@ln.bot in their Twitter bio. A stranger on the other side of the world opens a wallet, types in the address, sends 500 sats. It arrives in under a second. No payment processor took a cut. No bank approved the transaction. Nobody signed up for anything.

That's what paying someone on the internet should have felt like from the start.