The ColdCard RNG Failure: What Actually Happened, the Role of AI, and Why It Matters for Every Bitcoin Treasury Firm

Part 1 of 5 in a series on the ColdCard incident for Bitcoin treasury leadership and policymakers.

On July 30, 2026, Coinkite maker of the ColdCard hardware wallet, disclosed that a firmware bug had caused certain devices to generate Bitcoin private keys using far less randomness than the protocol requires. Within a day, roughly 594 BTC (about $38 million at the time) moved out of nearly 500 wallets in a 25-minute window. Ai attackers were able to recover those weakened private keys by a brute-force computation problem.

For anyone running Bitcoin treasury operations, the mechanics matter more than the headlines. Here's what happened.

The failure, in plain terms

A Bitcoin private key needs to come from a source of randomness strong enough that no one not a competitor, not a nation-state, not a botnet could ever guess it by chance. ColdCard devices are built with a hardware random number generator (a physical chip designed to produce true randomness) specifically for this purpose.

A code change made in March 2021 quietly broke that path. Instead of pulling entropy from the hardware chip, affected firmware routed key generation through a software-based fallback generator bundled in the device's underlying codebase. That software generator is deterministic  given the same starting conditions, it produces the same output. 

The bug survived five years of firmware releases and, according to Coinkite's own account, an AI-assisted security review that missed it. 

Who was affected, and how badly

The severity varies by device generation:

• ColdCard Mk3, firmware versions 4.0.1 through 5.0.3: keys generated with roughly 40 bits of entropy, against a 128-bit target. This is the confirmed, worst-affected population.

• ColdCard Mk4, Mk5, and Q, firmware before the July 2026 fixes: a design change added some additional entropy sources, bringing affected keys to roughly 72 bits still well short of the 128-bit standard.

To put that in perspective: every bit you remove from the entropy pool halves the work an attacker needs to do to find your key. The gap between 40 or 72 bits and 128 bits isn't a rounding error. It's the difference between a key space that's theoretically searchable with serious but attainable computing resources, and one that isn't.

Two important nuances Coinkite's advisory is explicit about:

• Dice rolls protect you. If you supplied 50 or more independent dice rolls when generating your seed, that manually-entered entropy was hashed into the final key and is not affected by this bug. 99+ rolls gets you to the full 256-bit standard.

• A firmware update does not fix an existing key. Updating a device only ensures newly generated keys use the corrected process. Any key generated before the update remains exactly as weak as it was the day it was created. The only fix is generating a brand-new seed on corrected firmware and moving funds to it.

What wasn't affected

Coinkite's other products TAPSIGNER, OPENDIME, and SATSCARD use different codebases and are reportedly not  implicated. However, use them at your own risk. Other hardware wallet manufacturers, including Trezor and BitBox, have publicly stated their firmware does not share the affected code path and their users do not need to take action based on this advisory alone.

Where AI actually fits into this story

Coinkite has said it believes an attacker used an AI model to review its open-source firmware history and locate the flaw and, with unusual candor, disclosed that it had run one of the best available AI models over its own codebase weeks earlier and that review did not surface the bug. That combination is worth sitting with: the same category of tool can find a critical flaw for whoever points it at the code first, regardless of which side they're on.

It's worth being precise about what AI did and didn't do here, because the two are easy to conflate. The reported role of AI was in discovery combing through years of firmware commits to spot the specific line where hardware entropy silently fell back to a weak software generator. 

Exploitation was a separate and much simpler step. Once the effective key space was reduced to roughly 40 bits on the worst-affected devices, recovering a private key becomes a brute-force computation problem checking candidate keys against known constraints until one matches that doesn't require AI at all, just enough conventional computing power pointed at a search space that had shrunk from computationally impossible to merely difficult. The 72-bit devices are believed to be out of reach of casual attackers but plausibly within range of a well-resourced one; the 40-bit devices were not out of reach for anyone with modest resources and motivation.

The distinction matters for treasury and policy audiences alike: the risk AI introduces here isn't "AI can crack strong cryptography," which it can't. It's that AI-assisted code review compresses the time it takes to find weaknesses like this one from years to days for defenders and attackers alike, whoever gets there first.

Why this is a governance story, not just a security story

It's tempting to read this as "buy better hardware." That's not the real lesson. A five-year-old bug in an open-source, publicly auditable codebase, missed by the vendor's own AI-assisted review, is a reminder that no single vendor's engineering process is a sufficient control for institutional-scale Bitcoin holdings no matter how good that vendor's reputation is.

The next post in this series looks at what that means concretely for how treasury companies should structure custody, and why the fix isn't "trust a different vendor" but "stop requiring trust in any single vendor at all."

Next: Part 2 — The Governance Lesson for Treasury Companies