Coldcard RNG Slip: How a Tiny Build Flag Cratered Entropy and Enabled $130M in Bitcoin Thefts

Air‑gapped and unplugged did not save thousands of Bitcoin wallets. Attackers drained at least 1,596 BTC across three confirmed waves—roughly 7,300 addresses—plus 14 smaller incidents, with a suspected fourth wave lifting the tally to around 2,055 BTC. At current prices, that’s about $130 million, including a single 41‑minute sweep that moved $70 million. Coinkite says at least 15 separate attackers joined in. The cause wasn’t exotic malware. It was a hole in the randomness that seeds Coldcard wallets.

The heart of the failure In 2021, Coldcard shifted its crypto primitives to libsecp256k1, the same curve library used by Bitcoin Core. During that migration, seed generation silently stopped pulling entropy from the hardware RNG and began using MicroPython’s software fallback (Yasmarang)—a PRNG intended for devices with no true randomness at all.

A tiny build guard made it happen. The firmware used a preprocessor check that verified whether a setting was “defined,” not whether it was “on.” Because the flag had been defined as zero, the guard passed. Both code paths shared the same function signature, so nothing looked off in review. Result: on Mk2 and Mk3 units running firmware 4.0.1 through 4.1.9, the PRNG’s seed derived from the chip’s serial number and its clock. Coinkite estimates the effective search space at roughly 40 bits. Newer models blended in some secure‑element entropy, pushing that to about 72 bits. The target was 128.

Why the bit count matters Bits scale exponentially. Each lost bit halves the attacker’s work. At 128 bits, brute‑forcing is beyond physics; at ~40 bits—around a trillion candidates—a modest cluster can grind through. Block’s engineers assessed newer devices’ effective secure‑element search space at 2^32 candidates (with ~2^31 average trials). For older models, given a known device ID, timer state, and call history, wallet generation becomes deterministic. That isn’t “weak.” It’s predictable—which breaks cryptography at the root.

The real lesson: single‑source entropy is a trap This wasn’t about slightly biased noise; it was about one entropy source disappearing and no one noticing. Statistical randomness and cryptographic unpredictability are different beasts. A PRNG can look fine under statistical tests while being entirely determined by its seed. True unpredictability must come from physical processes—electrical jitter, thermal noise, radioactive decay—the exact job of the hardware RNG that stopped being consulted.

Audits focused on whether the RNG code existed, not whether the seed generator actually called it. Eight years of eyes read the right files and missed the broken path. That’s the cognitive failure: verification that checked presence, not provenance.

AI didn’t save the defenders Coinkite believes automated code scanning likely surfaced the bug for attackers. They say they ran a leading AI model across the codebase and it missed the issue. That rings true: generic “find bugs” passes often underperform property‑based checks. What works is specifying and testing the property you require: at compile time and runtime, prove the seed combiner draws entropy from the hardware RNG; fail the build if the flag disables it; lock in signatures that can’t be swapped without tripping tests; add live entropy health checks and alarms. Trust, but instrument.

About the dice fight As users regenerated seeds, many reached for dice—Coldcard supports manual entropy input, and the company treats seeds built from at least 50 independent, private rolls as safe from this bug. A warning landed on July 31: common dice aren’t “cryptographically secure,” so consider precision casino dice and mix in another source. The physics point is fair; the risk trade‑off isn’t. Developer Justin Sharp ran the math: a perfect d6 yields 2.585 bits per roll; a visibly biased die (one face 20% vs 16.7%) still gives ~2.55 bits. Over 99 rolls, that’s roughly 256 bits vs ~252 bits—only four bits lost. Compare that to 40. The sharper takeaway aligns with the core failure: don’t rely on any single source. Combine dice, hardware RNG, and system noise through a secure extractor.

What to do now - If you created a seed on an affected Coldcard without sufficient dice input or a strong BIP‑39 passphrase, assume compromise. - Update firmware, generate a fresh seed, verify the wallet fingerprint, send a small test transaction, then move funds. - Follow the model‑specific guidance; exported seeds carry the flaw with them, so importing elsewhere does not fix it. - Fixed firmware is available, but it cannot repair already generated seeds.

What changes from here Hardware wallets aren’t “broken,” but the burden of proof just went up. Ship builds that fail closed when hardware entropy isn’t wired. Prove at CI and at boot that the hardware RNG is being used. Blend multiple entropy sources and extract with a robust KDF. Make the seed generator a separately testable module with invariant checks. And in review, stop asking “Is the RNG present?” Start asking “Exactly which bytes fed the key?”

Randomness is a claim. In security, claims need continuous evidence. Assume entropy is guilty until proven otherwise—and keep proving it.