In late 2021, I wrote about how hardware wallets give crypto users a false sense of security. The argument was simple: a hardware wallet protects your keys from malware and side-channel memory scraping, but it does nothing against social engineering, malicious message signing, or a scammer talking you into clicking through your own warning screens. I called it adding security to your signature pen — the pen doesn't stop you from signing your assets away if someone convinces you to sign.
Four years later, the recent Coldcard vulnerability disclosure adds a category I didn't anticipate: the vendor generating the failure before a single user ever touches the device.
This time nobody clicked a phishing link or panic-signed a message. Coldcard's own firmware shipped with a change that quietly disabled the hardware random number generator, meaning some devices were generating predictable, low-entropy keys while reporting that everything was normal. If your seed is generated from weak entropy, no amount of user vigilance — no careful contract-checking, no slowing down, no ignoring urgent DMs — saves you. The signature pen itself was compromised at the factory.
According to firmware developer ddustin's writeup of the commit history, the bug traces back to a single change with the commit message "runs" — five characters, covering roughly 1,500 lines of code.
The developer was trying to override a function in Coldcard's Python-to-C bindings so custom code, rather than the default STM32 hardware library, would handle random number generation. The override collided with an existing definition in the STM32 library, producing a "duplicate symbol" compiler error — the kind of error that exists specifically to stop you before you ship something broken.
Rather than resolve the conflict, the fix was to disable the hardware RNG outright with a single macro:
#define MICROPY_HW_ENABLE_RNG (0)
That made the duplicate-definition error disappear, because it removed the code that caused the conflict in the first place. It also, as a side effect, removed the hardware RNG from every code path — including random.bytes(), the actual function Coldcard's wallet-generation code calls, which the developer's override never touched at all. With the hardware RNG disabled, that function silently fell back to a much weaker software generator called Yasmarang.
The commit message was "runs." Not "fixes RNG override." Not "temporarily disables hardware RNG, needs follow-up." Just confirmation that the compiler stopped complaining.
A 1,500-line diff that silently disables the single most security-critical function in a hardware security product, accompanied by a one-word commit message, should never survive code review at an organization that takes its own threat model seriously. That's table stakes for any codebase where a mistake means someone's funds disappear. The commit history suggests that didn't happen here.
I don't know the specific person who wrote that commit, and I'm not interested in psychoanalyzing an anonymous username. But I don't need to, because the failure isn't really about one person — it's about the review culture that let a change like this through. And that culture wasn't an accident. It was predictable in advance, if you had your priors set correctly.
Here's the argument I actually want to make, and I want to make it precisely because I think it's true, not because it's provocative: building a Bitcoin-only hardware security device — one that architecturally refuses to engage with any other chain, cryptosystem, or engineering tradition — is a bad design decision on its own terms. It doesn't make your C memory management safer. It doesn't audit your build flags. All it does is shrink your talent pool and your review surface down to people who already share your priors going in.
That's the part that matters for Bayesian reasoning. A maximalist's public commitments are themselves evidence, not just marketing. Someone who has built an identity around "Bitcoin is complete, everything else is noise" has told you, in advance, that they've pruned the set of people they'll take a correction from down to people who already agree with them. That's a testable prediction, not an insult: an engineering culture that treats outside cryptography and systems expertise as contamination will produce more uncaught errors than one that doesn't, because it has fewer independent checks and less incentive to seek them out.
Coldcard is the confirming instance. If your prior was "ideological insularity increases defect rates in security-critical code," this update was already priced in before the commit history became public. You didn't need to see the specific bug to predict that a project structured this way would eventually ship something exactly like it. The compiler error that got silenced with MICROPY_HW_ENABLE_RNG (0) wasn't a fluke of one bad day — it was the visible symptom of a review process with no outside pressure valve, on a project whose founding premise is that outside pressure is unnecessary.
Go back to the 2021 argument: a hardware wallet upgrades your signature pen, not the person holding it. The Coldcard incident extends that in a direction I didn't cover — your signature pen is also only as good as the review process behind the firmware that built it. "Air-gapped" and "secure" describe the device's connectivity, not the rigor of the team that shipped its code.
None of this means hardware wallets are worthless — they still close off entire categories of attack, exactly as I argued four years ago. It means they were never a substitute for scrutiny, whether that scrutiny is yours (checking the contract before you sign) or the vendor's own (checking the diff before it ships).
Treat commit hygiene as a signal, not trivia. A vendor whose security-critical commits look like "runs" on a 1,500-line diff is telling you something about their review process, whether or not this specific bug had happened.
Don't rely on a single device or vendor for large holdings. Multisig across genuinely different hardware and software stacks means one vendor's bad firmware doesn't wipe you out.
Verify entropy where you can. Don't take "generated a wallet" at face value from a device you can't independently audit; where possible, use tools that let you check randomness rather than trusting a black box.
Push for external audits as a baseline expectation, not a nice-to-have. Cross-disciplinary review from outside a vendor's own ecosystem is exactly the kind of check that would have caught a bug like this before it shipped.
Hardware wallets were never a silver bullet for user error. Now we know they aren't a silver bullet for a vendor's ideology either. If a hardware wallet company's entire pitch is that it doesn't need to learn from anyone outside its own tribe, adjust your priors accordingly — before the next one ships a compiler error into production, not after.