An open-source hardware wallet is one whose firmware, bootloader, and ideally hardware schematics are published so that anyone can inspect, audit, and independently rebuild the code that protects private keys. This matters because closed-source signing devices ask you to trust a vendor's claims without the ability to verify them. Open source shifts that trust from a company's reputation to publicly reviewable, reproducible engineering.
Every hardware wallet sits at the most sensitive point in your security model: it holds the private keys and produces the cryptographic signatures that authorize on-chain transactions. When the firmware running on that device is closed, you depend entirely on the vendor's word that no exfiltration routine, backdoor, or key-leaking side channel exists. You cannot verify. You can only trust.
Open-source firmware eliminates that dependency. Any security researcher, cryptographer, or motivated user can read the signing logic, the key-derivation paths, the random-number generation calls, and the communication protocol between the device and the host wallet. Bugs get found by the community, not just by a single internal team.
The trade-off is real, though. Publishing source code also lets attackers study it. The counter-argument, well established in cryptographic engineering, is Kerckhoffs's principle: a system should remain secure even when everything except the secret keys is public knowledge. A hardware wallet whose security depends on obscurity has a fragile foundation.
Even the most open hardware wallets rely on commercial secure-element silicon whose internal design is not published. The chip vendor submits the silicon to Common Criteria evaluation (EAL5+, EAL6+, or similar), and independent labs test it against defined attack classes. That evaluation certificate is the trust anchor for the chip layer. Open source covers the firmware and applet running on that chip, not the transistor layout underneath.
These three terms are often conflated. They represent distinct, escalating levels of assurance.
The limitation is effort. Most users will never compile firmware or inspect a PCB. Reproducibility matters because it lets a smaller group of auditors verify on behalf of the wider community, and anyone who wants to can repeat the process.
Keycard demonstrates what a fully open approach looks like in practice. The Keycard smartcard applet (running on an NXP JCOP4 P71 secure element, EAL6+ certified at the chip level) is published on GitHub under keycard-tech. The Keycard Shell, an air-gapped signing device with a camera, display, and QR-based transaction flow (ERC-4527 / BC-UR), goes further: its firmware, bootloader, hardware schematics, BOM, and 3D enclosure files are all MIT-licensed and publicly available.
Shell firmware supports reproducible builds using CMake and Python tooling. Anyone can clone the repository, compile the firmware, and compare the resulting binary hash against the official release. A pair of scripts (firmware-hash.py and database-hash.py) automate this comparison. The bootloader is write-protected, JTAG-burnt, and open source, which means both the code that runs and the code that verifies new firmware are inspectable.
The Keycard smartcard applet itself is also open source, though its build reproducibility is not yet formally established to the same degree as the Shell firmware. This is an honest distinction: the Shell firmware build is reproducible today, the applet build is a work in progress.
For users who want maximum independence, the system is DIY-buildable. You can purchase a blank JavaCard, compile the Keycard applet from source, install it, and lock the card yourself by randomizing the GlobalPlatform keys, resulting in immutable firmware that you personally verified.