nSealr

nSealr is a pre-production system with a shared protocol and experimental implementations for Nostr signing devices. The Raspberry Pi implementation produces BIP-340 signatures, ESP32 signing remains disabled, and smartcard work is limited to simulator and PC/SC boundaries. Custom wallet hardware remains under development. Four implementations share one protocol and its conformance vectors.

Device families

Vault (Pi and ESP32) · Key · Card · One

Contract

Shared protocol, schemas and conformance vectors

Signing boundary

Experimental Pi signing; ESP32 signing disabled

Licences

CC0 specs · MIT code · CERN-OHL-P hardware

Repository

nSealr/specs

nSealr/specsShared nSealr protocol contracts, schemas, QR/review contracts, approval digests, and NIP-01/BIP-340 conformance vectors.Python

The problem

A hardware signer exists to answer one question honestly: is what I am approving what will actually be signed? Every part of the system between the user’s eyes and the signature is a place where that can stop being true: the host that composed the request, the transport that carried it, the parser that read it, the screen that rendered it.

The host is the easy call: the companion application is explicitly not trusted with key custody, and every implementation must reject an attempt by it to act as the review authority. The hard part is the screen. A device that displays one thing and signs another is indistinguishable, from the outside, from one that works.

What I built

The centre of the project is not a device, it is specs: protocol documents, JSON schemas, and 220 vectors, 107 of which describe things that must be rejected. Malformed frames, padded encodings, oversized payloads, duplicate gate names, a device claiming to be signing-enabled while still listing missing gates. Roughly half of the shared contract is deterministic refusal.

The answer to the screen problem is the approval digest. It is a SHA-256 over the request’s identity, the exact event template, the derived review data, and the rendered pages, so an approval binds the request to the review representation. A change in those inputs changes the digest. This checks consistency between the approval artifact and the signing request; it does not independently prove what a compromised physical display showed.

The review itself is four physical pages: event header, complete content that is never truncated, tags grouped rather than shown as raw JSON, and a decision page. Raw values only: the specification forbids inferred labels, so a kind is shown as its number and not as a friendly name a compromised host could choose. Touch is navigation on every board; approval is always a separate physical control.

Hard parts

Keeping signing behind the readiness gates. The Rust firmware core implements the request, review, custody and policy path, and then answers approved signing requests with signing_disabled. There is no signing backend in it at all. Twelve readiness gates govern that, covering secure boot, flash encryption, debug lock, key provisioning, physical approval, Unicode review rendering and more; the protocol forbids a device from reporting itself signing-enabled while any gate is outstanding, and vectors pin both directions of that contradiction. The firmware core and desktop simulator do not establish an on-device signer. The one implementation that produces real BIP-340 signatures is the Raspberry Pi vault. That signing path is experimental and does not establish production key-custody security.

Keeping the roadmap honest inside the contract. Every feature in the compatibility matrix carries two values: what the product is meant to do, and what it does now. The specification says why: so a roadmap can be honest without weakening the compatibility guarantee. It also means a form factor cannot quietly claim a capability by shipping it in the target column.

Deleting a board because the evidence said to. A full custom wallet PCB – secure element, NFC, battery management, a 97-part bill of materials – was reviewed and declared not fabricable, with a defect register naming six critical faults including a display connector whose tail could never mate and a backlight driver that could not regulate below its input. The conclusion recorded was that it could not be fixed by patching the layout. It was archived and replaced by a minimal design, and the two hard gates that no amount of desk work removes were written down: interactive routing, and first-article RF tuning, because that is physics.