Professional
nSealr
Nostr signing devices in five form factors, held together by 220 conformance vectors and firmware that refuses to sign until twelve readiness gates pass; ten remain unmet on the ESP32 scaffold.
nSealr builds signing devices for Nostr keys: a Raspberry Pi vault, two ESP32 form factors, a smartcard, and a purpose-built wallet. The thing that makes them one project is not shared code; it is a specification with 220 conformance vectors that four implementations, in four languages, all have to replay identically.
- Products
- Vault (Pi and ESP32) · Key · Card · One
- Contract
- 220 vectors · 11 protocol documents · 11 schemas
- Signing boundary
- Pi vault signs; ESP32 enforces signing_disabled
- Licences
- CC0 specs · MIT code · CERN-OHL-P hardware
- Repository
- nSealr/specs
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.
220
conformance vectors
107
of them refusals
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 is bound not only to what was signed but to what was shown. A device that displayed something different produces a different digest, and the mismatch is detectable rather than a matter of trust.
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
Refusing to ship the feature the project is for. The firmware implements the whole request,
review, custody and policy path, and then answers every valid signing request 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. Ten of the twelve remain unmet on the ESP32 scaffold. The one implementation
that produces real BIP-340 signatures is the Raspberry Pi vault.
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.