163 / 691NWC

Nostr Wallet Connect

Authorized app requests to a Lightning wallet

Nostr Wallet Connect links an app to a wallet through encrypted requests; the wallet service determines the scope of access.

Nostr Wallet Connect (NWC) is the NIP-47 protocol for remotely controlling a Lightning wallet through Nostr relays. Relays carry messages, not the bitcoins themselves; both a personal node and a custodial service can use the protocol.

The client app sends a request, the wallet service verifies it and calls its payment interface. NWC itself does not determine who holds the bitcoin keys. Connections to a personal node and a custodial wallet can therefore use the same protocol while differing in trust and recovery options. [NWC — NIP-47: Core protocol] [NWC — Project overview]

The connection URI contains the service’s public key, a relay and secret: the client connection’s private key. It is not the wallet seed, but enables signing authorized requests. Its QR code or copy can give another app access. Separate keys for individual connections reduce linkage between them. [NWC — NIP-47: Core protocol]

The public info event announces service capabilities; get_info returns methods available to the particular connection. The core includes pay_invoice, make_invoice, lookup_invoice, get_balance and get_info. History, keysend and notifications belong to optional extensions. Check support and permission separately: a method name is not universal payment consent. [NWC — NIP-47: Core protocol] [NWC — Optional specifications] [NWC-02 — Notifications]

Info uses kind 13194, requests 23194 and responses 23195. The p tag identifies the counterparty; the response’s e tag references the request. Clients check the signature, expected service key, request association and result_type. Merely receiving an event from a relay does not prove command execution. [NWC — NIP-47: Core protocol]

NIP-47 amounts and fees are in msat; 1000 msat equals one satoshi. Confusing units changes the amount a thousandfold. Successful pay_invoice returns a preimage; a failure response provides error. Creating an invoice with make_invoice does not mean it was paid; lookup_invoice can query its state. [NWC — NIP-47: Core protocol]

Current negotiation prefers nip44_v2; older nip04 remains for compatibility, and a missing encryption tag means the legacy mode. NIP-44 alone does not provide forward secrecy. Relays can see event kinds, tags, connection keys and timing. The user’s main identity key should not be used for an NWC connection. [NWC — NIP-47: Core protocol] [Nostr — NIP-44: Encrypted payloads]

NWC requests and responses use ephemeral events. An unavailable relay or offline service can lose a message, while a client can also lose only the response to an already completed payment. After a timeout, first check the state through lookup_invoice or the wallet. Do not treat silence as certain failure or a new request as an automatically safe retry. [NWC — NIP-47: Core protocol]

The service can constrain a connection by methods, budget or expiry and revoke its key. Enforcement belongs at the service, not merely in the client’s interface. Deleting a connection in an app may leave wallet-side permission intact. Revocation blocks future use but does not reverse an already completed payment. [NWC — NIP-47: Core protocol]

For the clearest picture, read this entry together with Nostr, Lightning Network, BOLT 11, Bitcoin wallet, Private Key, Satoshi. The reverse links also lead from Nostr, BOLT 11.

DOC · 001NWC — NIP-47: Core protocolSpecificationDOC · 002NWC — Project overviewPrimaryDOC · 003NWC — Optional specificationsSpecificationDOC · 004Nostr — NIP-44: Encrypted payloadsSpecificationDOC · 005NWC-02 — NotificationsSpecification
Source-first · No investment advice