Apps

Nostr Wallet Auth

Nostr Wallet Auth is not a wallet and not a finished replacement for NIP-47. It is a connection-initiation pattern for NWC: the app creates the secret and request, the wallet approves it, and normal NWC begins after the wallet creates the connection.

Apps The product layer Clients, signers, publishing tools, wallets and useful experiments.

Directory Signers Login

Apps25 min readNWA wallet-connection onboarding, client-created NWC secrets, mobile wallet approval, NIP-47 compatibility, budgets, relays and wallet-service confirmation flows

Nostr Wallet Auth

The quick readNostr Wallet Auth, often shortened to NWA, is best read as a wallet-connection onboarding flow for Nostr Wallet Connect. Normal NWC starts with a wallet service creating a `nostr+walletconnect://` URI that contains the client secret, then the user copies or scans that URI into an app. NWA flips the beginning: the app creates a secret and a `nostr+walletauth://` URI, the user opens that URI in a wallet, the wallet shows the requested methods and limits, and the wallet approves or creates the actual NWC connection. The older Mutiny proposal appeared as a NIP-67 pull request with a kind 33194 confirmation event. The newer Alby/Bitcoin Connect path is documented in the Alby JS SDK and in an open NIP-47 client-created-secret pull request: it keeps the client secret local, uses fields such as `request_methods`, `notification_types`, `max_amount`, `budget_renewal`, `expires_at`, `isolated` and `metadata`, and lets the wallet return a NIP-47 connection. The important caution is standards status. NWA is deployed and useful, but readers should verify the exact wallet, SDK version, URI fields, relay, approval screen, command set, budget, revocation behavior and whether the wallet supports the `create_connection` flow.

What Nostr Wallet Auth really is

Nostr Wallet Auth is a connection-initiation flow for Nostr Wallet Connect. Its purpose is narrow but important: it helps an app ask a wallet to create a scoped NWC connection without making the user copy a completed wallet secret into the app. The app starts the dance, the wallet approves it, and the resulting connection still uses NWC.

That means NWA is not a wallet, not a social client, not a Lightning backend and not a separate payment network. It sits before NWC. Once the wallet has approved the connection, the normal NIP-47 ideas take over: wallet service keys, relays, encrypted request events, response events, supported methods, budgets and revocation.

This distinction is the whole article. If a map lists Nostr Wallet Auth under protocols, the useful reader question is not where to download it. The useful question is how it changes the first minute of connecting a wallet to an app, and what new risks appear when the app creates the secret first.

Why the name is confusing

The name sounds like login. It is not login in the ordinary account sense. Nostr Wallet Auth is about authorizing an app to access wallet capabilities. A successful flow can lead to payment authority, invoice creation, balance reads, transaction reads or notifications depending on what the wallet approves.

It also sounds like a finished NIP. Historically, Nostr Wallet Auth appeared in a pull request as NIP-67 from Ben Carman and the Mutiny world. That pull request proposed a `nostr+walletauth://` URI and a kind 33194 confirmation event. It was a real proposal and had real implementation history, but it did not become the current accepted NIP-67 in the main NIPs index.

The current public usage is closer to a NWC client-created-secret flow. Alby JS SDK exposes `NWAClient`; the Alby guide calls NWA an alternative flow for Lightning apps to initialize NWC connections to mobile-first or self-custodial wallets; and the open NIP-47 pull request describes both HTTP and Nostr flows where the client-generated secret stays local. The reader should keep both histories in view.

The normal NWC starting point

NIP-47 describes Nostr Wallet Connect as a way for clients to access a remote Lightning wallet through standardized encrypted messages over Nostr relays. A wallet service publishes an info event, clients send kind 23194 request events, wallet services send kind 23195 responses, and optional notification events can report wallet activity.

In the classic connection flow, the wallet service generates a `nostr+walletconnect://` URI. That URI includes the wallet service public key, one or more relays and a client secret. The user copies, scans or deep-links that finished connection into the app that wants wallet access. The app stores it and later uses it to sign and encrypt wallet requests.

That flow works, but it creates a rough onboarding moment. A user may be asked to handle a powerful string without understanding what it grants. A mobile wallet may have to export a QR code that a browser app can scan. A web app may have no good way to know whether the wallet supports the methods it needs before the user tries. NWA exists because this starting point can feel backwards.

What NWA flips

NWA flips the start of the connection. Instead of the wallet creating the secret and handing it to the app, the app creates a local secret and a public key derived from it. The app then presents a `nostr+walletauth://` URI through a QR code, deep link, copy button or wallet-specific link. The user opens that URI inside a wallet.

