Open Source Hardware Wallets: Why They Matter

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 verify that the compiled binary running on the device matches 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 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 analysis of Bitcoin wallet architecture.

Levels of Openness

Fully open (firmware + hardware): Both the firmware source code and the hardware schematics are published. Anyone can audit the complete system. Examples include Blockstream Jade, Foundation Passport, and SeedSigner. This is the highest level of transparency. Manufacturing the device from published designs is theoretically possible, eliminating single-vendor dependency.

Partially open (firmware only): The firmware is published and auditable, but the hardware designs are proprietary or only partially documented. The Coldcard MK4 falls into this category — its firmware is on GitHub, but the full hardware design is not published. Users can verify the software behavior but must trust the hardware implementation.

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 Common Criteria EAL5+) 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. This is not a theoretical concern. The Ledger Recover incident demonstrated that a firmware update could add seed phrase export functionality to a hardware wallet. Because Ledger’s secure element firmware is closed-source, users had no way to detect this capability before it was announced. With open-source firmware, such a change would be visible in the code diff of every update, and the community would flag it immediately.

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 what the manufacturer ships on the device. 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, and the firmware interfacing with it remains open source — proving that secure element integration does not require closed-source code. Trezor Suite, the companion app, is also open source.

Coldcard MK4 and Q

Coinkite’s Coldcard line runs open-source firmware published on GitHub (Python-based, running on an STM32 MCU). The firmware handles all user-facing operations, with the Microchip ATECC608B secure elements providing key storage and PIN enforcement. The hardware is partially documented — enough for community review of the architecture, but not full manufacturing-ready schematics. The Coldcard Q model (with a QWERTY keyboard and larger screen) shares the same open-source firmware base. For details on setting up a Coldcard, see our seed phrase security guide.

Blockstream Jade and Jade Plus

Blockstream’s Jade is fully open source in both firmware and hardware. The hardware schematics and PCB designs are published under open licenses. The firmware is on GitHub and uses a unique “virtual secure element” approach — instead of a dedicated secure element chip, Jade uses a blind oracle protocol where the device communicates with a Blockstream server (or self-hosted server) during PIN unlock to provide equivalent security properties. This is a creative solution that avoids the NDA issues of traditional secure element chips. The Jade Plus improves on the original with a larger screen and camera for QR-based air-gapped operation.

Foundation Passport

Foundation Devices builds the Passport with an explicit commitment to transparency. The firmware is published under the MIT license. The hardware is published under the CERN Open Hardware License (CERN OHL), one of the most permissive hardware licenses available. The Passport uses a Microchip ATECC608A 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.

BitBox02

Shift Crypto’s BitBox02 has open-source firmware and hardware. The firmware is written in C and Rust, published on GitHub, and has undergone multiple independent security audits (including by Consulintel and Census Labs). The hardware schematics are published. The BitBox02 uses an 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

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 incident demonstrated why: functionality that users never requested and many actively opposed was added to the secure element firmware, and users had no visibility into it. 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 eliminate this gap. When a user or researcher compiles the code and gets the same binary hash as the official firmware, they have strong assurance that the published source is what is actually running on the device.

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
• Blockstream Jade supports reproducible builds with documented build environments
• Foundation Passport has invested in reproducible build infrastructure

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 (2019): Researchers at Kraken Security Labs discovered a voltage glitching attack on the Trezor One’s STM32 microcontroller that could extract the seed in about 15 minutes of physical access. This was disclosed responsibly, and while it could not be fixed in hardware on existing devices (the MCU’s susceptibility is a hardware limitation), it drove Trezor to add a secure element in the Safe 3, and it informed users about the importance of a BIP39 passphrase as a mitigation. The attack was only possible to develop and verify because the firmware was open source.

Coldcard’s PSBT parsing issues: Community reviewers identified edge cases in Coldcard’s PSBT handling code that could theoretically allow specially crafted transactions to display misleading information on the device screen. These were patched before any known exploitation. The fixes were visible in the public commit history, allowing users to verify both the vulnerability and the fix.

BitBox02’s anti-klepto implementation: The BitBox02 implemented the anti-klepto 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 verify that the protocol was correctly implemented and that the device was not vulnerable to this class of nonce-based exfiltration.

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 Foundation Passport and Blockstream Jade 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 hash with the hash of the firmware on your device. Most wallets display the firmware hash in their settings or can output it via a command. If the hashes match, the firmware on your device is exactly what the source code says. 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.

For a broader perspective, explore our hardware wallet buying guide guide.

{“@context”: “https://schema.org”, “@type”: “FAQPage”, “mainEntity”: [{“@type”: “Question”, “name”: “Does open source mean anyone can hack the wallet?”, “acceptedAnswer”: {“@type”: “Answer”, “text”: “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 j…”}}, {“@type”: “Question”, “name”: “If I build a SeedSigner myself, is it as secure as a commercial wallet?”, “acceptedAnswer”: {“@type”: “Answer”, “text”: “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 fac…”}}, {“@type”: “Question”, “name”: “Why do some manufacturers keep their hardware designs closed even when firmware is open?”, “acceptedAnswer”: {“@type”: “Answer”, “text”: “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 proj…”}}, {“@type”: “Question”, “name”: “How do I verify that my hardware wallet is running the firmware it claims?”, “acceptedAnswer”: {“@type”: “Answer”, “text”: “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 hash with the hash of the firmware on your device. Most wallets display the firmware hash in their settings or can output it via a command. If the hashes match, the firmware on your device is exactly what the source code says. For wallets without reproducible builds, you are trusting the manufactur…”}}]}