NIP-47: Nostr Wallet Connect
Payments needs to be callable without rebuilding the wallet every time
Nostr made tiny public payments feel native through zaps, but a client still needs a safe way to talk to a user's Lightning wallet. Without a standard, every app would need a different wallet integration, every wallet would need app-specific code, and users would be pushed toward copy-paste secrets or custodial shortcuts.
NIP-47 defines Nostr Wallet Connect, usually shortened to NWC. A wallet service publishes what it can do. A client sends encrypted requests such as pay invoice, make invoice, get balance or list transactions. The wallet service answers over the relay. The user's main Nostr identity key is intentionally not used, because payment activity must not be linked to the public social key by default.
That is why NIP-47 matters beyond wallets. It is a general app-to-wallet permission rail. A social client, marketplace, media app, API tool, desktop command palette or service bot can request Lightning actions without becoming the wallet.
Info, request, response, notifications and connection URIs
NIP-47 defines four main event kinds: info event 13194, request 23194, response 23195 and notification event 23197. The info event is replaceable and tells clients which capabilities the wallet service supports. Requests and responses are encrypted. Notifications allow wallet events such as payment received or payment sent.
The command set has grown with real usage. It includes flows such as pay_invoice, multi_pay_invoice, make_invoice, lookup_invoice, list_transactions, get_balance, get_info and hold-invoice support. Recent history added metadata and states to some invoice and transaction responses, because wallet UX needs more than paid or failed.
Encryption negotiation also matters. NIP-47 has had backward compatibility with NIP-04, but recent work added an encryption tag to negotiate upgrading to NIP-44. That is the healthy direction: payment commands need modern encrypted payloads and clear capability discovery.
From first wallet-connect proposal to a real payment ecosystem
NIP-47 was introduced in March 2023 by Semisol. The file history is busy because NWC escaped the markdown and became a real ecosystem. Early changes added error handling, feedback, connection-string fixes and Lightning address parameters. Later changes added notifications, key-usage clarifications, encryption negotiation, transaction states, invoice metadata, deep links and hold invoices.
The Alby history tells the adoption story. The older getAlby/nostr-wallet-connect repository says it is no longer actively maintained because the team focuses on Alby Hub, but the same README explains the original purpose: control a Lightning node or wallet over Nostr and connect apps such as Damus or Amethyst to a node. The newer awesome-nwc repository lists wallets, apps, relays, developer libraries, communities and protocols built around NWC.
That breadth is rare among NIPs. NIP-47 is not only a protocol file. It is one of the standards with visible wallet products, SDKs, test tools, special-purpose relays and user-facing apps around it.
NWC lives where app UX meets wallet policy
The implementation ecosystem is unusually concrete. Alby Hub, Alby Go, Alby Browser Extension, LNbits, Zeus, Primal Wallet, Bitvora, Cashu-connected experiments and several SDKs appear in the awesome-nwc inventory. There are NWC-specific relays such as Alby NWC Relay, NWCLay and wallet-relay, plus developer tools such as NWC Playground, NWC HTTP API and language libraries.
A client implementing NIP-47 needs to treat connection strings like wallet permissions, not like decorative settings. The connection may allow paying invoices, reading balance, listing transactions or receiving notifications. A wallet service needs to surface permission scope, per-app keys and revocation. Unique keys per connection are part of the standard's privacy intent.
The best NWC flows feel boring: scan or paste a connection, see supported capabilities, send a test request, pay an invoice, receive a response and revoke the connection later. The dangerous flows are silent: background payments with unclear limits, reused keys across apps, missing invoice metadata or vague error states.
Convenience can hide wallet authority
NWC makes payments easy to embed. That is also the risk. A connection string can carry enough authority to spend money or expose wallet information, depending on wallet policy. Users need clear permission screens, app names, spending limits where available and simple revocation.
The privacy boundary is also fragile. The NIP avoids using the user's main Nostr identity key, but apps, relays, invoice metadata and wallet services can still create linkages. Good NWC software needs to minimize key reuse and avoid turning payment behavior into public social metadata.
Read NIP-47 in the wild
NIP-47 is Nostr Wallet Connect. It lets an app ask a wallet service for payment actions without becoming the wallet itself.
The payment risk is permissions. A connection string, budget, method list and relay path decide how much value can move. Before approving, you need to know what the app can do, how to revoke it and which wallet actually controls funds.
What changes when you actually use it
For you, NIP-47: Nostr Wallet Connect is felt at the moment value moves or appears to move. The interface may show a zap, offer, wallet connection, token, invoice or result, but the source terms kind 23194, kind 23195, kind 23197, kind 23196, kind 9734, draft decide what can actually be proven. Read the money path before the visual reward path.
What changes for builders and operators
For builders, NIP-47: Nostr Wallet Connect means separating money truth from social display. Budgets, invoices, mints, wallet services, receipts and settlement need their own status language. A delightful payment animation is harmless only after custody, limits and revocation are legible.
What the official file makes concrete
The official file is organized around Rationale, Terms, Theory of Operation, Events, Info Event, Request and Response Events, Notification Events, Error codes. Inspect kind 23194, kind 23195, kind 23197, kind 23196, kind 9734, draft, pay_invoice, response because these are the pieces most likely to surface as product behavior. Read it beside NIP-04, NIP-44, NIP-57 before treating it as isolated.
NIP-47: Nostr Wallet Connect needs sharper warnings than a normal social feature. Custody, invoices, receipts, budgets, mints and settlement determine whether money really moved.
Where it breaks
The failure mode in NIP-47: Nostr Wallet Connect is believing the social signal more than the payment proof. A zap can be visible while settlement is incomplete, a wallet connection can outlive trust, a mint can fail, and a listing can look professional without escrow or reputation.
Where this appears outside the markdown
In the ecosystem, NIP-47: Nostr Wallet Connect sits near wallets, Lightning, Cashu, offers, receipts, jobs, goals or marketplaces. These features are exciting because value becomes visible inside social context, but they are also unforgiving. A page about value has to separate the social object from the financial fact before the design turns trust into decoration.
The nearby-standard trap
The nearby-standard trap in NIP-47: Nostr Wallet Connect is calling every money-adjacent event a payment. Zaps, wallet connections, Cashu proofs, nutzaps, offers, orders, goals and data jobs each prove different things. Read NIP-04, NIP-44, NIP-57 before a UI turns a signal into an accounting claim.
Language that keeps the feature honest
Good product copy for NIP-47: Nostr Wallet Connect names the money state. It separates request, invoice, payment, receipt, token, mint, budget, listing, order and settlement. That is how a delightful wallet or marketplace surface stays honest.
What this page does not promise
NIP-47: Nostr Wallet Connect does not turn a social signal into settled money by itself. A zap, wallet connection, listing, token, receipt or job request can be displayed beautifully while custody, settlement, refund, invoice expiry or mint risk remain unresolved. Read NIP-04, NIP-44, NIP-57 before trusting any value flow that hides who controls funds or which proof actually exists.
Read it as a field test
Start NIP-47: Nostr Wallet Connect with the money state, not the animation. Identify whether kind 23194, kind 23195, kind 23197, kind 23196, kind 9734, draft represent a request, permission, invoice, token, receipt or listing. Then read the nearby standards and source links so custody, settlement, budget and proof are not collapsed into one cheerful payment label.
Where the standard earns trust
The source links give you places to test the interpretation in public: getAlby/nostr-wallet-connect, getAlby/awesome-nwc, Alby NWC developer guide, nwc.dev. Use those links to move from the spec to live libraries, mirrors, pull requests, guides or products.
Official NIP-47 source is the anchor for exact wording, and NIP-47 commit history shows how that wording moved over time. The strongest secondary clues here are getAlby/nostr-wallet-connect, getAlby/awesome-nwc, Alby NWC developer guide. Treat this evidence chain as part of the article, not as footnotes. A NIP page becomes useful when you can move from claim to source to working behavior without guessing.
Keep the chain visible for NIP-47: Nostr Wallet Connect: first the human promise, then kind 23194, kind 23195, kind 23197, kind 23196, kind 9734, draft, then the implementation record, then the real-world failure case. That order keeps NIP-47 useful without turning it into marketing copy or protocol trivia.
Three questions to carry forward
- What is being proven: a request, invoice, payment, receipt, token, listing, wallet permission, mint promise or job result?
- Who can spend, revoke, refund, censor or lose the funds if the service disappears?
- Does the product separate social visibility from financial settlement before you trust the flow?
What to verify before you rely on it
- Find
kind 23194,kind 23195,kind 23197,kind 23196,kind 9734in the official file and check where the UI exposes the same concept. - Read NIP-04, NIP-44, NIP-57 as context before treating NIP-47 as a complete product story.
- Open at least one implementation, mirror, pull request or library source from the source links before trusting that the idea is mature.
- Test the unhappy path: missing relays, stale metadata, invalid signatures, blocked events, expired state, revoked permissions or unavailable media.
- Write the user-facing copy in plain language. If a standard changes authority, privacy, money, moderation or recovery, say that before the click.
Direct sources
Use these sources for NIP-47: Nostr Wallet Connect in that order: Official NIP-47 source for the current wording; NIP-47 commit history for the change record; getAlby/nostr-wallet-connect, getAlby/awesome-nwc, Alby NWC developer guide for public context. The article gives you the consequence in plain language, but the source trail is where exact fields, status notes, unresolved debates and implementation proof stay checkable.
