Nostr Wallet Connect (NIP-47)

Nostr Wallet Connect (NWC), defined in NIP-47, is a protocol that lets a Nostr or Lightning application send commands to a remote wallet service using end-to-end encrypted direct messages carried over a Nostr relay. It decouples the app that wants to spend or receive from the wallet that holds the keys, so a web client can trigger payments without ever touching your seed. In practice it has become the standard plumbing for wiring Lightning payments into the Nostr ecosystem and beyond.

How it works

The user obtains a connection URI from their wallet, shared as a QR code or pasted string, containing a dedicated secret key and the wallet service's public key. The client and wallet service then communicate by encrypting requests and responses to each other and publishing them as events on a relay both sides can reach. NWC defines specific event kinds: 13194 for the wallet's advertised capabilities (the info event), 23194 for client requests, 23195 for wallet responses, and 23197 for notifications. Encryption moved from the deprecated NIP-04 scheme to NIP-44, with the supported scheme advertised in an encryption tag. The elegant part is that the relay is just a dumb pipe: it sees ciphertext between two ephemeral keys and learns nothing about amounts, invoices, or identities.

What it enables

Through NWC a client can pay invoices, generate invoices, check balance, list transactions, and send keysend payments, all scoped to a connection that uses a unique key rather than the user's main identity. Wallet services typically let you attach a budget to each connection — say, a few thousand sats per day for a social client — so a compromised or misbehaving app can only spend up to its allowance. Because each app gets its own connection, one can be revoked without rotating your real Nostr key or disturbing any other app. The same mechanism powers one-tap zaps, subscription-style recurring payments, point-of-sale setups, and machine-to-machine payments where no human is present to approve each invoice.

The sovereignty calculus

NWC is an architecture, not a custody model — the sovereignty you get depends on what sits at the wallet end of the connection. Point it at a custodial Lightning service and you have convenience with counterparty risk; point it at a wallet service running against your own Lightning node at home and you have something genuinely powerful: any app, anywhere, spending from a node whose keys never left your hardware. That second configuration is the one that fits the self-custody ethos — the app layer stays disposable and untrusted while the money layer stays yours. It is worth being deliberate here, because the convenience of NWC makes it easy to quietly re-centralize onto someone else's node.

It helps to see what NWC replaced. Earlier attempts at app-to-wallet plumbing meant handing an app your node's admin credentials or a broadly scoped access token — effectively giving every client the keys to the treasury and hoping it behaved. NWC's design inverts that: capability discovery tells the client exactly which commands a wallet supports, per-connection keys and budgets enforce least privilege, and the relay transport means neither side needs a public IP, port forwarding, or a direct network path to the other. A wallet service behind a home NAT can serve a phone on cellular data with nothing but a shared relay between them. That NAT-piercing property, borrowed for free from Nostr's architecture, is a genuinely practical win for anyone whose Lightning node lives on a shelf at home rather than in a datacenter.

NWC pairs naturally with Nostr Zaps for one-tap tipping and complements browser-based signing via NIP-07 — one protocol delegates payments, the other delegates signatures, and both exist so your root keys never touch a web page. D-Central highlights NWC as a self-custodial way to wire payments into apps without surrendering wallet control.