How Coldcard Broke Its Own Randomness: The $89M Entropy Failure

On the afternoon of July 30, someone emptied more than a thousand Bitcoin wallets in 41 minutes without touching a single device. No phishing link, no malicious USB cable, no evil maid slipping into a hotel room. The attacker simply worked out what the private keys were, from a laptop, offline, using nothing but public blockchain data and a bug that had been sitting in plain sight for five years.

The devices in question were COLDCARD hardware wallets, made by Canadian company Coinkite and marketed for years as the paranoid bitcoiner's choice: air-gapped, open-source, purpose-built for people who trust nobody. That reputation is exactly what makes this incident worth dissecting. This was not a story about careless users. It was a story about a single line of build configuration.

What follows is what actually broke, the exact points where Coinkite failed, what owners need to do today, and what the episode says about the wider self-custody trade. This is commentary and general information, not personal advice.

The Scale: 1,367 BTC and Counting

The first wave hit on July 30, 2026. Roughly 594 BTC, about $38 million at the time, left around 500 mostly dormant addresses in under half an hour. As blockchain analysts widened the net, Galaxy Research mapped a single coordinated sweep of 1,082.65 BTC across 1,196 addresses in 41 minutes, worth roughly $70.2 million.

It did not stop there. Later waves picked off smaller balances with tactics that shifted each time to complicate tracing. By August 2, the running total stood at approximately 1,367 BTC across 4,585 addresses, close to $89 million. Coinkite has said attacks were still ongoing.

For context on the week that contained it, see our weekly markets roundup, which covered the hawkish Fed hold and the Mag 7 prints that shared the same news cycle.

What Actually Broke: One Preprocessor Check

Every hardware wallet has one job that matters more than all the others: generate a seed that nobody can guess. A 12-word BIP-39 seed is supposed to carry 128 bits of entropy, a number so large that brute-forcing it is not a matter of patience but of physics. Coldcard devices contain a hardware random number generator plus secure-element true random number generators to produce exactly that.

In March 2021, Coinkite migrated its elliptic-curve maths to Bitcoin Core's libsecp256k1, which meant integrating a library called libngu. As part of that migration, seed generation moved from Coldcard's own ckcc.rng_bytes() to ngu.random.bytes().

Here is the part that cost $89 million. libngu contained a safety guard meant to refuse to build if the hardware RNG was not enabled. That guard used #ifndef, which asks only whether a macro exists. It does not ask whether the macro is switched on. Coinkite's production config defined MICROPY_HW_ENABLE_RNG as zero, precisely because Coinkite supplies its own hardware RNG wrapper. The macro existed, so the guard was satisfied, the compiler error never fired, and the build silently linked seed generation to MicroPython's Yasmarang fallback, a small non-cryptographic pseudo-random generator never intended to protect money.

The safety net was in place. It was checking the wrong thing. And nothing on the device screen ever indicated that the hardware entropy source had been bypassed.

How Bad the Randomness Was

The fallback generator was seeded from the chip's unique ID and timer registers, then collected no fresh entropy afterwards. Those are not secrets. They are constrained, guessable values. The result, by Coinkite's own published estimates:

• Mk2 and Mk3: roughly 40 bits of effective search space. Block's engineering team, which published an independent teardown, described these seeds as effectively deterministic, reproducible given the device UID, timer state and prior RNG call history.
• Mk4, Mk5 and Q: roughly 72 bits. Better, because secure-element entropy was mixed in, but that entropy was hashed down to 32 bits before reseeding, capping the number of distinguishable output streams at 2^32. Block put the average brute-force cost at around 2^31 trials, which is cheap on modest hardware.

Put plainly: a device sold on the premise of unguessable keys was producing keys that a determined person with a public address and a decent machine could rebuild offline. And because the RNG feeds more than seeds, the same weakness touched paper-wallet keys, ECDH encryption and generated passwords.

Where Coinkite Failed

Bugs happen in every codebase. What separates an unfortunate bug from an institutional failure is the number of layers that should have caught it and did not. On this one, several layers were either missing or pointed the wrong way.

1. The Safety Check Could Not Fail

A build-time guard that cannot detect a disabled feature is not a guard. It is decoration that provides false comfort. Worse, the specific configuration that defeated it, setting the macro to zero, was Coinkite's own deliberate and permanent production setting. The check was guaranteed to pass on every single build the company ever shipped.

2. Nobody Tested the Output That Mattered

This is the hardest part to defend. The single most security-critical output of the entire product is the byte stream that becomes a seed. A test that generated seeds on real firmware and compared them across devices, or across resets, or checked them for the statistical fingerprints of a weak PRNG, would have surfaced this in 2021. On Mk2 and Mk3 the output was effectively deterministic, which is about as detectable as a flaw can be. For five years, that test did not exist.

3. The Audits Looked at the Right Code and the Wrong Question

Coinkite's own backgrounder contains the most damning sentence in the whole affair: existing security reviews "verified that code but did not verify end-to-end symbol resolution and call reachability from wallet seed generation." Reviewers read the hardware RNG implementation, confirmed it was sound, and never checked whether the seed function actually called it. The code was correct. It was simply not the code that ran.

4. Open Source Was Treated as a Substitute for Verification

The vulnerable firmware was public for over five years. It was reproducibly built, inspected by an unusually technical customer base, and nobody spotted it. That is not an argument against open source, it is an argument against the marketing claim that many eyes automatically equal many reviews. Linker-level integration errors are exactly the class of defect that reading source code does not reveal, because the source reads perfectly well. The flaw lives in what the build resolves, not in what the file says.

5. The First Response Was "No Need To Panic"

