Nostr Wallet Connect: How NWC Enables Remote Lightning Payments From Any App

Lightning wallets have historically been isolated. Each app that wants to send or receive payments needs its own wallet, its own balance, and its own channel management. This fragmentation creates friction: Nostr clients, podcasting apps, tipping widgets, and merchant tools all need direct access to a Lightning node to move sats. Nostr Wallet Connect (NWC) solves this by letting any application trigger Lightning payments through a remote wallet, using encrypted messages over Nostr relays.

Defined in NIP-47, NWC turns any Nostr-compatible app into a payment-capable app without requiring it to run a node, manage channels, or hold funds. The wallet stays where the user controls it. The app just asks it to pay.

Why Remote Wallet Access Matters

Before NWC, connecting an app to a Lightning wallet meant one of two things: either the app ran its own custodial wallet (introducing counterparty risk), or the user installed a browser extension like WebLN that could only work inside a desktop browser tab. Neither approach scales to the range of environments where payments are useful: mobile apps, IoT devices, server-side automation, and AI agents.

NWC decouples the payment trigger from the payment executor. An app running on a phone, a Raspberry Pi, or a cloud server can send a payment request to a wallet running anywhere else. The connection is persistent, budgeted, and revocable. This is the same architectural pattern that makes APIs powerful: separation of concerns between the caller and the service.

How NWC Works: Protocol Architecture

