Nostr Wallet Connect and the Spending Permission Layer
Nostr Wallet Connect is the permission layer that lets an app request Lightning wallet actions without becoming the wallet, the custodian or the holder of your main Nostr identity.
The wallet is no longer inside the app
The old payment pattern on the web is clumsy. A website wants money, so you leave the page, open a wallet, copy an invoice, confirm a payment, return to the original app and hope the state refreshed. That friction is tolerable for a large purchase. It is miserable for a zap, a tiny creator payment, a game move, a livestream reaction, a paywall unlock or a small merchant flow.
Nostr Wallet Connect solves that problem by separating the surface from the wallet. The app stays the app. The wallet service stays the wallet service. A relay passes encrypted requests and responses between them. The app can ask for a payment, an invoice, a balance or transaction history without touching the private keys or full wallet account directly.
That distinction is why NWC belongs at the center of the Wallets hub. It is not only a developer API. It is a trust boundary normal people need to understand. If the app can spend from your wallet, the useful question is not whether the button is pretty. The useful question is what exactly the connection can do, how much it can spend, how long it lasts, where the request travels and how you can kill it when you stop trusting it.
What NIP-47 actually defines
NIP-47 describes a way for clients to access a remote Lightning wallet through a standardized protocol. The main actors are the client, the person using the client and the wallet service. The wallet service is usually the always-on part: a cloud process, a home server, a Raspberry Pi, Alby Hub, LNbits, ZEUS or another bridge that can talk to the real wallet backend.
The connection uses a `nostr+walletconnect://` URI. That URI includes the wallet service public key, one or more relay URLs, a secret used by the client side of that connection and usually a Lightning address hint. The client and wallet service communicate through encrypted Nostr events. NIP-47 defines an info event, request events, response events and notification events, with methods such as `pay_invoice`, `make_invoice`, `lookup_invoice`, `list_transactions`, `get_balance`, `get_info` and notifications for payments received or sent.
The official NIP is clear about one subtle privacy point: your main Nostr identity key should not be the payment key for the NWC connection. Ideally each app gets its own connection key. That way the wallet service can authorize a specific app without linking every payment interaction to the public identity you use for posting.
The relay is not the wallet. It forwards events. It can observe event kinds and tags, but the request payload is encrypted. That still leaves metadata: timing, involved pubkeys, relay choice and connection patterns can leak shape. NWC is better than pasting wallet credentials into random web apps, but it is not a magic privacy cloak.
Budgets are the grown-up part of the story
Alby Hub makes the most readable version of this idea because it exposes app connections as things you can name, budget, review, expire and disconnect. The Alby guide shows the connection window with a left budget, a renewal interval, last-used information and expiry states. That is exactly the mental model you want: a connected app is not an unlimited wallet owner. It is a limited spender with a visible allowance.
A budget is not a small UI detail. It is the difference between a useful NWC connection and a dangerous one. A livestream app might need tiny zap payments. A podcast app might need recurring boosts. A store might need invoices, not outbound payments. A game might need a tiny allowance. A back office tool might need transaction lookup. Each connection should have a different scope and renewal period.
The mistake is to treat NWC like a universal login. It is closer to giving a valet key to a payment machine. You do not hand every website the same valet key, and you do not leave old keys lying around forever. You create the connection for the job, keep the amount small enough to survive mistakes and revoke old connections when the job is done.
Why wallets are implementing it
NWC is attractive because it lets wallet teams meet users where the action is. Alby Hub can become the wallet service behind the Alby browser extension, mobile apps and Lightning address flows. ZEUS can expose both NWC service and NWC client behavior while staying focused on self-custodial Lightning. LNbits can act as a wallet operating system where one backend funds multiple apps and extensions. Coinos, Boardwalk Cash, Primal Wallet, Cashu.me, Minibits, Rizful and other wallets can make their payment surface available to social and commerce apps without building every client feature themselves.
The NWC site frames the pitch simply: apps get wallet connections and one-click payments while users bring their wallet of choice and the app never takes custody. That phrase is useful, but it needs one caveat: no custody does not mean no risk. A bad app connection can still spend within its permission. A bad wallet service can fail. A bad relay choice can drop requests. A bad UI can hide the one detail you needed to see.
That is why the Wallets hub should keep product profiles and protocol documents side by side. The protocol text tells you what is possible. The product profile tells you what the actual wallet, app or service exposes today.
How to read a NWC screen before approving it
Before you approve an NWC connection, slow down for ten seconds. Which wallet service is behind it? Which app is requesting access? What can the app do: pay invoices, make invoices, read balance, list transactions, receive notifications? What is the budget? Does it renew? When does it expire? Can you revoke it from the wallet side without asking the app?
The relay matters too. If the connection depends on one unreliable relay, requests can vanish. If the relay is public and busy, metadata may be noisy. If the wallet service chooses a specialized relay, you need to know whether it is operated by the wallet team, a third party or you. NIP-47 recommends relays that do not drop events during inactivity and that retain messages long enough to be consumed before becoming stale.
For creators and Crays-style commerce, this matters because money flows will be small, social and frequent. A fan zap, a paid post, a voting game, a room unlock or a micro-checkout cannot feel like a bank transfer every time. NWC makes that smooth. The cost of smoothness is permission hygiene.
Where it can go wrong
The first failure mode is over-permission. A client asks for more methods than it needs, or the wallet UI does not explain those methods in plain language. The second is stale connection sprawl. People create a dozen app connections and forget which one can spend. The third is relay fragility. Requests and responses need to arrive. The fourth is blind trust in the wallet service. If the wallet service controls the connection and talks to the wallet backend, its reliability, key handling and logs matter.
The fifth failure mode is confusing NWC with full account ownership. NWC can let an app request wallet actions; it does not make the app the owner of your Bitcoin, your Nostr account or your invoices. Good apps keep that boundary visible. Bad apps blur it because blurred permission feels easier in the first minute.
The best implementation is therefore boring in the right places: obvious wallet name, obvious app name, visible budget, visible renewal, visible expiry, visible last use, visible supported methods and a clean revoke button. That is not paranoia. That is what lets small payments become normal without turning every tap into a hidden risk.
What to follow next
Start with the official NIP-47 text when you need the event kinds, method names, URI shape and encryption details. Open nwc.dev when you want the product-facing explanation and the current list of wallets, apps and SDKs. Use Alby Hub guides to understand how app connections look in a real wallet service. Use ZEUS and LNbits docs when you want to see NWC inside self-custodial and operator-style Lightning setups.
Then compare products. Alby is strong for account, extension, hub and app-connection UX. ZEUS is strong when you care about self-custody, node control and mobile Lightning depth. LNbits is strong when you want one backend to support many tools. Coinos and Primal show how wallet functions enter everyday product surfaces. Cashu wallets show where ecash changes the custody and privacy conversation.
The through-line is simple: NWC is not a wallet brand. It is the remote-control layer. Use it when the app should ask. Do not use it when the app wants to own.
The connection string is a small authority object
A Nostr Wallet Connect pairing string is not a bookmark. It carries the coordinates for one app-to-wallet relationship: the wallet service public key, relay URLs, a secret for that connection and often a Lightning address hint. Once a client has it, the client can create encrypted wallet requests and sign them as the connection key. The app still does not own the wallet, but it does hold a narrow authority object.
That is the practical leap from older Lightning UX. Copying a Bolt11 invoice asks you to pay once. Keeping a NWC connection lets the app ask again later, within whatever policy the wallet service allows. That is why the official NIP separates the client, user and wallet service, and why it warns against using your main Nostr identity key for the payment connection. The privacy model depends on each app connection being separable.
Read the string like a scoped API key with money behind it. If you paste it into a browser tool, command-line app or social client, you should know which wallet service will answer, which methods are enabled, which relay carries the request, how much can be spent and how quickly you can revoke the connection from the wallet side.
The relay is transport, but transport still shapes trust
NWC moves encrypted request and response events over relays. That keeps the relay out of the wallet business, but it does not make the relay irrelevant. A relay can drop events, disappear, retain messages too briefly, leak timing patterns or sit behind an operator you would rather not use for payment metadata. The payload may be encrypted, yet the shape of the traffic is still part of the payment experience.
The wallet service is the other half of that story. In a self-hosted Alby Hub, LNbits setup or ZEUS wallet service, the always-on component talks to your real Lightning backend. In a hosted service, someone else operates that bridge. In both cases the user-facing client is only asking. The service decides whether the request is allowed, whether the budget remains, whether the invoice is valid and whether a response comes back.
Good wallet products therefore make relay and service status boringly visible. If a payment request fails, the app should not leave you staring at a spinner. It should separate expired connection, exceeded budget, unsupported method, wallet offline, invoice failure and relay timeout. Each failure means something different.
NWC is becoming a wallet market, not one feature
Alby Hub turns NWC into a daily permission surface: add a connection, set permissions, budget, renewal and expiration, then paste or scan the pairing secret. NWC best-practice docs now treat configurable permissions, budgets, unique keys and sub-wallet isolation as wallet-service responsibilities, not optional polish. That is a strong signal: the protocol matured from clever zap plumbing into a real app-permission layer.
ZEUS moved the other direction from a mobile wallet into NWC service behavior. Its v0.12.0 release lets Nostr clients connect to a self-custodial ZEUS wallet, with per-connection budget limits, expiry dates, permissions, custom relays and ecash support for embedded wallets. LNbits also became important because it can act as both an NWC wallet service and an NWC funding source, letting one backend power apps or be powered by another NWC wallet.
That market shape matters for Crays. A creator page, event room, commerce flow or award vote should not hard-code one wallet brand as the payment future. It should ask for a capability: a scoped wallet service that can pay, invoice, expire and revoke cleanly. NWC is useful when it keeps that boundary open enough for many wallets and strict enough that one app cannot quietly become the owner of the user's money path.
Before you paste the secret
Use a tiny ritual. Name the app. Name the wallet service. Check the allowed methods. Set the budget lower than feels convenient. Add an expiration date if the job is temporary. Make one small test payment. Then open the wallet service and revoke the connection before creating the real one. This takes longer the first time and saves confusion later.
The deeper point is cultural: Nostr makes app choice fluid, but money should not become fluid in the wrong way. A replaceable client is liberating only if the wallet permission does not follow every experiment forever. Portable value needs disposable authority.
Sources worth opening
Open these when you want the specification, product documentation or implementation trail behind the article.
- NIP-47: Nostr Wallet Connect
- Nostr Wallet Connect
- Alby Hub app connections
- Alby SDK
- ZEUS documentation
- LNbits documentation
- NWC wallet-service best practices
- Alby NWC developer guide
- ZEUS v0.12.0 NWC service release
- LNbits full NWC support
