Nostr Wallet Connect (NWC)

What Is Nostr Wallet Connect?

Nostr Wallet Connect (NWC) is an open protocol that allows applications to remotely control a user's Lightning wallet through the Nostr messaging network. Defined in NIP-47, NWC lets any Nostr-compatible app request payments, generate invoices, and check balances without the app needing to run its own Lightning node or custody user funds.

The core idea is separation of concerns: the app handles the user experience, while the wallet handles the money. A social media client can offer one-tap tipping. A podcast app can stream sats to creators. A marketplace can accept Lightning payments. None of these apps need to integrate directly with a Lightning node because NWC provides a standardized communication layer between app and wallet.

NWC was originally developed by the Alby team and has become the de facto standard for Lightning integration within the Nostr ecosystem. Its design builds on Nostr's existing relay infrastructure and cryptographic primitives, making it straightforward for any application already connected to Nostr relays to add payment capabilities.

How It Works

NWC relies on three components: a wallet service (the user's Lightning wallet), a client (the app requesting payments), and one or more Nostr relays that carry encrypted messages between them.

Connection Setup

The process begins when a user wants to connect an app to their wallet. The wallet generates a connection URI containing everything the app needs to communicate:

nostr+walletconnect://<wallet_pubkey>?relay=wss://relay.example.com&secret=<client_secret_key>

This URI contains three pieces of information:

• The wallet service's Nostr public key, which the app uses to address messages to the correct wallet
• A relay URL where both the wallet and app will exchange messages
• A secret key generated specifically for this connection, which the app uses to sign and encrypt its requests

The user typically scans a QR code or pastes this URI into the app. Each connection gets its own keypair, so revoking one app's access does not affect others.

Request and Response Flow

Once connected, the app and wallet communicate through encrypted Nostr events. NWC defines two primary event kinds:

• Kind 23194: request events sent from the app to the wallet service
• Kind 23195: response events sent from the wallet service back to the app

A typical payment flow works as follows:

1. The user taps "zap" in a Nostr client to tip a content creator
2. The app creates a kind 23194 event containing an encrypted JSON payload with the method (e.g., pay_invoice) and parameters (the BOLT-11 invoice to pay)
3. The app publishes this event to the designated Nostr relay
4. The wallet service, which subscribes to events tagged with its public key on that relay, receives the request
5. The wallet decrypts the payload, validates the request against spending limits, and executes the Lightning payment
6. The wallet publishes a kind 23195 response event containing the payment result (such as the preimage as proof of payment) or an error

All communication is encrypted using NIP-04 (AES-256-CBC with a shared secret derived from ECDH). The relay transports the messages but cannot read their contents. The protocol is asynchronous: if the wallet is temporarily offline, requests queue on the relay until the wallet reconnects.

Supported Methods

NWC defines a set of JSON-RPC-style methods that apps can invoke:

Wallet services advertise which methods they support through the get_info response, allowing apps to adapt their UI to the wallet's capabilities.

Permission Model

NWC's security design centers on per-connection isolation and configurable spending controls. Each app connection receives its own keypair, so compromising one connection does not expose others.

Wallet services typically offer several layers of control:

• Spending limits: daily, weekly, or monthly budgets per connection (e.g., 10,000 sats per day). When exceeded, the wallet returns a QUOTA_EXCEEDED error.
• Per-payment approval: the wallet can prompt the user for manual confirmation on every payment request
• Automatic payments below a threshold: payments under a configured amount (e.g., 100 sats) execute automatically, while larger amounts require approval
• Method restrictions: connections can be limited to read-only access (get_balance, list_transactions) or granted full payment capabilities
• Instant revocation: users can delete a connection at any time, immediately cutting off that app's access

This model is analogous to OAuth scopes in web APIs: each connection gets precisely the permissions it needs, nothing more.

Use Cases

Zapping on Nostr

The most widespread use of NWC is "zapping": sending Lightning micropayments to content creators on Nostr. Defined in NIP-57, zaps are recorded as Nostr events so other users can see that a post or profile received tips. NWC provides the payment mechanism that makes zaps possible from any client.

Before NWC, Nostr clients had to either integrate their own Lightning wallets or rely on custodial services. NWC lets users connect their preferred wallet (including self-custodial options) and zap directly from the client interface.

Streaming Payments

Podcast apps like Fountain use NWC to stream sats to creators in real time while listeners consume content. This value-for-value model replaces advertising revenue with direct listener-to-creator payments, enabled by Lightning's low fees and NWC's ability to automate small payments without repeated user approval.

Subscriptions and Recurring Payments

With pre-authorized spending limits, NWC enables subscription-style payments. A paid newsletter or content platform can automatically charge a user's wallet on a schedule, provided the payments stay within the approved budget. This is similar to how LNURL handles recurring payment flows, but with the added benefit of working over Nostr's relay infrastructure rather than requiring a dedicated HTTP server.

In-App and Automated Payments

Any application built on Nostr can use NWC to add payment capabilities without building Lightning infrastructure. Marketplaces can process payments, games can handle in-app purchases, and bots can distribute rewards, all through standardized NWC requests to the user's own wallet.

NWC vs. LNURL and Lightning Address

NWC, LNURL, and Lightning Address all simplify Lightning payments, but they solve different problems:

The key distinction: NWC is a wallet control protocol (a remote control for your wallet), while LNURL and Lightning Address are payment request protocols (ways to ask someone to pay you). They are complementary. A wallet could expose a Lightning Address for receiving payments and support NWC for sending them.

Wallet Support

Several Lightning wallets and services implement NWC as either a wallet service (provider) or a client:

• Alby Hub: the primary NWC implementation, offering a self-custodial Lightning node with built-in NWC support and a web-based management interface
• Phoenix: ACINQ's mobile Lightning wallet with NWC capabilities
• LNbits: a Lightning account management system with NWC available through an extension
• Coinos: a custodial wallet supporting NWC connections

On the client side, most major Nostr apps support NWC for zapping: Damus (iOS), Amethyst (Android), Primal (cross-platform), and numerous web clients. The protocol has also been adopted by podcast apps like Fountain and music platforms like Wavlake for streaming payments.

Risks and Considerations

Relay Trust and Metadata Exposure

While NWC encrypts message contents so relays cannot read payment details, relays can observe metadata: which public keys communicate, when messages are sent, and how frequently. Using a dedicated NWC relay (like Alby's) reduces exposure to third-party observation but introduces a single point of failure. If the relay goes offline, communication between app and wallet stalls until the relay recovers or the user configures an alternative.

Key Security

The connection secret stored on the client device is the key to controlling the wallet (within the configured limits). If the device is compromised, an attacker could send payment requests. Per-connection keypairs limit the blast radius: compromising one app's connection does not affect other connections. Spending limits further cap potential losses. Users should treat NWC connection URIs like passwords and never share them publicly.

Spending Limit Enforcement

Spending limits are enforced by the wallet service software, not by cryptographic proofs. Users must trust that their wallet implementation correctly enforces the configured budgets. A bug in the wallet service could theoretically allow payments beyond the set limits. Using well-audited, open-source wallet implementations reduces this risk.

Encryption Limitations

NWC currently uses NIP-04 encryption (AES-256-CBC), which lacks authenticated encryption. The Nostr community has developed NIP-44 (XChaCha20-Poly1305 with authenticated encryption) as a more secure replacement, and migration is underway. Until the transition is complete, the encryption layer is functional but not at the standard of modern cryptographic best practices.

Why It Matters

NWC addresses a fundamental challenge in Lightning adoption: how to let apps interact with Lightning payments without either building complex node infrastructure or requiring users to trust a custodian. By creating a standardized, encrypted communication layer between apps and wallets, NWC allows any developer to add Lightning payments to their application with minimal effort. For a deeper look at how Nostr and Bitcoin payments intersect, see the research on Nostr, Bitcoin, and identity-based payments.

For Lightning-native platforms like Spark, NWC represents a useful interoperability standard. As more apps adopt NWC, users gain the flexibility to connect their preferred wallet to any compatible application, reinforcing the self-custodial model that makes Lightning payments powerful. The protocol complements other Lightning standards like BOLT12 offers and LNURL by focusing on the wallet-to-app communication layer rather than the payment request format itself.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.