You Can't Audit Entropy After the Fact: Operator Lessons from the Coldcard Seed Failure

Over two days starting July 30, 2026, coins left Coldcard-generated wallets in three coordinated waves. By August 2, forensic work by Galaxy Research put the confirmed total near 1,367 BTC ($88.6M) across more than 4,500 addresses. The victims had done what the industry told them to do. They bought a well-regarded, security-focused hardware signer, generated the seed on the device, and kept it offline. Many had not touched those wallets in years. The attacker never touched a single device.

The cause, per Coinkite’s advisory and technical backgrounder, was a firmware regression that shipped in March 2021 and survived five years of releases and reviews: seed generation silently stopped using the hardware random number generator.

One preprocessor semantic

The mechanics are almost offensively small. Coldcard’s build defined MICROPY_HW_ENABLE_RNG as 0 because Coinkite supplies its own hardware-RNG wrapper. Downstream, a guard checked #ifndef MICROPY_HW_ENABLE_RNG: whether the macro exists, not whether it is enabled. Defined-as-zero passed the check, and the build quietly linked MicroPython’s software fallback: Yasmarang, a toy PRNG intended for chips with no hardware RNG at all, seeded from the chip’s unique ID and boot-time state and never fed fresh entropy again.

The result, by Coinkite’s own estimate: seeds on Mk2/Mk3 (firmware 4.0.1 through 4.1.9) carried roughly 40 bits of effective entropy. Mk4, Mk5, and Q devices got an accidental partial rescue in 2022 (a 32-bit reseed from the secure element), bringing them to roughly 72 bits. The design target was 128. A 40-bit keyspace is a weekend project on commodity hardware, and the sweeps observed so far are consistent with exactly that: Mk3-era seeds. A 72-bit search is far harder, and no public evidence yet shows one cracked in the wild, but it sits uncomfortably within reach of a well-funded adversary with patience, which is why Coinkite tells Mk4, Mk5, and Q users to migrate too rather than wait to find out.

Two details deserve attention from anyone who runs key-management processes for a living:

The correct code was present the whole time. The hardware-TRNG implementation existed in every affected binary, reviewed and intact. It was simply never called from the seed-generation path. Coinkite’s post-mortem language is precise: reviews “did not verify end-to-end symbol resolution and call reachability.” The check confirmed the code existed; nobody confirmed it was reachable. That is the same failure shape as an unverified backup: presence mistaken for function.

The introducing change was mundane. Per an independent analysis of the commit history, the regression arrived while integrating a crypto library, as a workaround for a duplicate-symbol compile error. Nothing about it looked like a security decision. The most dangerous changes to a security-critical system rarely announce themselves as one.

Why nobody could see it in the output

Here is the uncomfortable part: there was no artifact anyone could have inspected afterward to catch this.

Keys derived from a broken RNG look exactly like keys derived from a perfect one. A seed with 40 bits of real entropy still expands into well-distributed, unique-looking addresses; the output of even a weak PRNG passes casual statistical inspection, and no test suite run against outputs can distinguish “unpredictable” from “deterministic but unexamined.” Entropy is not a property of the bytes. It is a property of the process that produced the bytes, and once generation is over, that process has left no trace unless you deliberately recorded one.

This is worth stating as a general law, because it separates key generation from almost everything else in custody operations. A backup can be verified after the fact. A recovery procedure can be drilled after the fact. Randomness is the one input you can only witness at the moment of creation. Whatever assurance you want about it has to be built into the ceremony and evidenced at generation time. Afterward is too late, structurally and permanently.

Who survived, and why

The postmortem sorts affected users into groups, and the sorting is instructive because every surviving group made its decisive move at generation time.

Dice-roll users survived. Coldcard has always offered seed generation from 50+ user-supplied dice rolls. On affected firmware, those rolls were hashed together with the (weak) device entropy, which means user entropy carried the seed: 50 private rolls contribute about 128 bits on their own, regardless of what the device added. The people the community sometimes teased for paranoia-theater dice ceremonies are the people whose funds never moved. Independent entropy at the ceremony is not theater. This event is what it is for.

Multi-vendor multisig users survived. A 2-of-3 across devices from different manufacturers loses one key to a single vendor’s design failure: below threshold, funds safe. Wizardsardine’s writeup makes the point well: the property doing the work is dissimilar redundancy. Three keys on three devices of the same brand is redundancy against loss, but not against design failure, and the failure that actually happened here was perfectly correlated across every device of the brand.

