CraysZap Land
Zap Land is best understood as a small wallet doorway: it creates an NWC string and a Lightning address, then lets Nostr apps treat that new wallet as a zap-ready payment backend.
A wallet that starts with one click
Zap Land is deliberately small on the surface. The public app at zap.land greets the reader with a direct promise: create a Lightning wallet with one click. Press the button and the page creates an NWC connection string, a Lightning address and a live wallet panel. There is no long onboarding path, no bank-style account form and no attempt to make the wallet feel like a full consumer finance brand.
That simplicity is the point. Zap Land is trying to make the first payment surface appear before you have learned the whole vocabulary of Nostr Wallet Connect, LNURL, zaps, wallet service pubkeys and enclave-backed custody. The page gives you an NWC string that can be pasted into compatible apps, then shows a Lightning address that can be added to a Nostr profile for receiving zaps.
The important thing is not that the app is short. The important thing is what the short interface hides. Behind the button is a wallet-service architecture built around Nostr events, NWC commands, a zap.land LNURL server, a wallet service called nwc-enclaved and a client helper package that creates the wallet relationship. Zap Land is a friendly doorway into that stack.
The two things you must keep
The live Zap Land wallet page centers on two outputs: the NWC connection string and the Lightning address. The connection string is the sensitive one. The app tells you to save it because it is the only way to access the wallet. That line should be read literally. If the connection string is lost, the page does not offer a normal password reset flow. If it leaks, someone else may be able to command the wallet within the permissions the service accepts.
The Lightning address is the public receiving surface. It lets someone send a Lightning payment or zap to an address that looks like an email address. In Zap Land's design, that address is derived from Nostr keys and hosted under zap.land, so the address can route back to the wallet service and ask it to create an invoice. That is what makes the app feel immediate: the wallet can be controlled through NWC and discovered through a Lightning address.
Treat those two strings differently. The LN address can be public, shared and added to a profile. The NWC string should be handled like wallet access. It belongs in a trusted wallet client or signer-style storage, not in screenshots, chat messages, public notes or random test pages.
What the open-source wallet page does
The zap-land-wallet repository is a React and Chakra UI app. It uses createWallet from nwc-enclaved-utils, stores the returned wallet details in the browser, and then uses the Alby SDK's NWC client to talk to the wallet. The interface displays the NWC connection string, the Lightning address, the balance, the maximum balance and a QR-friendly top-up invoice.
The code also shows the product assumptions. It polls balance every few seconds, lists transactions, creates a tiny invoice for topping up, watches the last transaction to detect payment and warns you when the selected service is marked as a developer instance. That warning is not decorative. A developer instance is for testing, not for meaningful balances.
The suggested next step is also revealing. The wallet page tells you to use the NWC string in apps such as Alby Go, Damus or Amethyst and to add the Lightning address to a Nostr profile. Zap Land is not trying to become the whole wallet experience. It creates the wallet relationship and then expects other Nostr apps to use it.
The zap.land address is not just a label
The zap-land server repository provides the LNURL and zap-address side. Its README describes the project as a Lightning Network LUD-16 address provider with Nostr Zap support for NWC wallets. In practical terms, it lets a wallet service pubkey and a client pubkey become a Lightning address under zap.land.
The server code expects the wallet-service npub in the hostname and the client npub in the LNURL path. When a wallet client or zapper asks for the address metadata, the server fetches wallet-service information from Nostr, reads the relays and payment limits announced by that service, and returns an LNURL pay response. That response can advertise NIP-57 zap support, a Nostr pubkey for zap receipts and min and max sendable amounts.
That means the address is not a static forwarding label. It is a live bridge between Nostr identity and Lightning invoice creation. The address tells a sender where to ask for an invoice, and the server uses Nostr-published service information to know how that request should reach the wallet service.
Why make_invoice_for matters
Zap Land depends on a method named make_invoice_for. Normal NWC make_invoice lets a wallet service create an invoice for its own wallet. Zap Land's zap-address flow needs something more specific: a third-party request must be able to ask the wallet service for an invoice on behalf of a target Nostr pubkey. That is what make_invoice_for is designed to do.
The zap-land README is explicit that this is a newer method and that, at the time of the project documentation, nwc-enclaved is the service that supports it. That detail matters for readers who expect every NWC wallet to behave the same way. Zap Land's receiving flow is not just generic NWC with a nice domain. It relies on wallet-service behavior that must be present for the address to work.
The upside is powerful. A new wallet can get a Lightning address tied to a Nostr pubkey without asking you to run a Lightning node manually or configure a separate LNURL provider. The limit is interoperability. If another wallet service does not support the same method or the same zap semantics, the zap.land-style address cannot simply be assumed to work.
NWC is the control plane
Nostr Wallet Connect is the control plane in this system. The app gets an NWC string. A compatible client uses that string to send encrypted wallet commands through Nostr relays. The wallet service receives commands such as get_info, get_balance, make_invoice, list_transactions or pay_invoice and sends encrypted replies back through Nostr.
The nwc-enclaved code follows the same shape. It processes request events, checks expiration, decrypts with NIP-04 or NIP-44 depending on the message, validates the method and parameters, and sends a response event. It also supports notification events so clients can react to wallet changes instead of only polling. This is wallet infrastructure speaking Nostr event language.
Relays are not the money custodian, but they are still part of the payment path. If the relay connection fails, a wallet command can fail even if the wallet backend is alive. That is one reason Zap Land should be tested with small amounts first. A working demo button does not prove that every relay, client, wallet service and payment path will be reliable in daily use.
nwc-enclaved is the wallet service underneath
The wallet service behind the project is nwc-enclaved, another Nostr.Band repository. Its README describes it as a custodial NWC wallet for trusted execution environments. The goal is to let app and agent developers provide zappable Lightning wallets without forcing every reader through a signup, KYC flow or manual node setup.
The service is still custodial. It can reduce some operator risk with an enclave model, but do not confuse that with holding coins in a personal Lightning node. The service manages wallet state, invoices, balances and payments. You control access through an NWC string, but the service is the thing actually connected to the backend.
The backend named in the nwc-enclaved documentation is phoenixd, a Lightning daemon built for server-side use. The service also has internal accounting around wallet balances, fees, invoice creation, outgoing payments, channel capacity and maximum balance. Zap Land is therefore a simple app on top of a real wallet-service stack, not a standalone local wallet.
The TEE promise and its limits
The phrase trusted execution environment needs careful reading. nwc-enclaved is designed for deployments where sensitive wallet logic can run inside an environment such as AWS Nitro Enclaves, with attestation data that lets clients check what kind of code and environment they are talking to. The related NEC-01 document describes Nostr events for publishing enclave attestations.
That model can reduce a specific fear: the service operator casually reading secrets, changing code invisibly or using ordinary server access to steal balances. Attestation gives clients something to verify, and reproducible builds can make that verification more meaningful. This is more serious than a vague claim that a hosted wallet is secure.
It still does not remove trust. A client must actually verify the attestation, understand production versus development or debug tags, check expiration, decide which PCR values are acceptable and judge the surrounding service. The nwc-enclaved README also says the project is under active development and should be used at your own risk. Enclaves narrow the trust question; they do not make it disappear.
Fees, limits and tiny-wallet behavior
nwc-enclaved is designed around small, app-facing wallets. Its constants and README describe maximum balances, invoice limits, daily wallet fees, payment fees and Lightning liquidity fees. The documented fee model includes a small daily wallet fee on non-empty wallets, a small payment fee and Phoenix-related payment and liquidity costs. Those numbers may change over time, but the point is stable: this is not a free unlimited bank account.
The limits are part of the safety model. A one-click wallet is useful because it lowers friction, but lower friction would be dangerous if new wallets could quietly accumulate large balances. Zap Land's own interface shows a maximum balance, and the service announcement can publish minSendable, maxSendable and maxBalance tags for clients to read.
A good reader habit is to treat Zap Land as a spending and receiving wallet for small zaps, not as long-term storage. Top it up with a small amount, connect it to one or two clients, test receiving and sending, then decide whether the convenience is worth the custodial and experimental tradeoffs.
Zaps need more than an invoice
A Lightning invoice can move sats, but a Nostr zap needs more context. NIP-57 describes zap requests and zap receipts so a payment can be tied to a pubkey, note, event address, relays and an amount. Zap Land's server accepts optional zap request data and the nwc-enclaved code validates important parts of that request before creating the invoice.
The validation logic is not just bureaucratic. It checks that the zap request is signed, that the payment amount matches, that the request has the expected p tag, that relay information exists and that optional event or address tags are shaped correctly. After payment, the service can publish a zap receipt with the bolt11 invoice, description and preimage information.
This is why Zap Land belongs in the wallet conversation rather than only in a Lightning address directory. It is not merely returning invoices. It is trying to make a new wallet instantly usable in the Nostr zap flow, including the public social proof that a zap happened.
What can go wrong
The first risk is ordinary custodial risk. The wallet service holds operational power. If the service is down, misconfigured, compromised, abandoned or legally pressured, your payment experience can break. A TEE design may reduce some kinds of operator abuse, but it does not turn a hosted service into self-custody.
The second risk is connection-string risk. The NWC string is wallet access. If it is pasted into the wrong page, stored in an unsafe note, backed up in a visible screenshot or sent over chat, the wallet may be exposed. Zap Land's low-friction setup makes this easier to forget because the whole wallet appears so quickly.
The third risk is ecosystem mismatch. Zap Land's address flow relies on make_invoice_for and on service information published through Nostr. Some NWC clients may support the ordinary methods but not understand the zap.land assumptions. Some wallets may support NWC but not the same receiving flow. Small tests are the right way to find those edges.
How to test it without fooling yourself
Start with no meaningful balance. Create a Zap Land wallet, save the NWC string somewhere private, copy the Lightning address and send a tiny payment from another wallet. Confirm whether the balance changes, whether the payment appears in transaction history and whether the page still works after refresh.
Then connect the NWC string to a client that supports NWC. Try get_balance and a tiny invoice before trying a real zap flow. If the app offers permission labels or budgets, use them. Watch whether the client stores the NWC string safely and whether it makes clear when the wallet is connected.
Finally test failure. Close the page, reopen it, try the Lightning address from another wallet, check what happens when the relay or service is slow, and read any developer-instance warning before adding value. The goal is not to prove that the happy path works once. The goal is to learn which parts of the stack you are trusting.
Who should care about Zap Land
Zap Land is useful for Nostr builders who want to understand how wallet onboarding might feel when the wallet appears before the lecture. It shows a path where you get an NWC string and a Lightning address quickly, then connect that wallet to social clients, zap flows or agent-style apps.
It is also useful for readers who want to see where Nostr payments are heading. The interesting part is not the single button. It is the combination of NWC, LNURL, NIP-57, wallet-service announcements, enclave attestations and small-balance Lightning infrastructure. Those pieces together suggest a future where many apps can create or request scoped wallet access without becoming full wallet companies.
The best use is still modest. Use Zap Land to learn, test and send small zaps. Use it to understand why connection strings matter and why wallet services need clear trust language. For larger balances, long-term savings or production funds, choose infrastructure whose custody, recovery, liquidity, audits, support and failure modes you are prepared to live with.
Sources worth opening
Open the live app, both Zap Land repositories, nwc-enclaved, nwc-enclaved-utils, the NEC attestation document and the Nostr and Lightning specifications together. The useful details are split across the wallet interface, LNURL server and wallet-service code.
- Zap Land live app
- Zap Land official SVG logo
- nostrband/zap-land GitHub repository
- zap-land README
- zap-land LNURL server source
- zap-land NWC client source
- zap-land server package file
- zap-land latest commit history
- nostrband/zap-land-wallet GitHub repository
- zap-land-wallet React app source
- zap-land-wallet package file
- zap-land-wallet latest commit history
- nostrband/nwc-enclaved GitHub repository
- nwc-enclaved README
- nwc-enclaved constants
- nwc-enclaved NWC server
- nwc-enclaved NWC base processor
- nwc-enclaved wallet manager
- nwc-enclaved wallet accounting
- nwc-enclaved service announcement
- nwc-enclaved Nostr module
- nwc-enclaved latest commit history
- nostrband/nwc-enclaved-utils GitHub repository
- nwc-enclaved-utils README
- nwc-enclaved-utils package file
- nwc-enclaved-utils latest commit history
- nostrband/necs GitHub repository
- NEC-01 AWS Nitro Enclave attestations
- Nostr Wallet Connect official site
- NWC documentation introduction
- NWC reference API overview
- NWC get_balance method
- NWC make_invoice method
- NWC list_transactions method
- NIP-47 Nostr Wallet Connect
- NIP-57 Lightning zaps
- NIP-04 encrypted direct messages
- NIP-44 versioned encryption
- NIP-65 relay list metadata
- LNURL LUD-06 payRequest base spec
- LNURL LUD-16 Lightning address
- LNURL LUD-18 payer identity
- Phoenixd documentation
- Alby JavaScript SDK
- Alby SDK NWC documentation
- Alby Go wallet app
- Damus app site
- Amethyst Android app repository
- AWS Nitro Enclaves documentation
- Nostr.Band site
