# Specter-DIY: a Bitcoin hardware wallet you assemble and audit yourself > Specter-DIY is a hardware wallet built from off-the-shelf boards, with the firmware mostly in MicroPython so it can be read and changed, and communication with the host over QR codes so the device never has to be plugged in. The secure bootloader exists, but the README is explicit that you install it yourself, which is where the risk sits. **cryptoadvance/specter-diy** — DIY airgapped hardware wallet that uses QR codes for communication with the host - Repository: https://github.com/cryptoadvance/specter-diy - Stars: 590 · Forks: 111 - Language: Python - License: MIT - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/cryptoadvance-specter-diy ## QR codes as the only channel, and why that is the security argument Specter-DIY is a DIY airgapped hardware wallet that uses QR codes for communication with the host, and the reasoning is given plainly in the README. QR codes are a default way for Specter to communicate with the host. They are convenient, and they allow the user to be in control of the data transmission, because every QR code has a very limited capacity and communication happens unidirectionally. And it is airgapped, so you do not need to connect the wallet to the computer at any time. The unidirectional point is the load-bearing one. A USB connection is a pipe, and once a pipe exists the host can send anything to the device and the device cannot tell the difference between a malicious command and a legitimate one. Splitting every message into small chunks that a human chooses to pass along, in one direction at a time, means each chunk has to be individually inspected and the device never accepts a stream. The cost is throughput, and the project accepts it. QR codes are a slow channel, and every transaction has to be serialised in both directions, in pieces small enough to fit in a code that a camera can read. The project opens with the Cypherpunk's Manifesto, and the line about building their own Bitcoin hardware wallets is not decoration. The whole premise is that a signing device whose firmware you can read is worth more than a cheaper device whose firmware you cannot. The supported networks are Mainnet, Testnet, Regtest and Signet, and the primary focus is multisignature setup with other hardware wallets, though the wallet can also work as a single signer. ## Three secret storage modes, and one that is not there yet For secret storage the project supports three modes, and the third one is a promise rather than a feature. Agnostic mode means the wallet forgets all secrets when turned off. Reckless mode stores secrets in the flash of the application microcontroller. And secure element integration is coming soon. Those three names are honest in a way that product documentation rarely is. Agnostic mode is the strongest of the three in one respect and the weakest in another. Nothing persists, so a power cycle is a factory reset, and an attacker who gains access to the flash gets nothing because the keys were never written there. The price is that the device cannot remember anything, so a wallet that needs a stored key to sign has to be re-seeded every time, which is a real operational burden for a device meant to be used. Reckless mode is the opposite trade. The keys are in the flash of the application microcontroller, which means they are readable by anything that can read that flash, and the mode is named for what it is. The secure element is where the project is heading, and it is the answer to the objection that a microcontroller flash is not a safe place for a key. A dedicated secure element holds secrets behind hardware protections that a general purpose microcontroller does not have. There is one more piece of the storage story, the secure bootloader, and the README is careful to distinguish what it does from what it does not do. A secure bootloader that verifies firmware upgrades has been implemented, so that only signed firmware can be uploaded to the device after initial setup. Unlike with commercial signing devices, the bootloader has to be installed manually by the user and is not set in the factory of the device vendor. ## MicroPython firmware, Bitcoin Core's secp256k1, and LVGL The implementation choices are what make the auditability claim credible. Most of the firmware is written in MicroPython, which makes the code easy to audit and change. The elliptic curve work uses the secp256k1 library from Bitcoin Core, and the GUI uses LVGL. To make working with Bitcoin Core easier the project is developing Specter Desktop, a separate small Python Flask server talking to your Bitcoin Core node, and the wallet aims at compatibility with Bitcoin Core where possible, using PSBT for unsigned transactions and wallet descriptors for importing and exporting multisig wallets. The choice of MicroPython over C for the majority of the firmware is the most consequential one. A C firmware is faster and smaller, but the only way to know what it does is to read compiled code, and MicroPython source is readable. For a device whose entire purpose is to hold a key and refuse to sign anything you did not intend, source readability beats raw performance. The repository layout backs this up. There is a boot/ directory, a bootloader directory, src/ for the firmware, f469-disco/ for the board specific code, tools/ for the build helpers, a build_firmware.sh script, a Makefile, a simulate.py for running the firmware on a desktop, a Dockerfile for the reproducible build, manifests/ with the frozen module manifests, and demo_apps/. The simulate.py and the docs/simulator.md page are worth calling out for anyone who wants to develop on this without a soldering iron, since the unit test suite runs on the Unix simulator build. ## Running the tests, and the reproducible build with Docker The test setup is a single make target once the system packages are in place: ``` sudo apt-get update sudo apt-get install libsdl2-dev libffi-dev pkg-config libreadline-dev libgmp-dev build-essential python3 make test ``` The build system will fetch the necessary submodules and compile the simulator before executing the tests. So the same simulator that the tests exercise is the one you can run by hand, which is what makes the test suite worth something for firmware. The reproducible build is documented separately in docs/reproducible-build.md, which describes how to build the initial firmware and upgrade files with the same hash as in the release using Docker. The Dockerfile in the repository root shows what that means concretely. It is pinned to a specific python image by digest, sets the locale, and downloads the ARM embedded toolchain, checking the download against an MD5 checksum provided by ARM before extracting it. The Python requirements are installed with pip3 install --require-hashes against a requirements file that the comment says is generated by pip-compile with hashes, so every transitive dependency is pinned to a recorded hash. Those two details, a digest-pinned base image and hash-pinned Python dependencies, are what turn the build into something a third party can reproduce and check. For a device that holds a key, being able to verify that the firmware you flashed is the firmware the project published is the property that matters, and the roadmap document is explicit that it describes what needs to be implemented before the wallet can be considered ready to use with real funds. The Makefile shows the build matrix in its variables, with a target directory of bin, a board defaulting to STM32F469DISC, a flavor defaulting to SPECTER, separate frozen manifests for the disco, debug and unix builds, and a debug flag. The Linux USB communication section notes that you may need to set up udev rules and add yourself to the dialout group, with details in the udev/ folder. ## The shield boards, and what the documentation folder tells you to read first The project has two shield variants, and the decision between them is a build decision rather than a software one. The idea of the project is to build a hardware wallet from off-the-shelf components. Even though there is an extension board that puts everything in a nice form-factor and helps you to avoid any soldering, the project continues to support and maintain compatibility with standard components. The shield folder has its own README explaining what it looks like and a 3dprinting.md document for printing a case, and the shield-lite folder holds the Specter Shield-Lite overview. The flexibility goal is stated in terms of a different architecture entirely. The project wants to work on any other set of components with minimal changes, and gives the example of a hardware wallet on a different architecture such as RISC-V, with an audio modem as a communication channel. It should be easy to add or change functionality of Specter, and the logical modules are abstracted as much as possible. The docs/ folder is organised as a reading order rather than a reference dump, and the sequence tells you what the project considers important. shopping.md explains what to buy, assembly.md shows how to put everything together, quickstart.md guides you through getting firmware onto the board, reproducible-build.md covers the Docker build with matching hashes, and build.md describes building the firmware and the simulator yourself. Then the security documents, which are the ones to read before trusting the device with money. security-model.md explains possible attack vectors and the security model of the project, SECURITY.md describes how to report vulnerabilities under the disclosure policy, and roadmap.md explains what needs to be implemented before the wallet can be considered ready to use with real funds. communication.md defines the protocol with the host over QR codes and USB, development.md explains how to start developing, and simulator.md shows how to run the simulator on unix and macOS. The project is MIT licensed, the last push was on 2026-10-07, and the recent releases are v1.9.0 from 2024-05-30, v1.10.3 from 2026-05-01 and v1.10.5 from 2026-09-06. ## Conclusion Specter-DIY suits someone who wants to understand exactly what their signing device does and is prepared to solder, flash and audit the firmware, since the MicroPython codebase and the reproducible build are the point rather than a side effect. It does not suit you if you want a product you can buy and trust, because the secure bootloader has to be installed by the user and the README tells you to pay extra attention during that step. Before you use real funds, read docs/roadmap.md for what is still outstanding, follow docs/reproducible-build.md so the firmware you flash matches the published hash, and confirm the secret storage mode you are relying on, since agnostic mode forgets everything when the device is powered off. ## FAQ ### How does Specter-DIY communicate with the host computer? Over QR codes by default. Communication is unidirectional, every code has a very limited capacity, and the user is in control of the data transmission, so the device is airgapped and never has to be connected to the computer. ### What secret storage modes does Specter-DIY support? Agnostic mode, where the wallet forgets all secrets when turned off, reckless mode, which stores secrets in the flash of the application microcontroller, and secure element integration, which is described as coming soon. ### How do I run the Specter-DIY test suite? Install the system packages with apt-get, then run the make test target. The build system fetches the necessary submodules and compiles the simulator before executing the tests, and the simulator can also be run by hand for development. ### Is the Specter-DIY secure bootloader installed by the vendor? No. The README states that unlike with commercial signing devices, the bootloader has to be installed manually by the user and is not set in the factory of the device vendor, and it advises paying extra attention during the initial firmware installation, verifying PGP signatures and flashing from a secure computer. ## Sources - [cryptoadvance/specter-diy on GitHub](https://github.com/cryptoadvance/specter-diy) - [Issues](https://github.com/cryptoadvance/specter-diy/issues) - [License: MIT](https://github.com/cryptoadvance/specter-diy/blob/master/LICENSE) - [README](https://github.com/cryptoadvance/specter-diy/blob/master/README.md) - [Releases](https://github.com/cryptoadvance/specter-diy/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/cryptoadvance-specter-diy