Passphrase users got lucky, partially. A strong BIP-39 passphrase that never touched a computer put funds behind one more brute-force barrier. Coinkite is careful to call this a mitigation, not a fix, and still tells those users to migrate. A passphrase is a second factor bolted onto a broken first factor.

There is also a group that thinks it survived and has not. A weak seed restored onto a different, perfectly good hardware wallet is still a weak seed: the flaw is bound to the numbers, not to the plastic. Neither a firmware update nor a change of vendor repairs a key that was already generated. The only remedy is a new seed and a migration, which is precisely the property that makes generation-time failures so expensive.

Everyone else is now in a forced migration, racing parties who can enumerate the keyspace. And the race was rigged from the start: the first theft wave reportedly began some 30 hours before any public disclosure existed, and most of the initial haul moved within the first hour. By the third wave, fee patterns (200 sat/vB on an uncongested network) point to fully automated sweeping.

None of this requires taking a reporter’s word for it. The wave-1 collector address, published in Fabio Akita’s technical walkthrough of the exploit and identified through Galaxy Research’s on-chain clustering, is bc1qnk4zh9qcnap2mycp56qjrgza3cc8ylrh8fecp0: 502 separate incoming payments totalling 594.48 BTC, consolidated and then pushed onward in a single 562 BTC transaction. One address per victim, batched and swept in under an hour, then parked. As of 2 August 2026 the coins had not moved again. The attribution rests on clustering, not on a confession, but the shape of the activity is checkable by anyone with a block explorer, and it is the shape of a script working through a precomputed list, not of a person making decisions. When a key-compromise event goes public, your real recovery time is not what your runbook says; it is whatever the attacker’s schedule allows. Organizations that had rehearsed moving funds under time pressure got to find out; organizations that hadn’t got to find out too.

Worse, the triage was done against a moving target. Coinkite’s first advisory scoped the problem to the Mk3. A day later it was widened to cover Mk4, Mk5, and Q at roughly 72 bits. Anyone who read the initial notice, concluded their Mk4 fleet was clear, and stood down had made a defensible decision on the best information available, and was wrong by the following afternoon. Early vendor scope statements during a live incident are provisional by nature: the vendor is reverse-engineering its own five-year-old build while you are reading. Plan for the affected-population estimate to grow, and re-check the advisory rather than acting once on its first version.

What key-generation evidence should record

If you operate custody infrastructure, or sign off on someone who does, this incident converts directly into requirements for the key-generation ceremony record:

1. Entropy provenance, explicitly. The record should answer: what supplied the randomness, what independent entropy was added, and how the sources were combined. “The device generated it” is a trust statement, not evidence. If your ceremony documentation cannot answer where the randomness came from, it cannot detect, even in principle, the entire failure class this incident belongs to.

2. Independent entropy whenever the interface allows it. Dice rolls, a second device’s output XORed in, verifiable entropy from a separate source. The cost is minutes of ceremony time. The payoff is that no single implementation’s silent failure can zero out your entropy. This was the single decision that separated victims from survivors in July 2026.

3. Dissimilar redundancy in the quorum design. For any threshold setup, ask: which single vendor, firmware lineage, or supply chain appears in every key? That intersection is your correlated-failure exposure, and it belongs in the risk register next to the usual loss-and-theft scenarios.

4. Verification of reachability, not presence. For your own systems, the software lesson generalizes: reviews that confirm secure code exists are not reviews that confirm it executes. Test the path end to end: generate on the real device and real firmware, feed known entropy where the design permits, and confirm the output is a pure function of what you fed in. “The TRNG is on the board” was true on every compromised Coldcard.

5. A rehearsed emergency-migration procedure. Key compromise at the vendor level turns rotation into disaster recovery with a hostile clock. If migrating every wallet to fresh keys has never been exercised, the first run happens during the race.

The pattern underneath all five: a property you cannot verify after the fact must be evidenced at creation. Backups earn their trust through later verification; randomness never gets that chance. The ceremony record is the only witness entropy will ever have. That is a good reason to treat key-generation evidence not as compliance paperwork, but as the one place where this class of catastrophe is visible before an attacker makes it visible for you.