Product shape

The practical product is a shared companion plus five signer solutions, not five unrelated experiments. Every shared feature behaves the same across implementations because the contract_id in nSealr/specs defines it once.

nSealr signer architecture Nostr clients send signing requests to the companion, which routes them to one of five signer solutions: Raspberry/Pi stateless QR vault, ESP32 QR vault, ESP32 USB signer, smartcard, or custom persistent-secret hardware wallet. Nostr Client Companion Verifier Raspberry QR Vault ESP32 QR Vault ESP32 USB / NIP-46 Smartcard APDU Custom Wallet

The five signer solutions

A solution is the unit at which feature parity is contracted. See the Signers section for the per-solution capability matrix and live maturity.

  • nSealr Vault — Pi edition — air-gapped, RAM-only, SeedSigner-style Raspberry Pi Zero.
  • nSealr Vault — ESP32 edition — air-gapped ESP32-P4 camera + display (Waveshare P4-3.5).
  • nSealr Key — daily-use connected ESP32-S3 signer (universal Waveshare S3-Touch family), real signing gated.
  • nSealr Card — display-less Satochip JavaCard, in-card signing, external review required.
  • nSealr One — USB-C flagship: hardened firmware signer + TROPIC01-backed vault + key-split, battery-operable, checked against persistent-secret-custody-v0.

Companion surfaces

The companion is a single TypeScript monorepo that ships multiple access surfaces over the same secretless platform. Every surface reuses the same validation, transport, and response-verification logic.

SurfacePurpose
nsealr CLIRequest construction, transports, verification, audit export.
npm SDKEmbed the companion in any Nostr client or service.
Browser extensionNIP-07 surface backed by a signer.
Local appDesktop UI for routing and review.
Local serviceBackground daemon for the extension and apps.
NIP-46 bridgeConverts already-decrypted NIP-46 payloads into standard nSealr signing requests.
NIP-46 relay sessionRuns a real remote-signer session over relays (NIP-44 + request/response correlation) with an ephemeral client transport key.

The companion is never trusted with the user’s key custody. It composes requests, moves them over the selected transport, and verifies every successful response against shared fixtures. The only secret it holds is an ephemeral client transport key for NIP-46 relay sessions (RAM-only, never the user signing key).

Trust boundaries (summary)

LayerTrusted with…Not trusted with…
Clientbuilding requestsprivate keys
Companionrouting & response verificationprivate keys, policy execution
QR vaultRAM-only signingpersistent secret
USB signerpersistent secret (after gates)the universe outside its boundary
Smartcardpersistent secret, APDU signingtrusted event review (display-less)
Custom HWpersistent secret + display review (after gates), under persistent-secret-custody-v0air-gapped claims, direct TROPIC01 Schnorr claims before evidence

The trust boundaries page and the threat model cover this in depth.

Last updated 2026-05-20