SeedSigner/seedsigner: an air-gapped Bitcoin signing device built from a Pi Zero and a camera

What the device is for

The goal of SeedSigner is to lower the cost and complexity of Bitcoin multisignature wallet use. To accomplish that, it offers anyone the opportunity to build a verifiably air-gapped, stateless Bitcoin signing device using inexpensive, publicly available hardware components, usually under fifty dollars.

Two things in that sentence carry the design. The first is multisignature, which is the case where the risk model justifies a device like this. In a multisig setup the seed is distributed, so a single compromised machine cannot spend the funds, and the device that actually signs is a separate piece of hardware that holds one share and can be shown to do exactly what the user asked it to do.

The second is verifiably. The project is explicit about the two properties it claims, stateless and air-gapped operation, and about the trust model behind them, and it says the code is completely FOSS under the MIT licence, with reproducible builds, and that it is created and maintained by volunteers with no corporation and no profit motive.

The repository is the firmware. The current version is 0.8.7, and the release names are worth reading for a sense of the project's history, with 0.8.7 called the Summer of SeedSigner release from 2026-07-08, 0.8.6 the Bigger Picture release from 2025-06-30 and 0.8.5 the Spanish release from 2025-02-04. The default branch is `dev` rather than `main`, which is what you would expect from a project where the released artefacts are built from a separate OS image repository.

The air gap is a hardware decision

The feature highlights are worth reading as a threat model, because each line is a way an attacker would normally try to get at a seed.

Seeds are temporarily stored in memory while the device is powered, and all memory is wiped when power is removed. That is the stateless property, and it is why the device has no persistence for your key material: pulling the plug is the erase.

The SD card is removable after boot, to ensure no secret data can be written to it. The operating system image is on the card, the card comes out, and what remains is a device with no filesystem in which a secret could have been written.

There is no WiFi or Bluetooth hardware onboard. This is the reason the shopping list is specific about the board model, and it is a physical property rather than a disabled driver.

Data can only be received by reading QR codes with the camera, and data can only be sent by displaying QR codes on the screen. So the only channel into the device is optical, the only channel out is optical, and there is no network interface at all. A transaction is built on a phone, shown as a QR code, scanned by the device, signed, and shown back as a QR code for the phone to read.

It is a slow and slightly absurd way to move data, and that is the point. Every convenience that would normally be used to exfiltrate a key is absent by design.

The shopping list is the security model

The build guide is a shopping list, and the notes on it are where the engineering decisions are explained.

The Raspberry Pi Zero is the board, and the preference is version 1.3, which has no WiFi or Bluetooth capability, though any Pi 2, 3, 4 or Zero W or 2W model will work. The display is a Waveshare 1.3 inch 240x240 LCD, and the note is emphatic that it must be the 240x240 version, because Waveshare make several boards that look very similar and are not compatible. The camera is a Pi Zero compatible one, tested with the Aokin or AuviPal 5MP 1080p with an OV5647 sensor, and other cameras with that sensor should work but may not fit the Orange Pill enclosure.

There are two practical notes. You may need to solder the 40 GPIO pins, 20 per row, to the board, and most stores offer the board with headers already soldered, so a beginner does not have to. And the Pi Zero W or 2W is often easier to find but has WiFi and Bluetooth hardware, which you can still use, optionally with the hardware modification to disable the wireless chips that another project documents.

One legacy note closes the list. The Raspberry Pi 1 is also compatible, but it requires a hardware modification to the Waveshare LCD hat.

The project also publishes enclosure designs in the repository, and SeedQR printable templates, which is the physical artefact that carries a seed into the device without typing it.

Trust in the release images, and reproducible builds

There is a section titled a special note on minimizing trust, and it is the most honest thing in the README.

The argument runs like this. As is the nature of pre-packaged software downloads, downloading and using the prepared SeedSigner release images means implicitly placing trust in the people preparing those images. In this project the released images are prepared and signed by the eponymous creator of the project, SeedSigner the person, and that individual is additionally the only person in possession of the PGP keys that are used to sign the release images.

So the project names the concentration of trust rather than implying it away, and then answers it. Starting with v0.7.0, the images distributed via GitHub are reproducible, which means you and others can verify that the released images are byte-for-byte the same when built from source. The invitation is explicit: you can contribute to this project by building from source and sharing the hash of the final images, and the build instructions have been made available in a separate seedsigner-os repository, with a lot of thought and work put into making them understandable even for less technical users.

That is the right answer to the problem. A single key holder is a single point of trust, and reproducible builds turn that trust from a requirement into a check anyone can perform.

What the software actually does

The feature list covers seed creation, wallet setup and signing, and the details are the part that shows how much care is in the flow.

On seeds, you can create a seed phrase by picking BIP39 words and letting the device calculate the final word, the checksum, or create one via dice rolls, which is documented separately, or via image entropy from the onboard camera. There is a guided interface to manually transcribe a seed into the SeedQR format for instant seed loading, BIP39 passphrase support, which is the optional thirteenth or twenty-fifth word, an optimised word entry interface for importing an existing phrase, and partial support for Electrum Segwit seed phrases.

On wallets and signing, the script types are Taproot, native segwit, nested segwit and legacy p2pkh, there is single sig and multisig xpub export, support for user-defined custom derivation paths, and an in-depth transaction, meaning PSBT, review flow before signing. That last one is the feature that matters most for a device whose entire purpose is to be trusted, and it is reinforced by the ability to verify the PSBT's single sig or multisig change outputs or self-transfer outputs, which is how a wallet that silently redirects your change is caught. Mainnet, testnet and regtest are all supported.

The additional utilities are the sort of thing a security device accumulates over years: SettingsQR to reconfigure a device for beginners, advanced users or your own preferences instantly, the ability to scan a software wallet's receive or change address to check that it is correct, an Address Explorer for single sig and multisig wallets, message signing to prove address ownership, and BIP85 child seed generation.

The compatibility list is the usual suspects of the ecosystem, Sparrow, Nunchuk, Keeper, BlueWallet and Specter Desktop, plus any wallet software that supports QR codes.

The repository, the dependencies and the developer loop

The source tree is organised around the same concerns as the device. There is `src/` for the firmware, `tests/`, `docs/` for the user documentation including the dice verification guide, the Electrum notes and the legacy hardware notes, `enclosures/` for the case designs, `l10n/` for the translations, `tools/` and `docker/` for the development environment, and `seedsigner-screenshots/` for the images.

The dependency files are the most interesting engineering artefact. `requirements.txt` explains that the entries are pinned and hash-locked, so that pip refuses any artefact that does not match the hash, with the hashes covering every published file of each release, the wheels and the sdist, and the procedure for updating a pin being to change the version and then refresh the hashes from the PyPI JSON endpoint.

Two entries are handled specially. `pyzbar` and `urtypes` point at commit-pinned GitHub source archives rather than `git+` URLs, because pip's hash-checking mode cannot verify a git checkout but can verify the archive tarball built from the same commit. And there is a note that a hash-locked file may share a `pip install` invocation only with other fully hashed files, since any hash in an invocation makes pip require hashes for everything in it.

For a project that signs Bitcoin transactions, hash-locking every dependency is the right level of paranoia, and the comments explain the reasoning so the next person does not undo it by accident.

The coverage configuration in `pyproject.toml` is also candid. It excludes debug-only code, defensive assertions, abstract methods and the main guard from the report, and it omits the modules with hardware dependencies, the camera, the video stream and the specific display drivers, with a comment that a different approach is needed to test those modules. The project requires Python 3.10 or later, and the development loop runs in a container through a compose file that builds a dev image and runs the setup script.

Where this is the wrong choice

The first wrong case is a single signature wallet with a phone. A signing device earns its cost in a multisig setup, where the risk of one machine being compromised is what the device mitigates. For a single sig wallet on a phone you have already accepted the risk, and the device adds hardware, a QR exchange and a learning curve for no gain.

The second is a workflow that needs speed. Every transaction is a camera scan and a screen display, and a user who transacts often will feel that. The design accepts the friction as the price of the property, which is a reasonable position for a cold storage device and a bad one for a daily wallet.

The third is a builder who is not prepared to verify. The whole trust argument rests on the image being the one you think it is, and if you are going to take the published image on faith, then the reproducible build, the build instructions in the separate OS repository and the invitation to share your own hash are the parts you have skipped. The project's own framing is that you can verify the released images byte for byte against a build from source, and the value of the device is that you can.

The fourth is a hardware constraint. The 240x240 display requirement is exact, the camera sensor matters for the enclosures, and the Pi Zero 1.3 is the recommended board for a reason. A builder who buys a lookalike screen will find that it does not work, and the README says so twice.

On the state of the project, the current version is 0.8.7, the last push was on 2026-10-07, the repository is not archived, and the licence is MIT with the code, the documentation and the wiki all under the same terms. The project also publishes a SECURITY.md, which is the file to read if you find a problem in a device that holds money.

Editorial conclusion

Adopt SeedSigner if you are running a multisignature Bitcoin setup and you want a signing device whose trust story you can verify, since the hardware has no radio, the seeds live in memory only while the device is powered, and the release images are reproducible so you can confirm byte for byte what you installed. Do not adopt it if you need a phone application or a desktop wallet with a screen and a keyboard, because the whole design is a minimal device with a small display and a camera. Verify first that your Pi Zero model has no WiFi or Bluetooth, that your display is genuinely the 240x240 Waveshare panel since the lookalike boards are not compatible, that you can build the release image yourself and compare the hash before you trust a published one, and that your own workflow can tolerate the QR exchange being the only way to move data in and out.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. SeedSigner/seedsigner on GitHub