The $38 Million Random Number

The $38 Million Random Number

Aug. 1, 2026 | Categories: Tech , Vulnerabilities

Coldcard's five-year RNG failure let attackers sweep $38M from wallets this week — but seeds protected by a strong BIP39 passphrase survived. Here's why, and how TimeCapsule makes that layer practical.

The $38 Million Random Number

What the Coldcard Entropy Failure Teaches Us About BIP39 Passphrases, Verifiable Randomness, and Why TimeCapsule Exists

Executive Summary

On July 30, 2026, roughly 594 BTC — approximately $38 million — was swept from around 500 single-signature Bitcoin addresses in a narrow time window. Within hours, Coinkite published a security advisory confirming what security researchers had already begun to root-cause independently: for five years, affected Coldcard firmware silently generated wallet seeds from a deterministic software PRNG instead of the device’s hardware true random number generator. Seeds that should have carried at least 128 bits of entropy carried roughly 40 bits on Mk2/Mk3 devices — a keyspace an attacker can enumerate with commodity hardware.

The most important detail in this story is not the bug. It is who survived it. Users who generated their seed with verifiable dice rolls were unaffected. And users who protected their wallet with a strong BIP39 passphrase — the so-called 25th word — kept their funds even where the underlying seed was fully enumerable, because the passphrase is entropy the device never touched. The lesson is structural: never let any single device, vendor, or reputation be the sole source of your entropy. Layer your custody so that no one failure is fatal.

Root Cause
~40 Bits
Effective seed entropy on affected Mk2/Mk3 firmware — an enumerable keyspace instead of the intended 128+ bits
The Survivors
25th Word
Wallets protected by a strong BIP39 passphrase were not sweepable — even where the seed itself was recoverable
The Playbook
Layered
Verified entropy + strong passphrase + multi-sig + time-locked inheritance. No single failure should be fatal

What Happened: Five Years of Silent Entropy Failure

Coldcard has earned its reputation. It is frequently described as the gold standard of Bitcoin self-custody: air-gapped, open-source, secure-element-backed, built by people who take the threat model seriously. That reputation is precisely why this incident matters so much — because the failure occurred at the one step almost nobody verifies: the moment the device generates your seed.

March 1, 2021
The vulnerable path enters the codebase. A single commit changes seed generation from ckcc.rng_bytes — which correctly reached the STM32 hardware RNG peripheral — to ngu.random.bytes, which routed through the libngu library’s broken code path.
March 17, 2021
Firmware v4.0.0 ships with the vulnerable path. From this point forward, seeds generated on affected Mk2/Mk3 devices derive from a deterministic software PRNG.
March 2022
Mk4 adds a 32-bit boot reseed — an improvement, but one that yields roughly 72 bits of effective security on Mk4-era devices, still well below the 128-bit specification.
July 30, 2026
~594 BTC swept from ~500 addresses. Coinkite publishes its Mk3 security advisory the same day. Block’s Bitcoin Engineering and Security teams, along with independent researchers, root-cause the RNG failure. Bitcoin Core developer instagibbs reproduces the vulnerability on a fresh Mk3 device.

The technical failure is a chain of individually plausible mistakes that compound into catastrophe. Coinkite has not formally confirmed that the on-chain sweep and the entropy flaw are the same event, but the timing and the characteristics of the drained wallets have led researchers across the industry to identify low-entropy seed generation as the most plausible explanation.

Anatomy of the Entropy Failure
Why every safeguard in the chain failed to catch it
Hardware TRNG Bypassedlibngu’s STM32 guard failed to route random requests to the hardware RNG, silently falling back to MicroPython’s deterministic Yasmarang PRNG
XOR of Known StreamsThe Yasmarang output was XORed with a second Yasmarang instance initialized from hardcoded public constants — two deterministic streams with known starting states produce a deterministic result
Cosmetic Health CheckThe runtime health check only rejects adjacent repeated values — a test any non-degenerate PRNG passes trivially, weak or not
Hashing ≠ EntropyThe resulting bytes were hashed with SHA256d before becoming a seed — but hashing cannot increase the entropy of its input. At most 240 candidate inputs means at most 240 candidate wallets

Note what this incident is not: it is not a remote key extraction. Nobody pulled private keys off a Coldcard over USB. The keys were simply never unpredictable to begin with. Anyone who could characterize the PRNG’s behavior on the STM32 could regenerate the same seeds the devices did — and, five years later, someone apparently did, at scale. Some observers have speculated that AI-assisted code review helped outsiders spot in weeks what five years of human eyes missed in public, open-source firmware. That should concern every vendor shipping security-critical code — it is exactly the dual-use dynamic we wrote about in our Frontier AI analysis.


The Wallets That Survived: The BIP39 Passphrase

