Cowrie Research

nwc-enclaved

4 min read

nwc-enclaved

  • Name: nwc-enclaved
  • URL: https://github.com/nostrband/nwc-enclaved
  • Category: TEE-based custodial Lightning wallet backend / Nostr Wallet Connect wallet-service infrastructure / attested zap-address custody middleware
  • Tags: bitcoin-ecosystem
  • Summary: nwc-enclaved is best cataloged as enclave-based wallet-service infrastructure rather than as a normal custodial wallet, simple NWC bridge, or generic Nostr utility. In this pass, the strongest first-party evidence came from the canonical GitHub README, the companion nwc-enclaved-utils library, the Zap.Land README, the project’s VIBE.md, and the related Nostr Enclave attestation materials. Taken together, those sources describe a wallet-service stack that lets any Nostr pubkey obtain a Lightning wallet without signup, uses NWC as the control plane, extends NWC with a make_invoice_for method so third parties can generate receive invoices and zaps, relies on phoenixd for automatic liquidity management, and is explicitly designed to run inside AWS Nitro Enclaves with reproducible builds and attestable code identity. The key distinction is that nwc-enclaved is packaging an attested, API-like custody substrate for apps and agents that want instant Lightning and zap capability without running their own node or handing opaque custody to a conventional wallet provider.
  • What it does:
    • Lets apps, agents, or users create and control Lightning wallets through Nostr Wallet Connect without a separate signup or QR-based wallet-connection ceremony
    • Treats any Nostr pubkey as wallet-capable and only materializes wallet state when an invoice is paid and the balance becomes non-zero
    • Adds a nonstandard make_invoice_for NWC method so third parties can generate invoices for a target pubkey, enabling Lightning address receive flows and NIP-57 zaps
    • Uses phoenixd as the Lightning backend for automatic liquidity management while layering wallet-level accounting and fee logic on top
    • Publishes a service-announcement event with relay, limits, and attestation metadata so clients can discover wallet-service instances and choose among operators/builds
    • Pairs with nwc-enclaved-utils and Zap.Land so developers can create wallets programmatically, derive Lightning addresses, and publish zap-capable Nostr profiles with minimal setup
  • Key claims:
    • The README says the project is a “custodial NWC wallet for TEE” and frames its main purpose as giving apps and agents zappable Lightning wallets without signup or KYC
    • The README says privacy and rug-pull risks are reduced by running an open-source autonomous custodial wallet inside AWS Nitro Enclaves with reproducible builds and attestation, while also acknowledging that legal questions remain out of scope
    • The README says any NWC method can be called by any pubkey without an additional connection or signup step, and that actual wallet state is only created once funds arrive, which is a strong clue that the project is behaving more like a just-in-time wallet service API than a traditional wallet UX
    • The README documents a custom make_invoice_for method plus NIP-57 zap support and describes how Zap.Land can map <user-npub>@<service-npub>.zap.land addresses onto the service, making receive-side interoperability a first-class goal
    • The project explicitly publishes a kind:13196 service-announcement event with relay and balance-limit metadata, showing that multi-operator discovery is part of the intended architecture rather than an afterthought
    • The fee model is operationally opinionated: a 1 sat daily wallet fee on non-empty wallets, a 1 sat payment fee, and pass-through liquidity-fee accounting tied to phoenixd, which suggests the system is designed to be self-sustaining under small-balance, high-activity usage
    • The companion nwc-enclaved-utils README shows a concrete developer flow where code can create a wallet, receive an NWC string and Lightning address, and publish a zap-capable Nostr profile, which confirms the project is being shaped as app-and-agent integration infrastructure
    • The related NEC-01 and nostr-enclaves materials show that attestation verification is meant to be machine-checkable by clients, reinforcing that trusted execution is part of the product surface rather than marketing garnish
  • Whitepaper: No canonical standalone nwc-enclaved whitepaper or litepaper surfaced in this pass. The clearest source of truth was the main repository README, the companion utils library, the Zap.Land README, and the related enclave-attestation materials; see ../whitepapers/nwc-enclaved-primary-sources-2026-05-03.md.
  • Sources:

Internal linkages

  • Protocol rail beneath the same app-to-wallet control surface: nostr-wallet-connect.

  • Stronger self-custodial comparison for app-connected Lightning operations: alby.

  • Last reviewed: 2026-06-05 UTC

Graph View