Ask around any Bitcoin forum and you'll be told the same thing within about four replies: buy an open source hardware wallet, because closed code is code you can't check. It's a reasonable instinct, and we won't argue against it here. What we will do is take it apart, because "open source" describes three separate layers of a signing device and almost no wallet is open across all of them, and because the largest hardware wallet theft of 2026 happened to a device whose code anyone could read.
Open means three different things at once
A hardware wallet is a stack. At the bottom sits a chip that stores your keys and performs the signing. Above it runs firmware, the software that draws the screen, builds transactions, and decides what the button does. Beside both sits a companion app on your phone or laptop that talks to the outside world.
Trezor is the strongest case for openness because it publishes at every level. Its firmware has been public for years, and the Safe 7 added TROPIC01, a secure element whose hardware design, firmware and specification are published rather than hidden behind the non-disclosure agreements that normally cover certified chips. Whatever you make of the price, that's the first time an open secure element has shipped in a product you can buy in a shop.
Ledger sits at the other end and is more mixed than the shorthand suggests. The device firmware is closed, which is the point critics keep hitting, while Ledger Live is published on GitHub and the certified chip inside comes with the same vendor secrecy every EAL6+ part carries. Ledger's argument is that opening a secure element's internals hands attackers a map; Trezor's argument is that secrets in a design are weaknesses waiting to be found. Our own read on how that comparison usually gets flattened is in Trezor vs Ledger in 2026.
Then there's a middle category people miss. Coldcard's firmware is source-available rather than open source: since November 2020 it has been licensed under MIT plus a Commons Clause that removes the right to sell software built on it commercially. You can read every line. What you cannot do is fork it into a competing product, and that difference shapes who bothers to read it at all.
The Coldcard case: readable is not reviewed
In March 2021, Coinkite shipped Coldcard firmware version 4.0.1 carrying a build configuration error. A macro was defined and then set to zero, a preprocessor guard only checked the first half of that condition, and the build concluded the hardware random number generator was wired up when it had quietly fallen back to a software source instead. Seeds generated on affected Mk3 devices came out with something like 40 bits of entropy rather than 128, which moves a private key from unguessable to brute-forceable on ordinary computers.
Nobody noticed for five years and four months. Then, starting on 30 July 2026, attackers drained roughly 1,816 BTC from more than 5,200 addresses across four waves, a figure TRM Labs put at about 116 million dollars and the largest hardware wallet exploit of the year. The wallets never touched the internet. The keys were computed. Coinkite has since said it believes the attacker used AI to find the flaw, and that its own review of the same code weeks earlier came back clean. We wrote the incident up in detail in The Coldcard Entropy Incident, Explained.
The uncomfortable conclusion is that public code and reviewed code are separate properties, and the second one is much rarer than the first. Thousands of people could have found that bug. None did, for five years, until someone with the wrong intentions went looking.
What open source does buy you
Plenty, and we don't want to leave the wrong impression. Published firmware means an independent researcher can audit without permission, a determined owner can build the firmware themselves and compare the result against what the vendor shipped, and a company that disappears tomorrow leaves behind something the community can maintain. It also removes a class of argument entirely: when a vendor claims their device does X, you can go and look.
The TROPIC01 story shows the mechanism working the way it should. Ledger's security lab, Donjon, ran an independent audit of a competitor's open chip design, found a laser fault-injection weakness, and reported it. Trezor published what happened alongside its assessment that funds were never at risk. A rival team was able to look closely enough to find something, and the finding reached owners rather than an exploit market.
What it doesn't buy you
Four things, and each of them has cost people money.
Open code doesn't prove you're running it. Unless the vendor supports reproducible builds and you check the hash yourself, the binary on your device is still something you're trusting on faith. Open code doesn't mean anyone competent has read the part that matters, as Coldcard demonstrated at scale. Open firmware says nothing about the chip beneath it unless the chip is open too, which until recently no shipping consumer device offered. And none of it touches the supply chain: a counterfeit device running modified firmware doesn't care what licence the original carries.
The fourth gap is the one we care about most, and it has nothing to do with source code. Whatever device you choose, your recovery is a set of words on an object in a location, and no licence protects that object from a house fire.
Where we stand, plainly
RyderOS isn't open source. We'd rather say that directly than let a comparison table imply otherwise, and if published firmware is your hard requirement then Trezor and BitBox are the honest recommendations to look at first.
What stands in its place is a certified chip and an outside audit anyone can read. The Ryder One uses an Infineon SLC38 secure element certified to EAL6+, with keys generated inside the chip that never leave it, and our firmware was independently audited by Halborn with the full report published rather than summarised in a press release. That's a different answer to the same question openness is trying to solve, which is how a stranger checks a claim they cannot personally verify. We've written more on judging that layer in Hardware Wallet Firmware.
The question underneath the licence debate
Every wallet in this article, open and closed alike, hands you the same homework at the end of setup. Write down the words. Keep them somewhere that survives you being careless, unlucky or absent. That single object is where most self-custody stories go wrong, and no amount of published code changes it.
TapSafe Recovery is our attempt at removing that object rather than hardening it. Recovery splits across a Recovery Tag holding half of what's needed and your paired phone holding the other half, encrypted into your own iCloud or Google Drive instead of sitting on the handset, so losing either piece alone costs you nothing and stealing either piece alone gets a thief nowhere. Recovery Contacts are optional, hold a quarter each, learn nothing about your balances, and are added in person with a tap. It runs on a custom implementation of Shamir's Secret Sharing, and your seed phrase remains available on the device as a last resort under the BIP-39 standard, so you keep the exit and can leave for another vendor whenever you like.
How to use the open source question when you're shopping
Treat it as one input rather than the deciding one. Ask what specifically is published, since firmware, chip and app are three answers and vendors quote whichever is flattering. Reproducible builds are the follow-up question, because publishing source without them is a promise rather than a check. From there, find out who has audited the device recently and whether you can read the report yourself. The last question is the one a licence never answers: what happens to your coins if the device and everyone who knows about it are unavailable on the same day.
If the last answer is a piece of paper in a drawer, that's the thing to fix first. Get your Ryder One.
Share: