Built to be checked,not to be trusted.

Six screens from the real frontend, at the panel’s real 800x480. Rendered by a browser from the same gallery the layout and contrast checks measure, so this is the device rather than a picture of one.

Every module ships a specification a machine reads. The build fails when the code, the specs and the tests stop agreeing, so the specification cannot quietly fall behind the thing it describes.

nullroute verification

  ok    coverage        271 of 271 runtime exports covered
  ok    invariants      338 invariants bound to 977 tests, 1296 tests in the suite
  ok    vectors         24 of 24 vector files match their pinned hash
  ok    differential    3 modules cross-checked
  ok    integrity       368 files, root 0886433f...a9857292

  39 specs, 338 invariants
  manifest root  0886433f3c2968433144f92d467cf15e593c29438de9349f5148244aa9857292

verification passed

$ printf '%s' '1234561234561234561234561234561234561234561234561234561234561234561234561234561234561234561234561234' | sha256sum
e56403e8522ddeae1b44a1e8148b1ba4d3b4c626ccf20980056eedcc7e0c0f35  -

The last line is the manifest root: every source file hashed, sorted under LC_ALL=C, in a format coreutils produced and coreutils can check. The device prints the same string on its lock screen. Build the source yourself and compare the two. If they differ, do not enter your PIN. How to do that.

What is built, what comes next, and what it does not protect against yet. Keep real money off it until the first two are done.

Not audited yet

One person wrote it. Before it holds real money, the code that holds keys needs to be read by somebody other than its author.

Hardware bring-up is next

The card boots under QEMU, opens its dm-verity mapping, refuses a partition with one byte changed, and starts the signing daemon. The next milestone is the same card on a Pi 4 with the 7 inch panel, which is the first run of the firmware path from power-on to the kernel and the first time the screens are drawn on the panel itself.

The boot partition is not covered

dm-verity detects modification of the system partition and does not prevent it. The boot partition holds the root hash and cannot be under the tree that hash describes, so an attacker who rewrites it supplies their own number. A signed boot chain closes that in phase 7, last on purpose, because it burns one-time fuses.

The browser is the weakest part

The screens are a Chromium kiosk, and its own sandbox needs the user namespaces that the directives protecting the daemon take away. So trust is kept out of it rather than hardened into it: the daemon holds the keys, and the screens receive only xpubs, addresses, descriptors and transactions.

It will not save you from a person

Hidden profiles and a wipe PIN are planned for phase 7. When they exist, they buy time against somebody unsophisticated and nothing more: this codebase is public, so anyone who reads it knows exactly what they do.

The full list, including what this deliberately does not defend against, is in the threat model. It is long on purpose.

The device and the method behind it are both open: specifications a machine can check, invariants bound to named tests, and a build that fails when a claim stops being true.

There is no download: you build it, which is the point. It runs on a Mac or a Linux box today. The device needs a 64-bit Raspberry Pi with enough memory, an 800x480 touchscreen and a camera. The card built today targets a Pi 4 and the official 7 inch touchscreen, about $100 in parts, and other boards follow as each one is brought up. A wallet here is a BIP-39 mnemonic and a canonical BIP-380 descriptor, so Bitcoin Core restores it with none of this code involved. The most valuable thing you can do with it is find where it is wrong.

Rendered from docs/ in the repository, the same bytes a reviewer reads in the source.