The public timeline is unflattering. Kevin Loaec of Wizardsardine flagged the anomaly publicly at 17:35 UTC on July 30, urging Coldcard users to check their balances. Coinkite co-founder Rodolfo Novak, known as NVK, replied at 18:10 UTC saying there was no need to panic. Coins were already moving. To Coinkite's credit, the position changed quickly and completely: NVK apologised publicly on July 31, accepted full responsibility for the mnemonic generation failure, shipped patched firmware the same day, and offered affected users incident summaries and transaction data for police reports and insurance claims. But the first 30 minutes of a live drain is when a warning is worth the most.

6. The Customer Email Contradiction

To warn owners, Coinkite emailed buyers going back to 2019. That was the right call for user safety and it detonated a separate trust problem, because the company had previously indicated it purged buyer data after 90 days. A privacy-first brand cannot hold seven years of customer records quietly and then reveal them during an emergency. Either the retention policy was wrong or the description of it was.

The Part That Is Genuinely Sympathetic

One point deserves fairness. NVK has suggested the flaw was likely surfaced by AI-assisted code review, warning that such tooling "can now find latent bugs at a speed that is outpacing even industry's most seasoned experts." That is probably true, and it is the uncomfortable lesson for every other open-source project handling key generation: five years of dormant public code is now five years of free training material for an automated auditor that never gets bored. Every wallet vendor should assume their old releases are being read this way right now.

Who Is at Risk, and What To Do

Per Coinkite's advisory, a seed is at risk if it was generated on affected firmware and was created without at least 50 independent private dice rolls and is not protected by a strong, unique BIP-39 passphrase. Affected versions:

• Mk2 and Mk3: firmware 4.0.1 through 4.1.9. Patched in 4.2.0
• Mk4 and Mk5: anything before 5.6.0 (Edge builds before 6.6.0X)
• Q: anything before 1.5.0Q (Edge builds before 6.6.0QX)
• Not affected: TAPSIGNER, OPENDIME and SATSCARD

The critical thing to understand, and the thing most people get wrong in a panic: updating firmware does not save existing coins. The patch fixes how new seeds are made. A seed that was already generated with weak randomness stays weak forever, on any firmware, on any device, in any wallet software. The keys are already out there to be computed.

If you hold coins on a seed generated by a Coldcard on affected firmware, the sequence is:

• Update to patched firmware
• Generate a completely new seed on the updated device
• Verify the new backup and send a small test transaction first
• Move all funds to addresses derived from the new seed
• Keep the old backup until the migration is fully confirmed, then retire it

If your seed came from dice rolls you performed yourself, or sits behind a strong unique passphrase, you were outside the attacker's practical search space. That is the one design decision that saved people here, and it is worth noting that Coldcard's dice-roll feature existed precisely because Coinkite told users not to fully trust any single entropy source. The users who took that advice literally are the ones who still have their bitcoin.

What the Market Did With It

The price reaction was strikingly muted. Bitcoin closed the week down roughly 2% and traded near $62,600 on Monday morning, comfortably inside the range it had held all week. A $89 million theft is real money, but it is a rounding error against a $1.25 trillion asset, and crucially it created no forced selling: stolen coins do not need to be liquidated on a schedule.

The behavioural reaction was far more interesting than the price one. CryptoQuant data showed daily Bitcoin deposits under 10 BTC hitting 7,300 BTC on July 31, the highest since February 6, with active addresses jumping from about 645,000 to nearly one million as smaller holders moved coins onto Binance, Kraken and OKX. Total exchange-held Bitcoin rose from 2.704 million to 2.715 million.

That is the exact inverse of the post-FTX reflex. In 2022, a custodian failure pushed coins off exchanges and into hardware wallets. In 2026, a hardware wallet failure pushed coins back onto exchanges. Retail's answer to "the thing I trusted broke" is apparently to run to whichever counterparty broke least recently.

Lorenzo Valente, director of digital asset research at ARK Invest, framed the underlying point well: self-custody does not remove risk, it trades counterparty risk for "software risk, hardware risk, supply-chain risk, phishing risk, backup risk, and the possibility of losing everything." Bitcoin commentator Guy Swann called it "the worst hit in bitcoin history to the most knowledgeable and properly secured bitcoiners." Meanwhile Nick Neuman of Casa made the practical objection to the standard fix: telling people to roll dice for extra entropy is "a non-starter for 99% of people."

He is right, and that is the real problem this incident exposes. The mitigation that worked was a manual, tedious step that most owners skip because the entire product promise was that the device already handles it.

The Lesson Worth Keeping

The uncomfortable conclusion is not that hardware wallets are bad, or that exchanges are better. Both propositions are refuted by recent history. It is that trust in a single point of failure is the risk, whatever brand is printed on it.

The practical takeaways generalise well beyond Coldcard. Add your own entropy when a device lets you, because it converts a vendor's correctness into something you verified yourself. Use a strong unique passphrase, which in this case was a complete defence. Spread meaningful holdings across more than one seed and ideally more than one vendor, so that any single firmware bug caps your loss rather than defining it. And treat a security advisory from your wallet vendor as a same-day task, not a weekend project, because the window between disclosure and exploitation is now measured in minutes.

Coinkite built a genuinely good product, published the source, funded audits and reproducible builds, and still shipped a five-year hole in the one function that mattered most. If that can happen to the vendor with arguably the most security-obsessed customer base in Bitcoin, the honest response is not to find a vendor you trust more. It is to stop needing to trust any of them completely.

ThriveInMarkets publishes market commentary and general information only, and does not provide personal investment, security or custody advice. Details of this incident are drawn from Coinkite's published advisory and technical backgrounder, Block's engineering analysis and contemporaneous reporting, and the investigation was still ongoing at the time of writing. Figures, affected version lists and loss totals may be revised. Always verify firmware versions and advisories directly with your hardware wallet vendor before acting.