nwc-enclaved primary sources — 2026-05-03

Project status in this pass

• No canonical standalone nwc-enclaved whitepaper or litepaper surfaced.
• The clearest current source of truth is the canonical repository README, the companion nwc-enclaved-utils library, the Zap.Land README, the placeholder VIBE.md, and the related enclave-attestation materials.
• The project is best understood as attested wallet-service infrastructure for Lightning and zaps rather than as a standard wallet app.

Primary-source snapshots

1) Canonical repository / README

• URL: https://raw.githubusercontent.com/nostrband/nwc-enclaved/main/README.md
• Key excerpt:
  • The README calls the project a “custodial NWC wallet for TEE.”
  • It says the goal is to let app and agent developers provide zappable Lightning wallets without signup, KYC, or upfront payments.
  • It also says the project is designed to run inside AWS Nitro Enclaves with reproducible builds and attestation.

2) Wallet-creation and trust-model details

• URL: https://raw.githubusercontent.com/nostrband/nwc-enclaved/main/README.md
• Key excerpt:
  • The wallet-creation section says clients can generate NWC keys themselves and that the service accepts NWC queries from any key.
  • It says actual wallet state is only created when an invoice is paid and the pubkey gets a non-zero balance.
  • The README also documents service-announcement events and a fee model built around wallet fees, payment fees, and liquidity accounting.

3) Receive-side addressing and zaps

• URL: https://raw.githubusercontent.com/nostrband/zap-land/main/README.md
• Key excerpt:
  • The Zap.Land README says the server provides a LUD-16 Lightning address with Nostr zap support for an NWC wallet.
  • It says the setup depends on a new make_invoice_for NWC method that lets third-party pubkeys generate invoices for the target wallet.
  • It gives a concrete address derivation pattern based on wallet-service and client pubkeys.

4) Developer integration flow

• URL: https://raw.githubusercontent.com/nostrband/nwc-enclaved-utils/main/README.md
• Key excerpt:
  • The utils README shows a code path where developers call createWallet() and receive both an nwcString and an lnAddress.
  • It also documents how that wallet can be used via Alby SDK-compatible NWC clients and how developers can publish a zap-capable Nostr profile.

5) Attestation and client verification

• URL: https://raw.githubusercontent.com/nostrband/necs/main/01.md
• Key excerpt:
  • NEC-01 defines how a service running in AWS Nitro Enclaves can produce a Nostr attestation event tying a pubkey to enclave PCR values signed by AWS Nitro Attestation PKI.
  • It explicitly says attestation only adds safety when clients validate against trusted PCR values, which is important context for evaluating the project’s trust claims.

6) Project framing for AI-assisted app builders

• URL: https://raw.githubusercontent.com/nostrband/nwc-enclaved/main/VIBE.md
• Key excerpt:
  • Even the placeholder VIBE.md frames the project as a way to “vibe code” a Lightning wallet into an app and points builders to the utils README as the current integration surface.

7) Baseline protocol reference

• URL: https://raw.githubusercontent.com/nostr-protocol/nips/master/47.md
• Key excerpt:
  • NIP-47 defines Nostr Wallet Connect as a protocol for remote wallet access through encrypted messages over Nostr relays.
  • Comparing nwc-enclaved to NIP-47 makes clear that the project is extending the baseline standard with creation and receive-side behavior not present in the core spec.

Working conclusion

nwc-enclaved is best cataloged as attested NWC wallet-service infrastructure. The deciding evidence in this pass was the combination of no-signup wallet creation for any pubkey, receive-side extensions for zaps and Lightning addresses, operator-discoverable service announcements, explicit fee machinery for sustainability, and a trust model centered on reproducible enclave deployment plus client-verifiable attestation.