BIP39 supports an optional passphrase — often called the 25th word — that is combined with your mnemonic during key derivation (via PBKDF2-HMAC-SHA512) to produce the actual wallet seed. Two properties make it decisive in an incident like this one:

  • It is entropy the device never generated. Your hardware wallet’s RNG — good, bad, or backdoored — contributes nothing to the passphrase. It comes from you. A broken PRNG cannot weaken randomness it never produced.
  • Knowing the mnemonic is not enough. An attacker who fully recovers a low-entropy seed phrase still lands in an empty decoy wallet. The funded wallet lives behind the passphrase, and every candidate passphrase produces a valid-looking (but different) wallet, so there is no oracle telling the attacker they are close.

The arithmetic tells the story of who kept their coins this week:

Effective Attacker Work Factor — Affected Mk3 Seed Generation
ConfigurationSearch SpaceOutcome
Weak-PRNG seed, no passphrase~240Enumerable on commodity hardware — funds swept
Weak-PRNG seed + weak passphrase (“Satoshi2021!”)~240 × dictionaryOffline brute-force is practical — still at risk
Weak-PRNG seed + strong passphrase (6+ Diceware words, ~77 bits)~2117Computationally infeasible — funds survived
Verified dice-roll seed + strong passphrase≥2128 × 277Gold standard — no single point of entropy failure

Two honest caveats. First, the passphrase must itself be strong and generated off-device — a pet’s name with a year appended will fall to the same offline brute-force that recovered the seeds. Second, a passphrase is a second secret you can lose, and losing it means losing the funds. That second caveat is the reason most people never adopt a passphrase at all — and it is exactly the problem TimeCapsule was built to solve.


What TimeCapsule Is Actually For

Whenever we demo TimeCapsule, someone asks what it’s really for. This week is the answer. The single biggest objection to strong BIP39 passphrases is operational: “If I use a 77-bit passphrase I can’t memorize, and I get hit by a bus, my family loses everything.” So people either skip the passphrase — and inherit the full risk of their device’s RNG — or they write it down next to the seed, collapsing two independent secrets back into one theft target.

Karma-X Approach

Time-Locked Recovery: Strong Passphrases Without the Inheritance Problem

TimeCapsule encrypts your BIP39 passphrase (or any critical secret) inside a cryptographic time-lock puzzle — based on the Rivest-Shamir-Wagner sequential-squaring construction — that mathematically cannot be opened before a delay you choose: 72 hours, 90 days, 180 days. Not by a thief. Not by a supercomputer. Not even by you.

Against theft: a stolen TimeCapsule USB is worthless during the delay window — you’ve rotated your funds long before it opens. Against coercion: the $5 wrench attack fails, because faster decryption is not physically possible. For inheritance: your heirs retrieve the capsule, start the solve, and recover the passphrase after the delay — no lawyer, no custodian, no trusted third party holding a copy.

A Coldcard owner following this model — seed from verified entropy, strong off-device passphrase, passphrase time-locked for heirs — would in all likelihood have watched this week’s sweep from the sidelines.

A time lock can protect a secret. It cannot repair one. If the key inside was born predictable, the strongest vault in the world is guarding something the attacker already has.

That is why we are careful about what we claim. TimeCapsule is not a panacea. It does not generate entropy, and it cannot fix a seed minted by a broken RNG — if you time-lock a weak seed phrase, you have durably preserved a compromised key. What TimeCapsule does is remove the excuse for skipping the layer that mattered this week: it makes a strong, unmemorizable, high-entropy passphrase operationally survivable for your family and your business. This incident also exposes the deeper habit TimeCapsule exists to challenge: trusting a vendor’s random number implementation — any vendor’s — as the single load-bearing secret of your custody.


We Reported a Coldcard Key-Recovery Bug Last Year. Here’s What Happened.

This is not our first encounter with Coldcard’s security posture. On September 30, 2025, the Karma-X Security Research Team published a critical cryptographic vulnerability in Coldcard’s Delta PIN duress feature — the “panic PIN” designed to protect users under physical coercion. The implementation flaw allowed full private key recovery from just two transaction signatures produced in Delta PIN mode: a feature meant to save your funds at gunpoint could instead hand them over mathematically.

We disclosed the issue to the vendor privately, with full technical detail. To their engineering team’s credit, a fix landed quickly — we have archived the complete disclosure correspondence and the specific commit that remediated the issue. What never arrived was the public acknowledgment that Coinkite’s own website commits to providing security researchers who report issues. No credit, no mention in release notes, no CVE coordination. We published our findings on our blog and on r/coldcard, where they received very little attention at the time.

Why this matters beyond credit: goodwill from independent researchers is the cheapest security budget a vendor will ever have. When free, high-quality vulnerability reports are met with silence — especially after a published policy promises acknowledgment — researchers stop sending them, or start sending them somewhere else. This week’s RNG failure sat in public, open-source firmware for five years. A vendor in that position needs more outside eyes on its code, not fewer. How you treat the researchers who find your bugs quietly determines how many of them find your bugs before someone with a sweep script does.

“Trust, But Verify” Is the Wrong Maxim

