Lightning Address Server
This is not a wallet UI and not the Lightning Address protocol itself. It is a small server pattern: expose a Lightning Address or LNURL-pay endpoint, use NWC as the invoice backend, and keep the wallet/node somewhere else.
Start with the exact object
The name `Lightning Address Server` is easy to misread because it can sound like a general protocol page. In this hub, it refers to a specific entry in the Nostr Wallet Connect ecosystem list. The entry links to a Replit project named `NWC-Lightning-Address-Server` and describes it as a tool to request Lightning invoices from your wallet via NWC.
That is not the same thing as the whole Lightning Address standard. It is also not the same thing as Alby Lite or Thor, even though those newer projects live in the same design space. The useful distinction is this: Lightning Address is the address format and LNURL-pay flow; NWC is the wallet-control transport; a Lightning Address server is the web service that sits between the two.
When checked on June 14, 2026, the public Replit page at `replit.com/@ReneAaron/NWC-Lightning-Address-Server` returned 404, and the direct ZIP endpoint returned 403. That does not prove the project never existed, but it does mean a reader cannot currently inspect the original code from the public listing in the normal way.
So the honest article is not a sales pitch for a vanished demo. It is a reader guide for what the entry meant, what you can verify today, how the pattern works, and what to test before trusting any server that turns an NWC connection string into public receive endpoints.
Why this pattern exists
A Lightning payment normally needs an invoice. That is fine for a checkout screen, but awkward when you want a durable address people can remember. Lightning Address solves that by making a Bitcoin receive handle look like an email address, such as `name@example.com`, while the wallet behind the scenes still receives a fresh BOLT11 invoice for each payment.
A server is needed because the sender's wallet must ask the receiver's domain for payment instructions. With LUD-16, the address maps to `https://example.com/.well-known/lnurlp/name`. That endpoint returns LNURL-pay metadata, including a callback URL, min and max amounts, and enough information for the sender's wallet to request a fresh invoice.
The older Replit idea was to make that bridge small and approachable. Instead of running a full public node API, you could give the server a Nostr Wallet Connect secret and let it ask the remote wallet service for invoices. The server becomes the public address layer; the wallet service remains the place that actually creates and settles invoices.
That can be attractive for builders who already have Alby Hub, Rizful, Coinos, LNbits or another NWC-capable wallet service. The public server only needs to speak HTTP, LNURL-pay and NWC. It does not need a local `lnd.conf`, a Core Lightning RPC socket, node TLS certificates or a public Tor service for invoice creation.
What the original listing can still prove
The strongest current evidence for the old project is the `awesome-nwc` list itself. In the Developer Tools & Libraries section, it places `Lightning Address Server` immediately after L402 Nginx and links it to Rene Aaron's Replit project. The description is narrow: request Lightning invoices from your wallet via NWC.
That sentence is enough to classify the entry. It is not a wallet because it does not hold spendable balances by itself. It is not a signer because it is not there to sign Nostr events for a user. It is not a relay. It is a developer-side server pattern for invoice creation through a wallet connection.
The missing public Replit code changes how you should use the page. You can keep the entry as historical ecosystem coverage, but you should not copy commands from it, deploy it unseen, or assume the security model. If a Replit owner later restores the page, the first task is to inspect its dependencies, secrets, routes and NWC methods before calling it usable.
For now, the page should help you understand the class of tool. The closest live code references are Alby Lite, which is a Deno/Postgres Lightning address server powered by NWC, and Thor, which is a Rust server that exposes Lightning Address endpoints and uses configured NWC URIs to create invoices.
The Lightning Address flow
From the sender's point of view, a Lightning Address is simple. A wallet receives `alice@example.com`, translates it into a well-known URL, fetches a JSON document, shows the sender allowed amounts and optional comment fields, then calls the returned callback with an amount in millisatoshis.
The server's first responsibility is the well-known endpoint. For a user named `alice`, it normally responds at `/.well-known/lnurlp/alice` with `tag: payRequest`, a `callback`, `minSendable`, `maxSendable`, and `metadata`. The metadata should include either `text/identifier` or related identity information so wallets can bind the invoice to the visible address.
The second responsibility is the callback. When the sender chooses an amount, the wallet calls the callback. The server must create or fetch a fresh invoice and return it as `pr`, usually with an empty `routes` array. That invoice should commit to the metadata according to the LNURL-pay rules, so the payer is not paying a generic invoice with unrelated description data.
If the server gets any of those details wrong, the failure may look small but matter in practice. Amount units are millisatoshis, not sats. Metadata hashing is part of the invoice verification story. Callback URLs must match the public domain. Min and max values shape wallet behavior. Small protocol mistakes turn into wallet incompatibility very quickly.
Where NWC enters
Nostr Wallet Connect, described in NIP-47, gives an app a way to communicate with a remote Lightning wallet service through Nostr relays. A connection URI typically contains the wallet service public key, relay URLs and a secret. The client encrypts requests, posts them to the relay, and the wallet service responds with the result.
For a Lightning Address server, the important method is invoice creation. The server receives an LNURL-pay callback and uses the configured NWC connection to ask the wallet service for a new invoice. The server then returns that invoice to the payer's wallet as the LNURL-pay response.
That is powerful because the address server does not need direct node credentials. But it is not magic. The NWC URI is still sensitive access material. Depending on wallet implementation and permissions, it may be able to create invoices, receive payment notifications, query transactions or do more than an address server strictly needs.
The safest mental model is that an NWC URI is a scoped wallet API key carried through Nostr relays. Store it as a secret, keep it out of logs, give it the smallest permissions possible, rotate it when in doubt, and never paste a production URI into a public demo, issue, screenshot or client-side page.
NIP-57 changes the server
A basic Lightning Address server only needs LNURL-pay. A Nostr zap-capable server has more work. NIP-57 defines zap requests and zap receipts so Nostr clients can show that a payment was intentionally associated with a profile or event, not just sent to a generic Lightning address.
For zaps, the LNURL-pay metadata can advertise `allowsNostr: true` and a `nostrPubkey`. The sender's client sends a signed zap request event to the callback as a query parameter. The server should validate that request, create an invoice whose description is tied to the zap request, and later publish a zap receipt when payment settles.
That last step is the hard part for a tiny demo. To publish a zap receipt, the server needs to know that the invoice settled and must sign a Nostr event. That often requires payment notifications from the wallet service, stored invoice records, preimage handling, a zapper private key and relay publishing logic.
Alby Lite is useful here because it shows what a fuller NWC-powered server can look like: it validates zap requests, stores invoices, listens for NWC `payment_received` notifications, marks invoices settled and signs zap receipts with a configured NIP-57 private key. A one-file demo may not do all of that.
What Alby Lite adds
Alby Lite is not the original Replit entry, but it is a strong modern reference for the same family of problem. Alby's March 4, 2025 announcement describes it as an open-source Lightning address server that can generate one or many Lightning addresses on your own domain, with built-in Nostr NIP-05 identity verification and support for receiving zaps.
The repository README says the API creates a user with `POST /users`. The request includes a `connectionSecret`, a `nostrPubkey` and an optional `username`; the response returns a Lightning address. The server is built with Deno, Hono, Drizzle and Postgres, and expects environment variables for `BASE_URL`, `DATABASE_URL`, `ENCRYPTION_KEY` and `NOSTR_NIP57_PRIVATE_KEY`.
The source confirms the shape. `/.well-known/lnurlp/:username` returns LNURL-pay metadata and can advertise zap support if a NIP-57 public key exists. `/lnurlp/:username/callback` validates the optional zap request, uses `@getalby/sdk` NWC client `makeInvoice`, stores invoice data, and returns the BOLT11 invoice plus a verification URL.
That extra machinery matters if you want a production-like address service. You need a database, encrypted NWC secrets, migrations, invoice records, payment notification subscriptions and a NIP-05 endpoint if the address is also meant to serve as an identity proof. Alby Lite makes the hidden work visible.
What Thor shows
Thor is another useful reference because it is smaller and easier to reason about. The GitHub README calls it a self-hosted Lightning Address server written in Rust and powered by NWC. Its promise is clear: custom Lightning addresses on your own domain without running LND or Core Lightning.
The config example contains a server domain, listen address, log directory and a list of users. Each user has one or more NWC URIs. The comment in the example recommends read-only NWC URIs where possible and says every user must have at least one NWC URI or the server exits.
The source exposes `/.well-known/lnurlp/{username}` and `/lnurlp/{username}`. The first endpoint returns LUD-06 metadata. The second computes the metadata hash, asks an `NwcInvoiceCreator` to call `make_invoice`, and returns the invoice as `pr`. If multiple NWC entries exist, Thor shuffles and tries up to three invoice creators.
Thor is not a drop-in replacement for every zap-capable scenario. Its visible source focuses on LUD-06/LUD-16 invoice creation and does not show the same NIP-05 or zap receipt machinery as Alby Lite. But it is a clean example of the core NWC-backed Lightning Address architecture.
The danger is public receive infrastructure
A receive-only server can sound low risk because it does not send payments. That is too simple. A public Lightning Address server still handles wallet access material, domain identity, invoices, comments, payer data, optional zap requests, logs and sometimes Nostr event signing.
If an attacker can read the NWC secret, they may be able to impersonate the server to the wallet service within that connection's permissions. If an attacker can write the database, they may replace encrypted secrets, claim usernames, alter NIP-05 mappings or break invoice verification. If an attacker can alter DNS or reverse-proxy routing, payments can be redirected or made unreliable.
The public endpoint also invites spam. A callback can be hammered with invoice requests. Every invoice may touch the wallet service, Nostr relays and a database. Without rate limits, caching decisions, request size limits and logs that avoid secrets, the server becomes an easy target for resource exhaustion.
Treat the deployment like payment infrastructure even if the app looks small. Use a private secret store, lock down Postgres, keep the server behind a maintained reverse proxy, enable TLS, cap request sizes, rate-limit callbacks, monitor wallet errors and keep enough invoice history to debug disputes without logging sensitive connection strings.
Domain control is part of the product
Lightning Address depends on a domain. If the address is `alice@example.com`, the payer's wallet trusts the HTTPS response from `example.com`. That means the domain, DNS provider, TLS certificate, CDN and reverse proxy are all part of the payment path.
NIP-05 adds another identity layer. A server can expose `/.well-known/nostr.json?name=alice` and map `alice@example.com` to a Nostr public key. That is useful because the same human-readable name can point to both a payment endpoint and a Nostr identity. It is also sensitive because a wrong mapping can impersonate a user in clients that display NIP-05 badges.
If you combine Lightning Address and NIP-05, make the ownership model explicit. Can users choose their own usernames? Can admins reassign names? What happens when a user is deleted? Are old invoices still valid? Are NIP-05 responses cached by clients? Can a username collision silently redirect zaps?
Before using any server in this class, test the domain from the outside. Fetch the well-known LNURL endpoint, fetch the NIP-05 JSON if present, confirm HTTPS, confirm callback hostnames, confirm redirects, and check how the server behaves behind Cloudflare, Nginx, Fly, Vercel or any other edge layer.
NWC permissions need boring checks
The cleanest NWC connection for a Lightning Address server should only let the server create invoices and receive the notifications it needs. It should not be a broad spending connection. If the connected wallet cannot scope permissions tightly, the risk profile changes.
NIP-47 defines the communication pattern and wallet-service role, but real wallet services differ. Some support `make_invoice`, some support `lookup_invoice`, some support payment notifications, some support budgets and expirations, and some expose optional behavior differently. A server that works with one wallet service may fail with another.
That matters for user-facing receive addresses. If the wallet service cannot send reliable `payment_received` notifications, a zap receipt flow may never complete. If it can make invoices but not return useful metadata, verification endpoints may be weaker. If it drops relay connections, callbacks may time out.
Your practical test should be specific: create an NWC URI with the exact wallet service, connect it to a staging server, request invoices at minimum and maximum amounts, pay one invoice, leave one unpaid, send a zap request if supported, restart the server, rotate the secret, and confirm the behavior rather than assuming all NWC wallets act alike.
Reader checks before using it
If you find a restored copy of the original Replit demo, start with source inspection. Look for server-side-only storage of the NWC secret, no client-side exposure, clear environment variables, dependency versions, package lockfiles, request validation and explicit LNURL-pay response fields.
Then check protocol correctness. Fetch `/.well-known/lnurlp/{name}` and confirm `tag`, `callback`, `minSendable`, `maxSendable`, `metadata` and optional `allowsNostr`. Call the callback with valid and invalid amounts. Confirm it returns a fresh invoice, not a reused invoice, and that the invoice description or description hash matches the metadata flow.
If the server claims zap support, check NIP-57 end to end. Send a valid zap request, send an invalid one, pay the valid invoice, and verify that a zap receipt is published to the requested relays. A server that returns invoices but never publishes receipts may still receive money, but Nostr clients will not have the normal zap proof.
Finally check operations. Does the app survive wallet-service downtime? Does it leak secrets in logs? Does it have any authentication on user creation? Can someone claim arbitrary usernames? Does it store old invoices? Can you back up and restore the database? Can you migrate users to a new wallet URI without breaking their public address?
What not to assume
Do not assume `Lightning Address Server` means non-custodial by default. The server may be non-custodial with respect to funds if it only asks a user's wallet to create receive invoices, but the connected wallet service may itself be custodial or self-custodial. The custody answer lives behind the NWC connection.
Do not assume it is private. A Lightning Address is public by design. The domain can observe requests. The server can see invoice requests, comments, payer data, zap request payloads and timing. Nostr relays can observe encrypted NWC traffic metadata. A payment address is convenient, but it is not a privacy shield.
Do not assume one server can safely serve everyone. A single operator hosting many users needs abuse controls, username policies, secret isolation, database backups, deletion rules, payment support procedures and a plan for compromised NWC URIs. A personal server is a different risk profile from a public multi-tenant service.
Do not assume the old Replit link is enough due diligence. Replit demos are useful for learning, but production payment infrastructure needs maintained dependencies, secrets outside the source tree, observable failures, HTTPS, rate limits and a clear update path.
Where it belongs in the app map
The entry belongs in Developer Tools & Libraries because it is infrastructure for builders. A normal end user would not open this page to send a payment. A builder opens it because they want to give an app, business, product, profile or user account a reusable Lightning receive address backed by an NWC wallet.
It also touches Finance & Payment Tools, but the primary surface is not checkout UX. It is the server layer behind payment UX. If a product later wraps this pattern in an admin dashboard, subscription model or hosted service, that product may deserve another category. The old Replit listing remains a builder tool.
The Nostr connection is specific and important. NWC is the wallet-control protocol. NIP-57 can turn receives into zaps. NIP-05 can connect the same domain name to a Nostr public key. Relays carry the encrypted wallet messages and, for zaps, the public receipts.
That mix is why the page is worth keeping even though the original link is stale. It shows a practical bridge between three things readers often see separately: Lightning Address for human-readable receive handles, Nostr Wallet Connect for wallet access, and Nostr zaps for social payment proofs.
Better current starting points
If your goal is to study a maintained implementation, start with Alby Lite and Thor rather than the unavailable Replit page. Alby Lite is broader and closer to a multi-user service with database-backed user creation, encrypted NWC secrets, NIP-05 mapping and zap receipt publishing. Thor is smaller and closer to a personal domain server with static config.
If your goal is to understand the protocol, start even lower. Read LUD-16 for how an email-like identifier maps to the well-known endpoint. Read LUD-06 for the payRequest callback and metadata rules. Read NIP-47 for the NWC connection and wallet-service model. Read NIP-57 if your server needs to advertise and complete zaps.
If your goal is a production address on your own domain, compare whether you need NWC at all. Some wallets and servers can connect directly to a node or use hosted Lightning Address infrastructure. NWC is attractive when your wallet service already supports it and you do not want to expose node APIs, but it is not the only way to receive to a domain.
A good deployment path is conservative: run one username on a test domain, connect a limited wallet, pay small amounts, test zaps only after basic LNURL-pay works, monitor logs, rotate the NWC secret once, restore from backup once, and only then decide whether the server is fit for real public use.
The practical close
Lightning Address Server is best read as an early ecosystem breadcrumb for a useful pattern: ask a wallet over NWC to create invoices for a reusable Lightning Address. The old Replit implementation is not currently inspectable from the public link, so the responsible stance is cautious.
The pattern itself is real. Alby Lite and Thor show that an HTTP server can expose LNURL-pay endpoints, map usernames to wallet connections, request invoices over NWC and, with more machinery, support Nostr identity and zap receipts. That is enough to matter for builders who want human-readable receive addresses without running a public node API.
The risk is also real. You are putting NWC secrets, domain identity, invoice creation and sometimes Nostr signing behind public endpoints. A small server can become payment infrastructure the moment you publish an address people rely on.
Use this page as a map, not a blind install guide. Confirm the exact code you deploy, understand which wallet service controls the money, keep permissions narrow, protect the domain, test wallet behavior, and treat the address as something users may trust long after your first demo works.
Useful Nostr context
These pages help connect Lightning Address behavior with zaps, wallets and server-side access patterns.
- NIP-57 zaps: The Nostr-side zap model that often uses Lightning Address style payment metadata.
- L402 Nginx: A nearby server-side Lightning access-control pattern.
- Wallets: Wallet and custody context for payment endpoints.
- Commerce: Payment product context for readers comparing checkout and access flows.
Sources worth opening
Open the original ecosystem list first to see why the entry exists, then read the Lightning Address/LNURL specs, NWC/NIP-47, and the current Alby Lite and Thor implementations that show the pattern in working code.
- awesome-nwc raw README entry list
- awesome-nwc GitHub repository
- Lightning Address website
- Lightning Address GitHub repository
- LUD-16 static internet identifiers
- LUD-06 payRequest base spec
- LNURL LUD repository
- NIP-47 Nostr Wallet Connect
- NIP-57 Lightning Zaps
- NIP-05 mapping Nostr keys to DNS identifiers
- Nostr Wallet Connect docs introduction
- Alby developer guide to NWC
- Alby Lite announcement
- Alby Lite GitHub repository
- Alby Lite README
- Alby Lite environment example
- Alby Lite LNURL-pay source
- Alby Lite well-known LNURL source
- Alby Lite NIP-05 source
- Alby Lite users API source
- Alby Lite NWC notification pool
- Alby Lite database source
- Alby Lite GitHub API metadata
- Thor GitHub repository
- Thor README
- Thor config example
- Thor HTTP server source
- Thor NWC invoice creator source
- Thor Cargo manifest
- Thor GitHub API metadata
- Thor Stacker News discussion
- Alby Hub website
- RFC 8615 well-known URIs