The wallet parses the URI, sees which relays the app is listening on, which methods the app wants, what budget or expiry it requested and what name or icon it presents. If the user approves, the wallet creates the NWC connection and publishes or returns enough information for the app to use its locally generated secret with the wallet service.

The important benefit is that the client secret does not need to be shown to the user or pasted across apps. The app can generate it locally and keep it in its own storage. The wallet only needs the app public key and the requested permission envelope. That is a cleaner shape for mobile-first wallets, web apps and cross-device connection flows.

The old Mutiny NIP-67 proposal

The earliest clear NWA proposal most readers will find is the Mutiny-era NIP-67 pull request. Its rationale was blunt: NWC is useful, but copy-pasting a wallet connection URI is a UX hurdle, and users may handle sensitive information they do not understand. It also noted that apps and wallets may disagree about supported commands, leading to silent failures or confusing setup.

That proposal used a `nostr+walletauth://` URI containing the app public key, relay, a random secret identifier, required commands, optional commands, budget and optional identity. After approval, the wallet would send a kind 33194 event back to the app. The event would identify the app, include approved commands and optionally provide a relay and Lightning address.

The proposal is useful history because it explains the product need well. It is also a warning against oversimplifying the standards story. If a page says NWA is simply NIP-67, the reader should check what the software actually implements. Modern Alby SDK code no longer depends on that exact event kind model for its documented NWA path.

The newer client-created-secret direction

The more current path is represented by the open NIP-47 client-created-secret pull request and the Alby JS SDK. The pull request says the original NWC flow is less secure and prone to user error because the secret must be copied into the client. It then describes alternatives where the client generates its own secret and only coordinates public keys with the wallet service.

That pull request describes two one-click-style connection flows. The HTTP confirmation page is for publicly accessible wallet services such as Alby Hub or CoinOS. The Nostr flow uses a `nostr+walletauth://` authorization URI for mobile-based or self-hosted Lightning wallets. The pull request says the Nostr flow is similar to NWA but avoids adding a new event type.

The practical reading is that NWA became less of a separate NIP and more of a connection mode inside the NWC ecosystem. Builders should therefore cite the exact implementation they use: older Mutiny-style NWA, Alby SDK `NWAClient`, Bitcoin Connect's NWC provider options, an Alby Hub confirmation page or a wallet-specific deep link.

The URI fields that matter

Alby SDK's `NWAClient.ts` is the clearest current implementation source. It builds a `nostr+walletauth://` URI from an app public key and query parameters. Required fields include relay URLs and requested NWC methods. Optional fields include app name, icon, return URL, notification types, maximum amount, budget renewal period, expiry, isolated mode and metadata.

Those names are not just developer trivia. `request_methods` tells the wallet what the app wants to do. `notification_types` tells it whether the app wants wallet events. `max_amount` and `budget_renewal` describe a spending envelope. `expires_at` limits lifetime. `isolated` can request an isolated app connection or sub-wallet where supported. `metadata` lets the app provide extra context.

A wallet should show the important parts to the user before approval. A connection screen that hides requested methods and budget is not a good NWA experience. The flow is valuable because it can move permission review into the wallet. If the wallet treats the URI like a blind accept button, the protocol shape is doing less work than it should.

What the app does

The app begins by creating or loading an app secret key. From that secret it derives an app public key. The Alby example creates an `NWAClient` with relay URLs and request methods, then exposes `connectionUri` for the user to scan or open in a wallet. The same client can subscribe on the relays while waiting for the wallet to create the connection.

This is different from simply embedding a static NWC URL in a page. The app is asking for a new connection that is specific to this app and this permission request. If the app wants `get_info` only, it should request `get_info` only. If it wants `pay_invoice`, balance reads and payment notifications, it should name those and justify them in the product flow.

After the wallet completes the setup, the app can construct an `NWCClient` using its own secret, the approved relay set and the wallet public key. In the Alby implementation, the NWA subscribe path listens for a NIP-47 info event tagged to the app public key, then creates the NWC client and tries to fetch `get_info`.

What the wallet does

The wallet side parses the NWA URI. Alby SDK's accept example asks for an existing NWC URL that supports `create_connection`, parses the `nostr+walletauth://` URL, and then calls `createConnection` with the app public key, name, request methods, notification types, max amount, budget renewal, expiry, isolated flag and metadata.

That example is deliberately incomplete in one important way: it says the user would choose to accept the connection. The actual confirmation page, wallet UI, policy checks and database writes are wallet-specific. A production wallet must decide how to display the app name and icon, how to validate requested permissions and how to store or revoke the connection.