Bitcoin’s founding ethos is stronger than “trust, but verify.” It is “don’t trust — verify.” And yet seed generation is precisely where almost everyone abandons it. Users who verify every firmware signature, check every receive address on-device, and run their own node will still press “new wallet” and accept whatever twelve or twenty-four words appear on the screen, on faith that the vendor’s RNG did its job. Coldcard’s reputation is deserved — and it still shipped five years of deterministic seeds. Reputation is not entropy.

The bitter irony is that Coldcard itself ships the antidote: it supports seed generation from user-supplied dice rolls, with math you can independently verify. Users who generated their seed from 99+ dice rolls were never exposed to this bug at all. Verification was available the entire time. Trust was simply easier.


If You Hold Funds on a Coldcard — or Any Hardware Wallet — Do This Now

  1. Treat affected seeds as compromised — today. If your seed was generated on a Coldcard Mk2/Mk3 running firmware v4.0.0–v5.0.3 without 99+ dice rolls, assume the key is public. Updating firmware does not help: the weakness lives in the key you already generated, not in the code running now.
  2. Migrate correctly. Create a brand-new wallet on a patched or different device, send a small test transaction, verify it, then sweep the remainder. Never type your existing seed into an internet-connected computer to “check” it.
  3. Generate entropy you can verify. Use dice rolls (99+ for 256-bit) or another auditable physical source, and cross-check the resulting mnemonic derivation against an independent, offline implementation before funding the wallet.
  4. Add a strong BIP39 passphrase. Six or more Diceware words (or equivalent, ~77+ bits), generated off-device, stored separately from the seed. This is the layer that separated survivors from victims this week.
  5. Use multi-signature — across heterogeneous vendors. A 2-of-3 across different manufacturers and device generations means no single vendor’s bug is fatal. Caution: if your entire quorum can be met by same-era devices from a single vendor, you have multiplied a correlated risk, not diversified it. Researchers this week noted that all-Coinkite multisig quorums deserve the same urgency as single-sig.
  6. Time-lock your recovery path. Put the passphrase (or complete recovery instructions) in TimeCapsule with a 90-day delay, on multiple USB copies in tamper-evident storage. Your heirs can always recover; a thief with the USB recovers nothing in time to use it.
  7. Track the advisories. Coinkite’s technical backgrounder and Block’s independent analysis are the primary sources. Mk4/Mk5/Q devices carry roughly 72-bit effective entropy from the 2022 reseed — below specification, with exploitability still being characterized. Treat “probably fine” as “migrate soon,” not “ignore.”
  8. Make verification a habit, not an event. Firmware signatures, receive addresses, derivation paths, entropy sources. The step you skip on faith is the step that gets exploited at scale.

Closing Thought: Reputation Is Not Entropy

Every custody disaster produces the same retrospective sentence: “but they were the gold standard.” The Coldcard entropy failure is a five-year lesson in why that sentence should never appear in your threat model. The gold standard shipped a deterministic RNG. The panic feature we analyzed last year could leak the very keys it existed to protect. None of this makes Coldcard uniquely bad — it makes every single-vendor, single-secret custody design predictably fragile.

The architecture that survived this week was not clever. It was layered: entropy the user verified, a passphrase the device never saw, signatures no single vendor could complete, and a recovery path that needs no trusted third party. That is the design philosophy behind everything we build at Karma-X — Protection > Detection — because you cannot detect your way out of a key that was born compromised. You can only architect so that it never mattered.

Don’t trust anyone with your randomness. Not the gold standard. Not us. Verify.


Sources & References

  1. Coinkite. Entropy Technical Backgrounder & Mk3 Security Advisory. Link
  2. Block Engineering. Predictable RNG Fallback and 32-Bit Reseed in COLDCARD Firmware. Link
  3. TFTC. ColdCard Is Compromised: What You Need to Do Now (with James O’Beirne). Link
  4. The Crypto Times. Coldcard Mk3 Firmware Bug Leaves BTC Wallet Seeds Exposed, $38M Drained. Link
  5. TechTimes. Coldcard Hardware Wallet Hacked via Firmware Bug That Bypassed RNG for Five Years. Link
  6. Karma-X Security Research. Coldcard Delta PIN Bitcoin Private Key Recovery Vulnerability. Link
  7. Karma-X on r/coldcard. Delta PIN Disclosure Thread. Link
  8. Karma-X. TimeCapsule: Using Time-Lock Puzzles To Secure Digital Assets. Link

document
Easy Install

From small business to enterprise, Karma-X installs simply and immediately adds peace of mind

shop
Integration Ready

Karma-X doesn't interfere with other software, only malware and exploits, due to its unique design.

time-alarm
Reduce Risk

Whether adversary nation or criminal actors, Karma-X significantly reduces exploitation risk of any organization

office
Updated Regularly

Update to deploy new defensive techniques to suit your organization's needs as they are offered

box-3d-50

Deploy
Karma-X

Get Karma-X!
💬 Ask our AI Assistant Kali