The 40-Bit Seed: Coldcard's Silent Three-Year RNG Failure and the 77,402 BTC Exodus

Forty bits. That is not a typo, and it is not a metaphor. It is the effective entropy that Coldcard — the hardware wallet marketed to the most paranoid Bitcoin holders, the one with the USB port physically removed in its most extreme air-gapped configuration — shipped to customers for more than three years. The cost is now measurable: 1,367.05 BTC in suspected thefts, 77,402 BTC moved off devices in defensive migration, and a candidate seed pool small enough that a rented GPU cluster can exhaust it offline. No physical contact with the wallet. No host malware. Just deterministic enumeration against a public ledger. The math holds until the incentive breaks. This time, the incentive broke on the supply side. Coldcard occupies a strange place in the Bitcoin hardware stack. It is not the beginner's choice. It is the device chosen by people who understand what self-custody means: air-gapped signing, PSBT workflows, a deliberate rejection of convenience. It is the wallet you buy when you have decided that trust in computers is a liability. That makes this vulnerability harder to process, because the failure is not in the secure element or the signing logic. It is in the most boring, most fundamental component a hardware wallet owns: the source of randomness that generates your seed. The disclosure arrived through Coinkite's security advisory, with coordinated technical analysis from Block and on-chain loss estimates from Galaxy Research. In the firmware build configuration, MICROPY_HW_ENABLE_RNG is defined as 0 — disabled. The code never validates that value. It checks whether the RNG object exists, not whether it is enabled. The hardware random number generator stays silent, and MicroPython falls back to Yasmarang, a deterministic, non-cryptographic pseudo-random generator. Your cold storage was running on a roulette wheel with a fixed number of positions. Yasmarang is not a cryptographic generator. It is a compact PRNG with a 128-byte state, designed for microcontrollers with scarce memory. Deterministic by construction: same state, same output, forever. The failure entered the production path with firmware 4.0.0 on March 17, 2021. It sat there for over three years before coordinated external analysis surfaced it. That latency is the story. The version boundary is already contested. Coinkite places the exposure start at 4.0.1 for Mk2 and Mk3 models; Block's timeline identifies 4.0.0. Users who skipped the allegedly bad release may still be exposed if the timeline shifts under further review. My read is conservative: when a security model collapses, a version number is a legal artifact, not a security boundary. If the code path was live in 4.0.0, treat 4.0.0 as compromised. Over-covering one firmware version costs hours. Under-covering it costs a drained wallet. Now the math that matters. For the Mk2 and Mk3, the effective search space is roughly 40 bits. 2^40 is about 1.1 trillion candidates. A modern GPU can derive and evaluate Bitcoin addresses at millions of candidates per second. A single machine finishes the job in weeks. A modest cluster of one hundred GPUs does it in hours. This is not nation-state capability. This is a cloud rental, a weekend, and a monitored address list. The cost of the attack is measured in hundreds of dollars, not millions. The Mk4, Mk5, and Q models fared better, with approximately 72 bits of search space. But Block's analysis identified up to 2^32 distinguishable output streams in the random path. I read that as a structural priority list for attackers: the generator does not produce a uniform field of independent wallets; it produces a space of related streams that can be ordered and searched in descending likelihood. Seventy-two bits is beyond naive brute force. It is nowhere near the 128 bits promised by a 12-word seed, let alone the 256 bits implied by 24 words. The problem is amplified by how Bitcoin wallets derive keys. A 24-word seed runs through PBKDF2, producing a 512-bit master key, and the HD tree then expands into thousands of addresses. Users assume the phrase length maps to the entropy of the source. It does not. Key stretching does not create entropy; it only obfuscates its absence. The attack itself is the purest violation of the hardware wallet threat model. No physical access is required. The attacker enumerates the candidate seed pool on a separate machine, derives public keys, and compares each against the public ledger. Any address holding a balance is flagged, its private key is derived, and the funds are swept. The attack can be run against the entire address space of an HD wallet, and the matching process does not require knowing which firmware version the victim used — the candidate pool covers all of them. This is the offline brute force that hardware wallets were designed to make impossible. The device still holds your keys. It never had a key worth the name. And here is the detail that makes this genuinely dangerous: the affected seeds look completely normal. Twenty-four legitimate BIP39 words. Passphrase support works. The device boots, signs, and displays addresses like any other Coldcard. There is no indicator, no warning, no UI state that whispers low entropy. Users do not know they are compromised. The seed does not scream. I have seen this pattern before, in contracts I audited during the DeFi years: a boolean flag defined in a constructor, read in a hot path, but never validated at initialization. The system behaves normally until the flag matters. In one review, a fee-rounding path shipped with a guard that was present but inverted; tests passed for months. A fee error costs fractions of a cent. A seed with 40 bits of entropy costs everything. Audits verify logic, not intent. Here, the logic audit missed the flag entirely. Updating the firmware is necessary but insufficient. A patched device generates correct entropy for future seeds, but existing seeds are permanently compromised. Every address in the derivation tree shares the same low-entropy root. Change addresses, legacy addresses, SegWit addresses — all are in the candidate pool, and all are exposed. A BIP39 passphrase adds a real layer of protection, because the attacker must know the phrase to derive the final keys. But the majority of users do not use a passphrase, and the UI treats it as an optional extra rather than a required defense. The only complete response is to generate a new seed on patched hardware and move every satoshi. The on-chain footprint is already visible. Galaxy Research's estimate of 1,367.05 BTC in suspicious losses is an evolving number — more likely to be revised upward than downward. The 77,402 BTC of defensive migration is not selling; it is reallocation. But a migration wave of that size awakens dormant UTXOs, some untouched for years, and pushes them through the mempool. Chain surveillance tools will flag these as abnormal whale movements, and some of that activity will be misread as distribution. Migration also costs fees: multiple transactions per wallet, adding up to hundreds of bitcoins of economic waste. History repeats in the ledger, not the news. The enumeration itself is silent. An attacker only broadcasts the sweep transaction at the end, so the public ledger shows the theft, not the search. Stolen coins move once, then sit in fresh wallets waiting for a favorable market window. One uncomfortable variable remains unknown: how many keys were already enumerated. The attack leaves the victim in the dark. A swept wallet is obvious, but a balanced wallet that was enumerated but not yet drained is a ticking event. The owner of an exposed seed has no way to distinguish safe from checked but not stolen. This is the worst part of low-entropy compromise: the attacker's silence is not a proof of safety. Now the contrarian point, and it is uncomfortable. The 1,367 BTC already stolen is the smaller risk. The larger risk is structural: the hardware wallet security model rests on an unverifiable manufacturer assumption. Every vendor claims a certified secure element and a hardware TRNG. No buyer can verify that the RNG is enabled. Users only learn it was not after a coordinated external analysis exposes three years of silent exposure. This bug class is not unique to Coldcard. Any device that integrates MicroPython and fails to enforce the enabled state of its hardware RNG carries the same latent flaw. The biggest brands have different firmware and the same fundamental opacity. The vulnerability was not found by Coinkite's own team, not by a continuous audit program. It was surfaced through coordinated external analysis after three years of production. That is not a governance failure unique to this vendor; it is the industry norm. Hardware wallet vendors sell on trust — your keys, your coins — but the user experience is identical whether the RNG works or not. That is precisely the kind of silent failure that survives for years and disappears from audit reports. Risk is a feature, not a bug, until it isn't. The fix for users is deterministic: regenerate, migrate, verify. The fix for the industry is not. When does the next security-first device ship its own silent flag? The next disclosure will come from a different vendor, with a different flag, and the same three-year arc. Consensus is code, but code is fragile. The hardware wallet is the physical expression of that fragility. The ledger is still counting.