This means wallet support is not one yes-or-no feature. A wallet can parse an NWA URI badly, support only some fields, ignore budgets, fail on notifications, hide metadata or create connections that are hard to revoke. When you test NWA, test the wallet's behavior, not only whether a URI opens.

How NWC begins after approval

After approval, NWA should leave you with a normal NWC path. The app has its client secret. The wallet service has a wallet key for this connection. The relay or relays are known. The app can request the info event, learn supported methods and then send encrypted NIP-47 requests. From that point onward, wallet safety depends on NWC permissions and wallet enforcement.

This is why NWA should not be described as a payment method. It is the setup path that creates or authorizes the payment method. The actual payment request is still `pay_invoice`, `pay_keysend`, `make_invoice`, `lookup_invoice`, `list_transactions`, `get_balance`, `get_info` or another NWC method supported by the wallet and SDK.

If a connection fails after approval, the problem may be in the relay, the info event, the wallet service, method support, encryption mode, app secret storage or wallet policy. A useful app should report those failures separately. A vague wallet could not connect message leaves users with no way to know whether they denied permission, lost relay connectivity or hit unsupported commands.

Budgets and commands are the safety core

NWA is only safer than copy-paste NWC if it improves the permission boundary. The app should request the smallest useful method set. A read-only dashboard may need `get_info` and perhaps `get_balance`. A payment app may need `pay_invoice`. A store may need `make_invoice` and `lookup_invoice`. A recurring payment app may need a budget, expiry and clear renewal period.

The Alby and Bitcoin Connect examples show realistic fields: request methods, notification types, max amount, budget renewal, expiry, return URL and metadata. Those fields give the app a way to ask precisely. They also give the wallet a way to say no, downgrade or ask the user for a smaller approval.

The reader should care about units. NWC and SDK code often use millisatoshis for budgets and balances. User interfaces often show sats or fiat estimates. If the wallet and app disagree about units, a budget can be dangerously misunderstood. A good approval screen should make the human-readable amount and period unmistakable.

Why mobile wallets care

Mobile wallets are the natural home for NWA. A web app can display a QR code or deep link. The user can open the link in a phone wallet. The wallet can show the app name, requested methods and spending limit. The app can keep its own secret and wait for the wallet to complete the NWC connection.

That is much nicer than asking a user to copy a long `nostr+walletconnect://` string from a phone wallet into a browser tab, or to scan a wallet-generated QR code from one device with another. It also helps self-custodial wallets because the wallet can remain the place where the user reviews access, rather than exporting a full capability first.

The mobile story still has limits. Phones sleep, relays fail, deep links can be hijacked, app links can open the wrong wallet, and background wallet services may not answer like an always-on server. NWA improves setup. It does not turn a phone into a reliable backend unless the wallet and operating system are designed for that role.

Where Bitcoin Connect fits

Bitcoin Connect is a UI layer for connecting Bitcoin and Lightning wallets to web apps. Its NWA demo configures the NWC provider with authorization URL options such as request methods, payment notifications, max amount, weekly budget renewal, expiry, optional isolated mode, return URL and metadata. That makes it a useful example of how NWA fields become product UI.

For a builder, the lesson is that NWA should not live only in a low-level SDK. A user needs a button, QR code, deep link, wallet chooser, pending state, success state and failure state. Bitcoin Connect exists in that product layer, while `NWAClient` provides the lower-level connection mechanics.

For a reader, the same split is useful. If an app says it supports NWA through Bitcoin Connect, check what fields it passes and what wallet it targets. A polished button can still request too much. A plain QR code can be safer if it asks for one method and a short expiry.

What is implemented today

The public footprint checked on June 13, 2026 shows NWA inside the Alby JavaScript SDK, with `NWAClient.ts`, tests and examples. The SDK repository was active in 2026, and its NWC guide had been updated recently. Bitcoin Connect also has NWA-related demo configuration. The Awesome NWC list includes Nostr Wallet Auth under protocols as a way to initiate NWC connections from the app instead of from NWC wallets.

The open NIP-47 pull request says the client-created-secret flows are implemented in Alby JS SDK and Bitcoin Connect, and mentions Alby Go, Alby Hub, CoinOS and PayWithFlash around the HTTP and Nostr flows. Treat that as implementation context, not as a guarantee that every production wallet behaves the same today.

Mutiny is the historical reference. Mutiny's blog wrote about one-step wallet connect with Nostr Wallet Auth in 2023, and external documentation described it as a simpler connection process. Mutiny's product status changed later, so use that material for history and design motivation rather than as the current implementation target.

