FAQ

What is nSealr in one sentence?

A non-profit, open-source program of specs, companion software, and five signer solutions so that Nostr signing can happen on hardware you can audit, build, and verify — not inside whichever app happens to hold your nsec.

Why not just use a browser extension like nos2x or Alby?

Browser extensions are a reasonable upgrade over copy-pasting nsec, but they still hold the key in software, in a process that touches every page you visit. A hardware signer pushes the trust boundary to a device with an explicit user gesture. If your threat model is “any compromised page can sign”, an extension does not help. If your threat model is “I want to see what I sign on a separate screen”, you need hardware.

Why not just use a Trezor / Ledger / SeedSigner?

• Trezor / Ledger: their firmware is signing Bitcoin / EVM transactions, not arbitrary Nostr events. Most do not implement BIP-340 Schnorr over Nostr event ids. Some Trezor models can be extended, but it’s not a first-class flow.
• SeedSigner: ideologically very close — air-gapped, QR-only, RAM-only, open hardware. nSealr’s Raspberry/Pi QR vault is the SeedSigner pattern applied to Nostr events specifically, with shared specs so other solutions can match its behavior.

We borrow from all three. We don’t fork any of them.

Can I use nSealr in production today?

No. Real sign_event is signing_disabled on every prototype firmware. Until the secure-boot / flash-encryption / debug-lock / provisioning / recovery gates land independently per solution, this is research and development.

Per-solution maturity is in each signer page.

Why does TROPIC01 keep coming up — and why is direct Schnorr future-gated?

TROPIC01 is a secure element being investigated for the custom hardware-wallet line. Public APIs expose P-256/ECDSA and Ed25519/EdDSA, but BIP-340 Schnorr over Nostr event ids is not available in a production-validated public path today. The current Rev A direction is ESP32-S3 host-MCU signing with TROPIC01 used for secure channel, TRNG, device authenticity, pairing lifecycle, key wrapping/unlock material, and PIN hardening. Direct TROPIC01 Schnorr stays future-gated until a public API, firmware release, or written vendor path is verified.

Why are there five signer solutions instead of one?

Different trust boundaries fit different threat models.

• QR vaults (Raspberry/Pi, ESP32): air-gapped, RAM-only, manual-only. Best for “I never want this key online, even briefly”.
• USB / NIP-46 signer: a persistent device for daily use, with scoped automation through the companion. Best for “I sign a lot and review most of them”.
• Smartcard: display-less custody, external review acknowledgement on a trusted screen. Best for very compact carry hardware.
• Custom hardware wallet: research line for purpose-built persistent-secret hardware. The first Rev A scaffold is USB-C bus-powered, no-battery, connected/no-wireless, TROPIC01-assisted, and now pinned to the checked persistent-secret-custody-v0 lifecycle contract.

A solution shares contracts with the others where applicable — so a feature like approval_digest behaves identically across all of them when present.

Where do the private keys actually live?

The companion never holds keys. The client never sees keys.

What is approval_digest?

A deterministic hash over the exact canonical material the user reviewed. The local approval gesture is bound to this digest, and the signer refuses to emit a signature whose serialisation does not reproduce the same digest. See the deep-dive.

What does signing_disabled mean?

Prototype firmware exposes the whole signing flow — request validation, review, approval — but refuses to actually emit a BIP-340 signature. It returns a deterministic “signing-disabled” decision instead. This lets us collect protocol evidence and CI against the contracts without ever putting a real signing path on hardware that hasn’t passed hardening gates.

Why are docs and code in different repos?

To make every signer line auditable independently. The website is documentation; the hardware lives in nSealr/raspberry, nSealr/esp32, nSealr/smartcard, nSealr/hardware; the spec is nSealr/specs. A contributor can take any one of these without cloning everything.

Can the companion sign things on my behalf without asking?

No — the companion is secretless. It can propose policy to a signer (for the USB/NIP-46 line), but the signer enforces the policy and a signing decision still requires a deliberate local gesture (or, for smartcard, an external review acknowledgement). The companion physically cannot sign anything: it doesn’t have a key.

How do I report a security issue?

Open an issue on the relevant repo, or contact the GitHub organisation. For pre-disclosure, please use a private security advisory on GitHub. The project does not yet make a production security claim, so most issues during this phase are functional / contract bugs — but security reports are still welcome.