Out of scope

nullroute does not defend against any of the following. If your threat model includes one of them, this is the wrong device.

No secure element. This is the most important line in this document. The seed is encrypted at rest with AES-256-GCM under a key stretched from your passphrase by Argon2id at 64 MiB and three passes, and that is all. An attacker holding the SD card is limited only by your passphrase strength and that cost, which is roughly half a second per guess on this class of hardware. There is no tamper-resistant chip rate-limiting them, no key that never leaves hardware, and no self-destruct. A Coldcard or a BitBox02 is genuinely better than nullroute on this specific axis, and that is exactly why the recommended deployment is a multisig quorum that includes one of them.

The retry counter is not a defence against a stolen card. The device erases its wallet after ten consecutive failed unlocks. That stops a person who picks up a running device and starts guessing, and nothing else. The counter has to be readable before the passphrase is known, so it cannot be authenticated: anyone holding the card can reset it, or copy the sealed blob first and guess against the copy indefinitely, with no counter involved at all. Treat the ten attempts as protection against a passer-by, and the passphrase as protection against everyone else.

Erasure is not secure erasure. The sealed blob is overwritten before it is unlinked, and on flash storage with wear levelling the old blocks survive that. The property being relied on is that what was written was encrypted before it reached the card, not that it was destroyed afterwards.

Sophisticated physical attack on the SD card or the SoC. Chip decapping, glitching, cold boot attacks, and direct flash reads are all out of scope.

Side channel attacks against the Pi. Power analysis, electromagnetic emissions, acoustic, and timing attacks against the hardware are not defended against. The Pi was not designed for this and neither were we. That includes unlock timing: a correct and an incorrect passphrase take different paths after the key derivation, and nothing equalises them. Fixed-cost unlock is planned for phase 7 (INV-DURESS-2) and is not built.

A compromised host OS image installed before first boot. If the image you flashed was already backdoored, the manifest hash it displays is whatever the backdoor wants it to say. The application verification system defends the application, and it cannot bootstrap trust in the thing that runs it.

This is being addressed rather than merely conceded, and Building a device states exactly how far each step gets:

• Tier 0 (phase 2) makes the image reproducible and checkable before flashing and after reading the card back. What exists today: make image writes the image, its root hash and a SHA256SUMS over both, and make image-repro builds it twice and compares. Signing and publishing are planned: no signing key exists, nothing is signed, and no image has been published. So today tier 0 answers "was the build honest" only for an image you built yourself, and there is no download to ask "was it tampered with" about.
• Tier 1 (phase 3) puts the system partition under a dm-verity hash tree and shows its root hash at boot. Read carefully: on its own this moves the gap rather than closing it. Without a signed boot chain, an attacker who rewrites the boot partition supplies their own root hash and their own initramfs, and the device displays whatever number they chose.
• Tier 2 (phase 7) is what actually closes it, by chaining the verity root hash into a boot image the silicon verifies. It burns one-time fuses, cannot be undone, and rests on a closed-source BootROM that nobody outside Raspberry Pi can audit. It will never be the default.

Until tier 2, treat the operating system as trusted-by-assumption. The usual answer would be to build the image yourself or verify a signature on a published one. The first is available now and the second is not: make image builds a flashable card and prints its checksums, make image-repro builds it twice and compares, and nothing has been published, so there is no signature to check. This passage said the build script was never written, which stopped being true when it was. See docs/VERIFICATION.md.

Evil maid attacks, absent secure boot. See above. Tier 1 makes an unsophisticated modification visible to a user who reads the boot screen. It does not defeat an attacker who also rewrites the boot partition.

A determined adversary with unlimited time, you in custody, and knowledge of this codebase. Nothing in this repository helps you here. Duress profiles will not help you here either, when they exist.

Malicious hardware in the supply chain. We check the software supply chain. We cannot check that your Pi is a real Pi.

Your own operational security. Photographing your seed, typing your passphrase into a phone, storing a backup in cloud storage, or telling someone how much bitcoin you own are all outside what any device can fix.

---