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 nostr-ecosystem
• Summary: nwc-enclaved is attested hosted Lightning wallet infrastructure for Nostr-era apps. The point is just-in-time wallet creation, NWC control, receive-side zap plumbing, and a custody boundary that tries to be inspectable instead of purely trust-me. Useful service shape, still a specialized hosted wallet rather than a self-custodial anchor.
• What it does:
  • Lets any Nostr pubkey get a Lightning wallet through Nostr Wallet Connect without a separate signup or QR handoff
  • Materializes wallet state only once funds arrive, so the service behaves more like just-in-time wallet infrastructure than a normal consumer wallet app
  • Adds a custom make_invoice_for NWC method so third parties can generate receive invoices and zap flows for a target pubkey
  • Runs on top of phoenixd for liquidity handling while adding wallet accounting, fees, and service-level policy
  • Publishes service-announcement and attestation metadata so clients can discover operators and inspect which build they are trusting
  • Pairs with nwc-enclaved-utils and Zap.Land so developers can spin up wallets, derive Lightning addresses, and publish zap-capable profiles quickly
• Key claims:
  • The README calls it a custodial NWC wallet for TEEs and frames the product around instant zappable wallets for apps and agents rather than long-lived human wallet UX
  • The AWS Nitro Enclave and reproducible-build story matters because it makes the custody boundary more legible, not because enclaves magically remove trust
  • The any-pubkey, no-signup flow is the clearest reason the note exists: it turns hosted Lightning custody into something closer to app middleware
  • The custom make_invoice_for method and Zap.Land mapping keep receive-side interoperability explicit instead of burying it in wallet copy
  • The fee model and phoenixd dependency matter because they show the operator economics and liquidity assumptions underneath the nicer app story
  • The service-announcement and enclave-attestation materials matter because clients are meant to compare operators and verify code identity, not just accept one default host blindly
• 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:
  • https://github.com/nostrband/nwc-enclaved
  • https://raw.githubusercontent.com/nostrband/nwc-enclaved/main/README.md
  • https://raw.githubusercontent.com/nostrband/nwc-enclaved/main/VIBE.md
  • https://raw.githubusercontent.com/nostrband/nwc-enclaved-utils/main/README.md
  • https://raw.githubusercontent.com/nostrband/zap-land/main/README.md
  • https://raw.githubusercontent.com/nostrband/necs/main/01.md
  • https://raw.githubusercontent.com/nostr-protocol/nips/master/47.md

Internal linkages

• Best upward reads: alby and nostr-wallet-connect.

Control surface

• The leverage sits in wallet materialization, NWC permissioning, attestation and discovery metadata, fee policy, and the hosted phoenixd backend the service wraps.

• Read it as attested wallet middleware. If the operator is weak, the enclave story does not save the service.

• Last reviewed: 2026-06-17 UTC