Security boundaries to keep visible

The first boundary is the client secret. NWA is attractive because the secret is generated locally by the app and does not need to be pasted by the user. That only helps if the app stores it like a credential. It should not enter logs, analytics, URLs sent to third parties, screenshots, support dumps or plaintext backups.

The second boundary is app identity. NWA URIs can include names, icons, return URLs and metadata, but those fields can lie. A wallet should not treat a name string as proof of identity. Users need to see a trustworthy domain or wallet-specific verification path where available. Otherwise a malicious site can make a connection request that looks friendly.

The third boundary is wallet policy. A wallet must enforce methods, budgets, expiry, notifications and revocation after approval. The app can request a limited connection, but the wallet is the final guard. If the wallet ignores limits or cannot revoke a connection, the setup UX is improved but the money risk remains.

What developers should test

Developers should test the whole lifecycle, not only URI generation. Generate an NWA URI, parse it in the wallet path, show a confirmation page, approve it, create the NWC connection, receive the info event, call `get_info`, then try only the methods that were approved. Store the resulting connection and prove it survives a page reload or app restart.

Then test the negative paths. What happens if the wallet does not support `create_connection`? What if no relay connects? What if the user rejects the request? What if the wallet supports `get_info` but not `pay_invoice`? What if the budget is exhausted, the expiry passes, the return URL is missing or the metadata is malformed?

Finally test security posture. Confirm that the secret never leaves the app except where intended. Confirm the app does not expose it in a query string. Confirm logs redact NWA and NWC URIs. Confirm revocation stops requests. Confirm multiple app connections do not share wallet keys unless the wallet intentionally accepts that privacy tradeoff.

What users should check

Users should treat NWA approval like granting a payment permission. Before approving, check the app name, app domain or origin, requested commands, spending limit, renewal period, expiry and wallet account. If a wallet shows only a generic approve button, use a tiny budget or skip the connection.

Start with a harmless method if possible. A connection that only requests `get_info` is easier to test than a connection with payment authority. If the app needs payment authority, use a small budget and short expiry first. Make one tiny payment, check history, then revoke the connection and confirm the app no longer works.

Do not assume NWA means non-custodial. NWA can be used with self-custodial wallets, hosted wallets, mobile wallets or provider-backed wallet services. The connection flow tells you how the app gets permission, not who controls the funds. Ask the custody question separately.

The current standard status

NIP-47 itself is a current draft optional NIP. It defines NWC events, connection URIs, commands, encryption expectations and metadata. Nostr Wallet Auth, as a phrase, is more complicated. The old NIP-67 pull request remains an open proposal, and the newer client-created-secret work is an open NIP-47 pull request.

That means public documentation should avoid pretending that NWA is a universally finalized standard with one canonical behavior. It is better to say exactly which flow is being used: Mutiny-style NWA, Alby SDK `NWAClient`, NIP-47 client-created-secret Nostr flow, HTTP confirmation page, Bitcoin Connect provider flow or a wallet-specific interpretation.

This does not make NWA irrelevant. Many useful interoperability patterns exist before every line is merged into the main NIPs repository. It does mean production apps should pin SDK versions, document supported wallets and expose fallback paths for users whose wallet does not understand the NWA URI.

The bottom line

Nostr Wallet Auth exists because normal NWC setup can be backwards for users. A wallet-generated connection string is powerful, awkward and easy to mishandle. NWA lets the app ask for a connection in a structured way, while the wallet remains the place where the user approves methods, budgets and lifetime.

The clean version is simple: the app creates a local secret, publishes or displays a `nostr+walletauth://` request, the wallet parses it, the user approves it, the wallet creates a scoped NWC connection, and the app then talks to the wallet over normal NIP-47. The messy version is the standards history, implementation differences and product UI around that flow.

Use NWA as an onboarding improvement, not as a magic safety layer. It is good when it reduces secret handling, improves mobile wallet approval and makes permissions visible. It is weak when it hides requested methods, skips identity checks, uses vague budgets or leaves users without revocation. The promise is real, but the proof is in the wallet screen and the connection test.

Sources worth opening

Start with the Alby NWC JS SDK guide, `NWAClient.ts`, the NWA examples, NIP-47, the current NIP-47 client-created-secret pull request and the older Mutiny NIP-67 pull request. Then compare Bitcoin Connect, Awesome NWC, Mutiny's historical write-up and wallet-service docs before treating NWA as production infrastructure.