Open Source Hardware Wallets: Why They Matter for Bitcoin Security
Bitcoin was born from open-source code. The protocol, the reference implementation, and the cryptographic libraries it depends on are all publicly auditable. But when it comes to the devices that store private keys — hardware wallets — the open-source principle is not universal. Some manufacturers publish everything. Others keep critical components proprietary. The difference matters more than most users realize.
What “Open Source” Means for Hardware Wallets
A hardware wallet has multiple layers, and each can be open or closed independently:
Firmware: The software running on the wallet’s microcontroller and/or secure element. This is the most critical layer because the firmware handles key generation, seed storage, transaction signing, and display output. Open-source firmware means anyone can read the code, audit it for vulnerabilities, and, with a reproducible build, check that the official firmware file was built from the published source.
Hardware designs: The schematics, PCB layouts, and component specifications for the physical device. Open hardware means you can verify what chips are on the board, how they are connected, and whether the design matches the manufacturer’s claims. With fully open hardware, a third party could theoretically manufacture the same device independently.
Companion apps: The desktop or mobile software used to interface with the hardware wallet (like Ledger Wallet, formerly Ledger Live; Trezor Suite; or the Sparrow Wallet integration). These apps handle address generation for display, transaction construction, and communication with the Bitcoin network. Open-source companion apps let users verify that the software is not leaking data or substituting addresses.
A wallet can be open at one layer and closed at another. Understanding where the openness begins and ends is essential for evaluating the actual trust model. For a broader view of how these layers interact, see our lesson Hardware Wallets Explained.
Levels of Openness
Fully open (firmware + hardware): Both the firmware source code and the hardware schematics are published. Anyone can audit the device’s own code and circuit design, though not the inside of the chips on the board, such as a secure element, which remain their makers’ closed designs. Examples include Blockstream Jade, SeedSigner, and Foundation’s Passport Core (no longer sold). This is the highest level of transparency. Manufacturing the device from published designs is theoretically possible, eliminating single-vendor dependency.
Published with limits: The code is published and auditable, but its licence restricts what you may do with it. Coldcard is the main example: Coinkite publishes all of its firmware source, plus schematic diagrams and parts lists for the Mk4, Mk5 and Q, but the firmware licence (MIT with a “Commons Clause” that forbids selling it) makes it source-available rather than open source in the strict sense. Anyone can still read and build the code.
Closed source: The firmware running on the security-critical components is not published. Ledger is the primary example — the firmware on its secure element is proprietary. Users must trust the manufacturer and any third-party certifications (like the Common Criteria EAL5+ or EAL6+ ratings of Ledger’s chips) rather than verifying the code themselves.
Why Open Source Matters for Security
Community Audits
Open-source firmware gets reviewed by people who are not on the manufacturer’s payroll. Independent security researchers, competing wallet developers, and paranoid Bitcoin holders all examine the code. This diversity of reviewers catches issues that internal teams miss — not because internal teams are incompetent, but because they operate within the same set of assumptions and blind spots. Outside reviewers bring different perspectives, different threat models, and different motivations.
The Linux kernel, OpenSSL, and Bitcoin Core itself have all benefited enormously from this dynamic. Bugs that persisted for years in closed-source software were found quickly when the code was opened to public review. Hardware wallet firmware is far less complex than an operating system, making thorough community review genuinely achievable.
No Hidden Backdoors
With open-source firmware, a manufacturer cannot insert a backdoor without it being visible in the code. Ledger Recover (2023) showed why this matters. It is an optional paid service that, if you sign up and approve it on the device, encrypts your seed and splits it among three companies. Critics argued it showed that Ledger’s firmware can be updated to export a seed; Ledger replied that it is opt-in and needs your PIN and approval. In principle any hardware wallet’s firmware could be changed to export a seed. The difference is what you can check: Ledger’s operating system is closed, so outsiders could not read how the feature works, while with open-source firmware such a change would be visible in the code of every update.
This does not mean open-source wallets are immune to supply chain attacks or compromised builds. It means there is a mechanism for detection that does not exist in the closed-source model.
Verifiable Builds
Open source enables reproducible builds — the ability to compile the published source code and verify that the resulting binary matches exactly the official firmware file the manufacturer distributes. Without reproducible builds, a manufacturer could publish clean source code while shipping modified binaries. Reproducible builds close this gap and are a critical complement to open-source publication. We discuss this in more detail below.
The “Trust but Verify” Principle in Bitcoin
Bitcoin’s culture is built on verification rather than trust. Running a full node verifies the blockchain instead of trusting a third party. Checking transaction signatures verifies ownership instead of trusting a sender’s claim. This principle extends naturally to hardware wallets: if you can verify the code that guards your keys, you should. If you cannot, you are trusting instead of verifying, regardless of what certifications or reputations the manufacturer holds.
This does not mean closed-source wallets are insecure. It means they require a different trust model — one that relies on the manufacturer’s integrity and on third-party auditors rather than on direct verification. For users holding significant Bitcoin, understanding which trust model applies to their device is essential. Our article on Bitcoin self-custody explores how these trust decisions shape overall security posture.
Open Source Hardware Wallets: The Current Landscape
Trezor (Safe 3, Safe 5)
Trezor pioneered the hardware wallet market in 2014 and has been open source from the start. The firmware for all Trezor devices is published on GitHub and has been extensively reviewed. The hardware designs and schematics are also published. The Safe 3 and Safe 5 added an Infineon Optiga Trust M secure element; the chip itself is not open source, but all of Trezor’s code that talks to it is — proving that secure element integration does not require closed-source wallet code. The Safe 7 adds a second chip, TROPIC01, which Trezor presents as an independently auditable secure element. Trezor Suite, the companion app, publishes its source code too, under Trezor’s own reference licence, which lets you read it but not redistribute it.
Coldcard Mk5 and Q
Coinkite’s Coldcard line runs firmware whose full source is published on GitHub (MicroPython-based, running on an STM32 MCU), under the MIT licence with a “Commons Clause” that forbids selling it: source-available rather than open source in the strict sense. The firmware handles all user-facing operations, while two secure elements from different vendors (Microchip ATECC608 and Maxim DS28C36B) protect the seed and enforce the PIN. Coinkite publishes schematic diagrams and parts lists for the Mk4, Mk5 and Q in the same repository. The Mk5 replaced the Mk4 in March 2026, and the Coldcard Q (with a QWERTY keyboard and larger screen) shares the same firmware base. Public code didn’t prevent the July 2026 seed-generation flaw (see our Coldcard advisory), but it let outside researchers analyse it. For details on setting up a Coldcard, see our Coldcard setup guide.
Blockstream Jade and Jade Plus
Blockstream’s Jade is open source in both firmware and hardware: Blockstream publishes the firmware under open-source licences and the hardware design files for both models on GitHub. Jade uses a unique “virtual secure element” approach — instead of a dedicated secure element chip, it relies on a blind oracle protocol in which the device reaches a Blockstream server (or a self-hosted one), through your companion app, during PIN unlock, so that neither the device nor the server alone can unlock the keys. This is a creative solution that avoids the NDA issues of traditional secure element chips, at the cost of normally needing that server to unlock. Both models have a camera for QR-based air-gapped operation; the Jade Plus (January 2025) adds a larger screen and a better camera.
Foundation Passport Core (no longer sold)
Foundation Devices built the Passport with an explicit commitment to transparency. The firmware is published under GPLv3 (with some parts under MIT and other compatible licences). Passport’s circuit designs are published under the CERN-OHL-S v2, a copyleft open hardware licence that requires changes to be shared under the same terms. The Passport uses a Microchip ATECC608 secure element with open-source firmware interfacing. The device runs on a STM32H7 processor and features a camera for QR-based air-gapped operation. Foundation also publishes their security model documentation and threat analysis. Foundation announced in March 2026 that it had discontinued the Passport Core, and says it remains supported with security updates; it now sells the Passport Prime, which we have not reviewed.
BitBox02
The BitBox02, from Shift Crypto (which trades as BitBox), has open-source firmware and hardware. The firmware is written in C and Rust, published on GitHub under the Apache 2.0 licence, and has been independently audited (BitBox names Census Labs). The hardware schematics are published. The BitBox02 uses a Microchip ATECC608B secure element for additional attestation and key derivation. The companion app (BitBoxApp) is also open source. The Bitcoin-only edition removes altcoin support entirely, reducing the attack surface.
SeedSigner
SeedSigner is a fully DIY project — a stateless Bitcoin signing device built from off-the-shelf components (Raspberry Pi Zero, camera module, LCD screen). The entire software stack is open source. There is no “manufacturer” — users build it themselves from published instructions and source code. SeedSigner does not store keys; it generates or imports them at each session and signs PSBTs via QR codes. It represents the far end of the openness spectrum: you build the hardware, you compile the software, and you verify everything yourself. The tradeoff is usability and the absence of a secure element.
Comparison Table
| Wallet | Firmware Open Source | Hardware Open Source | Reproducible Builds | Independent Security Audits |
|---|---|---|---|---|
| Trezor Safe 3 / Safe 5 | Yes | Yes | Yes | Multiple (including original by Kudelski) |
| Coldcard Mk5 / Q | Source-available (MIT + Commons Clause) | Schematics and parts lists | Yes | Community review, NVD disclosures |
| Blockstream Jade / Jade Plus | Yes | Yes | Yes | Community review; DARKNAVY bug report (fixed in 2025) |
| Foundation Passport Core (no longer sold) | Yes (GPLv3) | Yes (CERN-OHL-S v2) | Yes | Community review |
| BitBox02 | Yes | Schematics and parts list | Yes | Census Labs |
| SeedSigner | Yes | N/A (off-the-shelf parts) | Yes | Community review |
| Ledger (Nano, Stax, Flex) | No (secure element firmware) | No | No | CC EAL5+ / EAL6+ chip certification; Ledger’s in-house Donjon team |
Closed-Source Examples and the Trust Tradeoff
Ledger is the dominant example of the closed-source approach. The argument for closed-source secure element firmware is that the security of the chip depends partly on the obscurity of its internal operations. Publishing the firmware, the argument goes, would give attackers a detailed map for crafting side-channel attacks or fault injection strategies.
There is some technical merit to this. Secure elements are designed to resist known attack classes, and obscuring the specific countermeasure implementations adds a layer of difficulty. However, security through obscurity is not a primary defense — it is a supplementary one. The cryptographic operations themselves do not benefit from secrecy, and the key management logic (how seeds are generated, stored, and exported) should be auditable regardless. The Ledger Recover debate showed why: when Ledger announced an opt-in service that can export an encrypted copy of the seed, users had to take Ledger’s word for how it worked, because they could not read the code that runs on the secure element. For a deeper dive into these attacks, see our article on side-channel attack risks in cryptocurrency hardware.
Reproducible Builds Explained
Open-source code alone is not sufficient for full verifiability. The final link in the chain is reproducible builds — the ability for anyone to compile the source code and produce a binary that is byte-for-byte identical to what the manufacturer distributes.
Without reproducible builds, a manufacturer could publish pristine source code on GitHub while shipping different (potentially compromised) binaries on actual devices. Reproducible builds close this gap for the files the maker distributes. When a user or researcher compiles the code and gets the same binary hash as the official firmware file, they have strong assurance that the official release was built from the published source. Whether the device in your hand is running that release is a separate check, made by the device’s signature check and, on some devices, a firmware hash check (see the FAQ below).
Achieving reproducible builds is technically challenging. Compilers, linker settings, library versions, and build environments must all be precisely controlled. Several projects now achieve this:
- Trezor provides reproducible builds via Docker containers with pinned toolchain versions
- BitBox02 publishes reproducible build instructions and Docker environments
- Coldcard automates its reproducible build with Docker and reports whether the result matches the official release byte for byte
- Blockstream Jade supports reproducible builds with documented build environments
- SeedSigner has published reproducible release images since version 0.7.0
- Foundation Passport provides a Docker build and a command to check the firmware hash against a published one
If a hardware wallet project claims to be open source but does not offer reproducible builds, there is a verification gap. The source code is auditable, which is valuable, but the connection between the source code and the firmware on your device is based on trust rather than verification. Our article on firmware updates and security discusses how reproducible builds interact with the update process.
Real-World Impact: Vulnerabilities Found Thanks to Open Source
The value of open-source firmware is not theoretical. Multiple significant vulnerabilities have been discovered by community researchers because the code was available for review:
Trezor’s MCU vulnerability (disclosed January 2020): Researchers at Kraken Security Labs showed a voltage glitching attack on the STM32 microcontroller of the Trezor One and Model T that could extract the encrypted seed in about 15 minutes of physical access. It was disclosed responsibly to Trezor first. It could not be fixed in software on existing devices (the chip’s susceptibility is a hardware limitation), so Trezor pointed users to a BIP39 passphrase as the mitigation. Its newer Safe models keep the PIN and secrets behind a secure chip, so glitching the main chip of a locked device no longer gives up the seed. The main chip can still be glitched, though: in March 2025 Ledger’s security team, Donjon, did so to get past the Safe 3’s firmware check, which matters if someone tampers with a device before it reaches you. Buy from the maker’s own store.
Coldcard’s multisig change check (fixed December 2019): Dmitry Petukhov, a developer building the Coldcard into his own software, found that its firmware did not read multisig scripts strictly enough: a man-in-the-middle (such as malware on the computer that prepares the transaction) could dress up an output it controlled as your own change and take it when you used multisig. Coinkite fixed it in firmware 3.0.6, added change addresses to the confirmation screen as an extra check, and reported no evidence that anyone exploited it. When the details went public in March 2020, his write-up quoted the exact lines of the public multisig code that skipped the check.
BitBox02’s anti-klepto implementation: The BitBox02 (and, separately, the Blockstream Jade) implemented the anti-klepto, or “anti-exfil”, protocol to prevent the device from leaking key material through biased nonce generation (the type of attack known as Dark Skippy). Because the implementation was open source, researchers could check that the protocol was correctly implemented. It only protects you when the wallet app runs the check on a computer or phone that isn’t compromised too, and as of November 2026 not for Taproot (bc1p) signatures.
These examples illustrate a pattern: open source does not prevent vulnerabilities, but it provides the mechanism for finding and fixing them before they are exploited. Closed-source firmware may have equivalent or worse vulnerabilities that remain undiscovered because nobody outside the company can look at the code.
The Future of Open Source Hardware Wallets
The trend is moving toward more openness, not less. Several developments point to where the industry is heading:
Secure elements with open-source compatibility: The argument that secure elements require closed-source firmware is weakening. Trezor’s integration of the Optiga Trust M, Jade’s virtual secure element approach, and Foundation’s open-source secure element interfacing all demonstrate viable paths to hardware security without code secrecy. As more chips designed for open-source integration become available, the NDA argument will lose its remaining force.
Reproducible builds as a standard expectation: A few years ago, reproducible builds were an aspirational goal. Now multiple projects achieve them, and users increasingly expect them. The tooling for reproducible builds (Docker, Nix, Guix) is maturing, lowering the barrier for new projects.
DIY and community-built devices: Projects like SeedSigner have proven that a functional Bitcoin signing device can be built from commodity hardware and fully open-source software. While DIY devices lack the polish and secure element protection of commercial products, they demonstrate that Bitcoin signing does not require vendor trust at all. This serves as a check on commercial manufacturers — if they become too opaque, users have alternatives.
Growing security literacy in the Bitcoin community: Bitcoin users are increasingly educated about supply chain risks, firmware trust models, and the limitations of closed-source security. This market pressure pushes manufacturers toward transparency. Ledger’s announcement of an open-source roadmap (however slowly executed) was a direct response to community demand following the Recover controversy.
For users evaluating their custody setup, the openness of the hardware wallet they choose is one factor among many — alongside physical security, usability, multisig support, and vendor track record. But it is a factor that deserves weight, because it determines whether your security is based on verification or trust. Building a security model that uses hardware diversity across multiple vendors in a multisig configuration can reduce dependence on any single manufacturer’s trust model, open or closed.
Frequently Asked Questions
Does open source mean anyone can hack the wallet?
No. Publishing source code does not make a device less secure. The cryptographic security of a hardware wallet depends on the strength of its algorithms and key management, not on the secrecy of its code. AES, SHA-256, and elliptic curve cryptography are all public algorithms, and their security comes from mathematical properties, not obscurity. Open source means anyone can look for vulnerabilities, which means they get found and fixed faster. Closed-source code has just as many bugs — they just take longer to find, and they may be found by attackers before defenders.
If I build a SeedSigner myself, is it as secure as a commercial wallet?
It depends on your threat model. A SeedSigner does not have a secure element, so it is more vulnerable to physical extraction attacks if someone gains access to the device while keys are loaded. However, SeedSigner is designed to be stateless — keys are not stored on the device between sessions. For an attacker to extract keys, they would need physical access during the brief window when the device is powered on and keys are loaded in RAM. For users who prioritize verifiability and do not face significant physical theft risk, a SeedSigner can be part of a strong security setup, especially as one key in a multisig configuration.
Why do some manufacturers keep their hardware designs closed even when firmware is open?
Hardware openness has different economics than software openness. Publishing full schematics and PCB layouts makes it easy for competitors (particularly low-cost manufacturers) to produce clones. Some companies keep hardware designs partially closed as a business protection while opening the firmware for security auditing. This is a pragmatic compromise — the firmware is where the security-critical logic lives, and opening it provides most of the auditability benefit. Fully open hardware projects like Blockstream Jade and Foundation’s Passport Core accept the cloning risk as a tradeoff for complete transparency.
How do I verify that my hardware wallet is running the firmware it claims?
For wallets with reproducible builds, download the source code, set up the build environment (usually a Docker container provided by the project), compile the code, and compare the resulting binary’s hash with the hash of the official firmware file, setting the maker’s signature aside as the project’s instructions explain. If the hashes match, the official firmware is exactly what the source code says. Your device then checks the maker’s signature on every update, and some devices also let you check the firmware they are running: Trezor Suite runs a firmware hash check each time you connect a Trezor that has the latest firmware, and a BitBox02 can show its firmware hash at startup. For wallets without reproducible builds, you are trusting the manufacturer’s signature on the firmware update. Our guide on firmware updates and security best practices walks through this process for several popular devices.
