An air-gapped Bitcoin signing device you can actually verify.
Runs on a Raspberry Pi. Generates seeds from dice you rolled yourself. Signs PSBTs across an air gap. Every module ships with a machine-checkable specification, and the device refuses to run unless code, specs, and tests all agree.
Do not take our word for it
A hardware wallet that generates your seed inside a black box is asking you to trust the box. In 2024 a widely used one turned out to ship a random number generator that did not behave as documented, and the industry answered by promising a better black box.
Here is the alternative. Roll some dice below, then run the command it gives you in a terminal.
0 rolls. 100 more for a real seed. 99 is not enough: it is 255.911 bits.
Press the numbers. Each one is a roll of a six-sided die. The device does exactly this, and nothing else, to turn dice into a seed.
That is the whole idea. If a device shows you a different value for the same rolls, it is lying to you and you can tell. No special tooling, no trust in us. The full procedure, including why the answer is 100 rolls and not 99, is in Entropy.
The device
A 7 inch touchscreen on a Raspberry Pi. These are screenshots of the running software, not mockups.
Live entropy accounting, truncated so it never claims more than you have. Warnings appear and never block: a fair die can look suspicious, and the device does not discard your rolls.
Every script type, receive and change, with the derivation path under each address. No balances, because the device has no network and will not pretend otherwise.
Paste an address a coordinator gave you. The device re-derives it from your seed and answers, rather than comparing against a list it was handed.
The hash of the running code, and a plain statement of what it does not prove. Compare it against what you built. If they differ, do not enter your PIN.
Before you trust this with anything
There is no secure element
Keys are encrypted under a key derived from your PIN, and that is the entire physical defence. Someone holding your SD card is limited only by your PIN strength. A Coldcard or BitBox02 is genuinely better on this specific axis.
One signer in a quorum
Designed for 2-of-3 or 3-of-5 alongside hardware from other vendors, where nullroute is the one you can fully audit. Sole custody of meaningful funds is a use we have not designed for.
Not finished
Pre-1.0 and unaudited. There is no encrypted store and no PIN gate yet, so there is nowhere to persist a wallet. Do not put money on this.
What it does
- Signs without leaking
- RFC 6979 deterministic ECDSA and BIP-340 Schnorr with
aux_randfixed to zero. Signatures are byte-identical every time, so there is no free space to hide key material in. A randomised signature can leak your key a few bits per transaction and nothing on screen looks wrong. - Verifies change by re-deriving it
- An output is labelled change only if the address re-derives from a registered descriptor at a valid change path. Anything else is shown as a payment, whatever the transaction claims.
- No network, at all
- Not for updates, not for fee estimation, not for fonts. Enforced by a lint rule with its own regression suite, a runtime assertion, and a kernel-level restriction on the daemon, rather than by convention.
- No lock-in, proved in CI
- Every wallet is recoverable from the BIP-39 mnemonic plus a standard descriptor, using Bitcoin Core and no nullroute code. There is a test that does exactly that against regtest, and it is the most important test in the suite.
Run it yourself
You do not need a Raspberry Pi to look at this. The whole device runs on a Mac or Linux machine, and the lock screen will show the hash of the code you just built.
git clone git@github.com:Xaxis/nullroute.git
cd nullroute
make install
make dev # the device, at 127.0.0.1:5180Hardware for a real one runs about $100 to $120: a Raspberry Pi, a small touchscreen, an SD card and one die. The bill of materials is in the README.
Documentation
Rendered directly from docs/ in the repository. The page you read here and the file that ships with the code are the same bytes.
Threat model
What is this safe against, and what is it not?
What the device defends against, what it partially defends against, and the long list of what it does not. Read this before trusting it with anything.
Verification
How do I check the device is honest?
How to check, yourself, that a device runs the code it claims to. Written for someone who does not trust this project and should not have to.
Entropy and seed generation
How do dice become a seed, and how do I check it?
The dice procedure, the exact byte encoding, and a worked example you can reproduce with sha256sum on any machine.
Provisioning a device
How do I build and verify the device image?
The hardware, the hardening actually applied (and the standard controls deliberately skipped as theater here), and how to verify an image before and after flashing it.
Status
The signer is being built before the wallet, and the verification system was built before the signer. Nothing later is pulled forward: that ordering, and the irreversible work staying last, is what keeps a large feature list from eroding the small part that holds keys.
| Phase | Scope | State |
|---|---|---|
| 1 | Spec system, entropy, BIP-39/32, daemon, lock screen, networks | complete |
| 2 | Descriptors, addresses, PSBT review, signingTier 0: reproducible, signed image | in progress |
| 3 | Multisig, cosigner registration, encrypted store, PINTier 1: dm-verity, boot attestation | not started |
| 4 | BIP-322 message signing, BIP-85, BIP-329 labels | not started |
| 5 | Wallet layer, optional and lower assurance | not started |
| 6 | Bridge companion, runs on a networked machine | not started |
| 7 | Miniscript, taproot script paths, SeedXOR, silent paymentsTier 2: signed boot chain (irreversible) | not started |