NWC uses three components: a wallet service (the user's Lightning wallet), a client app (any application that needs to trigger payments), and one or more Nostr relays that route encrypted messages between them. All communication happens through Nostr events, with content encrypted so relays cannot read payment details.

Event Kinds

NIP-47 defines three core event kinds and one extension kind for communication:

The info event (kind 13194) contains a space-separated list of methods the wallet supports, along with tags indicating supported encryption schemes. Apps read this event to discover wallet capabilities before sending requests.

Connection Pairing

Pairing happens through a URI that the wallet generates and the app consumes. The format follows a specific structure:

nostr+walletconnect://<wallet-pubkey>?relay=<wss-url>&secret=<hex-string>

The URI contains three components: the wallet service's Nostr public key (32-byte hex), a relay URL where both parties will exchange messages, and a randomly generated 32-byte secret that becomes the client app's private key for this specific connection. The user typically scans a QR code or pastes this string into the app. Once paired, both sides subscribe to events on the shared relay.

One secret per app: Each connection gets its own unique secret. If you connect three apps to your wallet, three independent secrets exist. Revoking one kills that app's access without affecting the others, and without rotating your wallet's master keys.

Payment Flow

Once paired, a payment follows six steps:

1. The app receives or generates a BOLT-11 invoice to pay.
2. The app constructs a JSON payload (method: "pay_invoice", params: the invoice string) and encrypts it using NIP-44 encryption with the connection secret.
3. The app publishes a kind 23194 event to the Nostr relay, tagged with the wallet service's pubkey.
4. The wallet service, subscribed to events on that relay, receives and decrypts the request.
5. The wallet verifies the request against the connection's permission scope (budget, per-payment limit) and executes the Lightning payment.
6. The wallet publishes a kind 23195 response with the payment preimage (or an error code like INSUFFICIENT_BALANCE or QUOTA_EXCEEDED).

The entire exchange is end-to-end encrypted. The relay routes sealed messages but cannot observe invoice amounts, destinations, or preimages.

Supported Methods

NWC is not limited to sending payments. The protocol defines a set of methods that cover the full range of wallet operations an app might need:

Extension specs maintained in the NWC extensions repository add hold invoices (NWC ext 03), notification subscriptions (NWC ext 02), deep links for mobile pairing (NWC ext 07), and BIP-321 payment URIs (NWC ext 321). Wallet services advertise which methods they support in their kind 13194 info event, so apps can adapt to each wallet's capabilities.

Security and Permission Scoping

The connection secret is bearer authority: anyone who possesses it can spend from the wallet up to whatever limits the wallet service enforces. This makes permission scoping essential.

Budget Controls

Wallet services (like Alby Hub) allow users to configure fine-grained constraints per connection:

• Maximum amount per individual payment (e.g., 10,000 sats per transaction)
• Spending budget with renewal window (daily, weekly, monthly, or yearly cap)
• Allowed method list (e.g., read-only apps get only get_balance and list_transactions)
• Connection expiry date after which the pairing stops working
• Approval mode: manual confirmation per payment, full auto-approval, or hybrid (auto-approve under a threshold)

When a payment request exceeds the budget, the wallet returns a QUOTA_EXCEEDED error. The app handles this gracefully without crashing or retrying.

Relay Trust

Relays are message routers, not trusted parties. Because NWC messages use NIP-44 encryption (or the older NIP-04 as a fallback), relays see only the encrypted ciphertext, event timestamps, and the two pubkeys involved. They cannot read invoice amounts, destinations, or preimages.

The residual risk is metadata: a relay operator can observe that pubkey A communicates with pubkey B at certain times, and correlate this with Nostr identity if the wallet pubkey is linked to a public profile. Users who need stronger privacy can run their own relay, which several wallet services support.

Known Attack Surfaces

• A compromised app can drain funds up to the connection's budget limit before the user revokes it
• Auto-approval with unlimited budgets is dangerous: any app compromise becomes a full wallet drain
• The multi_pay_invoice method enables rapid batch payments, amplifying the damage window of a compromised secret
• Payment history exposed via list_transactions can leak financial privacy to connected apps

Best practice: Treat each NWC connection like an API key with a spending cap. Give each app the minimum methods it needs, set a daily budget you can afford to lose, and review active connections periodically. Revoking a connection is instant and free.

Real-World Use Cases

Zapping From Nostr Clients

The original use case for NWC is zaps: Lightning tips attached to Nostr notes. Clients like Damus (iOS), Amethyst (Android), and Primal (cross-platform) let users connect their wallet via NWC and zap content creators with a single tap. The wallet handles routing and settlement in the background while the user stays in the social feed.

Content Monetization

Platforms like Wavlake (music streaming) and Fountain (podcasting) use NWC to let listeners tip artists and podcasters directly from the playback interface. The listener connects their wallet once, and every subsequent tip flows through the same encrypted channel without re-authentication.

Merchant Payments

BTCPay Server and the BuzzPay point-of-sale terminal support NWC as a wallet backend. Merchants connect their self-custodial wallet and receive payments without exposing node credentials to the POS device. WooCommerce and Shopify plugins extend this to e-commerce.

AI Agents and Automation

NWC's programmatic interface makes it a natural fit for autonomous payment agents. The Alby Bitcoin Payments MCP server connects AI agents to Lightning wallets via NWC, allowing language models to make budgeted payments on behalf of users. Automation platforms like n8n use NWC nodes to trigger payments as part of workflows: pay an invoice when a form is submitted, zap a contributor when a PR is merged, or stream sats to a service based on usage.

The NWC Wallet Ecosystem

Dozens of wallets now implement the NWC wallet service, spanning self-custodial nodes, custodial services, and ecash mints:

• Alby Hub: self-custodial Lightning node with full NWC support, backing LDK, LND, Cashu, and Phoenixd. Alby sunset its custodial shared wallet in January 2025, pushing users toward self-custody.
• Zeus: mobile multi-wallet with an embedded LND node and NWC
• Coinos: free custodial web wallet with NWC
• Primal: custodial wallet built into the Primal Nostr client
• Cashu.me and Minibits: ecash wallets with NWC bridges
• LNbits and Core Lightning: infrastructure-grade implementations via plugins

On the client side, over 40 apps integrate NWC: social clients (Damus, Amethyst, Primal, Snort, Coracle), content platforms (Stacker News, Wavlake, Fountain), crowdfunding (Geyser), streaming (Zap.Stream), games, and even hardware devices like the BoltCard NFC tap-to-pay card.

NWC vs. WebLN vs. WalletConnect

Three protocols address the problem of connecting apps to wallets. Each targets a different ecosystem and makes different tradeoffs:

NWC's key advantage over WebLN is platform independence. A WebLN integration only works when a user has a compatible browser extension installed and the tab is active. NWC works everywhere: a cron job on a server can pay invoices, an NFC card can trigger payments, and a mobile app can zap without a browser in the loop. Alby's JS SDK bridges the two with a NostrWebLNProvider that exposes a WebLN-compatible interface over NWC, letting legacy web apps use NWC without code changes.

Compared to WalletConnect on Ethereum, NWC uses Nostr's censorship-resistant relay infrastructure rather than a proprietary relay network. The two protocols share no code or specification despite the similar naming: NWC is purpose-built for Lightning payment operations (invoices, keysend, balance queries) rather than general-purpose transaction signing.

Limitations and Open Questions

Relay Dependency

NWC relies on at least one Nostr relay being available for message routing. If the relay specified in the connection URI goes offline and no fallback relay is configured, payments stall until connectivity is restored. Users can mitigate this by specifying multiple relays in the connection URI or running their own.

Identity Linkage

If a user's NWC wallet pubkey is the same key they use for their public Nostr profile, payment patterns become linkable to their social identity. Best practice is to use a dedicated keypair for NWC connections, separate from the user's social Nostr identity.

Pairing UX

The current pairing flow requires users to generate a connection string in their wallet, copy it, and paste it into the app (or scan a QR code). A proposed improvement, Nostr Wallet Auth (NIP-67), would invert this flow: apps would initiate connections by presenting a QR code specifying required methods and budget, and wallets would approve or deny the request. This mirrors how OAuth consent screens work and could reduce friction significantly.

Design Patterns for Wallet-Agnostic Payments

NWC's success points to a broader shift in how payment protocols are designed. Rather than requiring apps to integrate directly with specific wallet implementations, NWC defines a standard interface that any wallet can implement and any app can consume. The app does not need to know whether the user's wallet runs LND, Core Lightning, or an ecash mint. It just sends a pay_invoice request and gets back a preimage or an error.

This wallet-agnostic pattern appears across the Bitcoin ecosystem. Spark takes a similar SDK-first approach to wallet integration: developers integrate with Spark's SDK and their users get instant, self-custodial Bitcoin and stablecoin payments without needing to understand the underlying protocol. The common principle is that payment infrastructure should be invisible to end users and simple for developers to embed. NWC achieves this for Lightning wallet connections; Spark's SDK achieves it for the wallet itself.

Getting Started With NWC

For developers building apps that need Lightning payments, NWC support can be added through Alby's JavaScript SDK, which provides a typed NWCClient for all NIP-47 methods. The nwc.dev site maintains documentation, tutorials, and a complete ecosystem directory. For users, any wallet that supports NWC (Alby Hub, Zeus, Coinos, or others) can be connected to any NWC-compatible app in under a minute.

For a deeper look at how Nostr and Bitcoin payments intersect beyond NWC, see our research on Nostr, Bitcoin identity, and payments. For the underlying glossary definitions, see Nostr Wallet Connect and Lightning invoices.

This article is for educational purposes only. It does not constitute financial or investment advice. Bitcoin and Layer 2 protocols involve technical and financial risk. Always do your own research and understand the tradeoffs before using any protocol.