# A Hardware Wallet That Wasn't Using Its Hardware: The $70 Million Coldcard Failure
On July 30, 41 minutes was all it took to empty 1,196 Bitcoin addresses of 1,082.65 BTC — roughly $70.2 million at current prices. The sweep was surgical, uniform, and fast. Galaxy Research traced the pattern and found the common thread: a five-year-old firmware bug in Coldcard, the device that much of the Bitcoin community treats as the paranoid-prepper's gold standard for cold storage.
The irony is brutal. Coldcard's entire value proposition is hardware-level security. Keeping private keys offline, isolated from networked machines, protected by a dedicated secure element. And the vulnerability that just burned tens of millions of dollars in user funds? The hardware random number generator wasn't being used.
---
## The Bug: One Macro, Five Years of Exposure
The fault traces back to a March 2021 firmware integration. Coldcard runs on MicroPython, and its cryptographic library, libngu, checks whether MICROPY_HW_ENABLE_RNG is defined in the build config — not whether it's set to a nonzero value. Coinkite's production config defines the macro as zero, because Coinkite supplies its own hardware RNG wrapper and doesn't need MicroPython's default path. The library saw the macro, assumed the hardware RNG was active, and silently fell through to MicroPython's Yasmarang PRNG fallback.
Yasmarang is a software pseudorandom number generator. It needs a seed to start. In this build, that seed came from the STM32 chip's unique device identifier and timer registers — fixed values or values with constrained ranges — and collected no additional entropy after initialization.
The result: an attacker who can narrow down or reconstruct a target device's UID, timer state at first boot, and prior RNG call history can generate candidate seed streams offline, derive their corresponding Bitcoin addresses, and cross-reference against the public blockchain. No device access required. No physical attack. Just arithmetic.
---
## Entropy by the Numbers
Coinkite's own disclosure puts effective entropy at approximately 40 bits for the Mk3 and around 72 bits for the Mk4, Mk5, and Q. A standard 12-word BIP-39 seed carries 128 bits of entropy. Block's separate analysis sets conditional ceilings rather than a single practical figure, and explicitly notes that 73-bit security is not cryptographically equivalent to 73 bits of entropy — the gap matters.
Forty bits is borderline trivial for a targeted attack with modern hardware. Seventy-two is harder but not the wall you're paying Coldcard prices to stand behind.
The affected firmware versions span a long window:
| Device | Vulnerable Range | Fixed Version |
|---|---|---|
| Mk2 / Mk3 | 4.0.0 – 4.1.9 | 4.2.0 |
| Mk4 / Mk5 | Any before 5.6.0 | 5.6.0 |
| Q | Any before 1.5.0Q | 1.5.0Q |
| Mk4/5 Edge | Before 6.6.0X | 6.6.0X |
| Q Edge | Before 6.6.0QX | 6.6.0QX |
That's everything shipped during most of Coldcard's commercial life.
---
## Patching Won't Save You — Read That Again
Coinkite pushed emergency firmware for every affected model on July 31, one day after the theft. Fast response. But here's what a lot of users are probably going to miss: updating the firmware does not fix the problem for existing seeds.
The weakness is in when the seed was generated, not in what software the wallet runs today. If your seed was created on vulnerable firmware, that seed is compromised regardless of what you install now. Restoring the old seed phrase to a patched device — or to any other wallet — carries the vulnerability forward.
The only safe path is generating a new seed on patched firmware and moving coins to addresses derived from that seed. This is a meaningful operational burden. It requires physically accessing the device, verifying the firmware version, generating fresh entropy, recording new seed words, and moving funds on-chain.
Coinkite does offer one narrow exception: seeds generated using at least 50 fair, independent, private dice rolls are not vulnerable to this specific bug. And a strong BIP-39 passphrase creates a wallet the bare seed words can't reach on their own — though Coinkite still recommends replacing the seed outright. Multisig provides some defense, but only if the signing quorum includes at least one device not built on affected firmware.
TAPSIGNER, OPENDIME, and SATSCARD run different codebases and are not affected.
---
## This Is the Second PRNG Disaster in Five Weeks
In early July, Coinspect published research they called Ill Bloom: a separate weak-PRNG vulnerability in older software wallets that had quietly drained over $5 million from addresses across Bitcoin, Ethereum, Tron, Rootstock, and Polygon since May. Different wallets, different codebase, same root cause. Entropy generation that wasn't actually random.
Two major PRNG-related thefts in roughly five weeks is not a coincidence — it's a signal. The cryptographic community has known for decades that weak randomness undermines every security guarantee downstream. But knowledge hasn't translated into rigorous auditing of how entropy is actually sourced in production builds.
The Coldcard case is particularly galling because the fix was present. The STM32 hardware RNG was there. Coinkite had even written a wrapper for it. The macro check was just wrong — existence instead of truthiness — and that single logic error in a dependency silently discarded five years of hardware investment.
---
## HackWire Analysis
The Coldcard flaw is going to be held up as a cautionary tale about hardware wallet trust, but the real lesson is narrower and more actionable: firmware audits need to verify entropy paths, not just assume them.
Cryptographic libraries are littered with conditional compilation flags that do surprising things when set to unexpected values. The libngu macro check is an obvious example, but it's not exotic — this class of error shows up repeatedly in embedded cryptography. A macro set to zero should mean disabled. When "does this key exist in the build config" and "is this feature enabled" are different questions, the answers had better not be conflated.
What's largely missing from current coverage is the detection problem. Galaxy Research identified the July 30 sweep as almost certainly connected because of its uniform fee rate (30 sat/vB) and the absence of change outputs — unusual transaction patterns that stuck out in aggregate. But the attack could have proceeded quietly over months with more randomized fees and cover transactions. The on-chain fingerprint that got noticed was an operational choice by the attacker, not an inherent detection mechanism.
For defenders right now: if you hold BTC in a Coldcard generated on firmware older than the fixed versions listed above, treat the seed as burned and move your coins. That's not optional advice. And if you're running any embedded device that generates cryptographic material — hardware wallets, HSMs, IoT devices with certificates — demand documentation of the entropy source, not just a claim that hardware RNG is present.
The broader pattern of PRNG failures in 2026 suggests attackers are methodically working through old wallets and devices where entropy assumptions were wrong. This isn't the last one.
— HackWire Editorial
---
## Related Coverage