Reviewed Is Not Verified: What the Coldcard Incident Shows About Evidence
An entropy flaw sat in open-source wallet firmware for five years before an attacker exploited it. What the Coldcard incident says about the gap between reviewable and verified.
A quiet flaw, then twenty-five minutes
On 30 July 2026, in a window of roughly twenty-five minutes, an unknown attacker swept about 594 BTC — around 38 million dollars at the time — from roughly 500 single-signature Bitcoin wallets, according to an analysis published by Block's engineering and security teams. The wallets shared one trait: their seeds had been generated on Coldcard hardware wallets, devices built by Coinkite and chosen specifically by security-conscious, Bitcoin-only users. By 2 August, on-chain researchers at Galaxy Research had attributed roughly 1,367 BTC — about 88.6 million dollars — across 4,585 addresses to three attack waves.
No device was opened. No key was extracted. No phishing message was sent. Every theft transaction was valid under Bitcoin's rules, signed with the correct private keys. The attacker did not break into the wallets; the attacker regenerated them.
Weak randomness, not broken cryptography
A Bitcoin private key is safe because it is one point in an astronomically large space. A standard 12-word seed encodes 128 bits of randomness — about 3.4 × 10³⁸ possibilities. No amount of hardware can enumerate a space that large; the security assumption is not that guessing is forbidden, but that it is hopeless.
That assumption holds only if the randomness is real. Coinkite's security advisory disclosed that seeds generated on certain Coldcard models and firmware versions carried far less entropy than intended: reporting on the disclosure put the effective figure at roughly 40 bits on affected Mk2 and Mk3 devices (firmware v4.0.1 through v4.1.9), and the advisory itself states about 72 bits, rather than the expected 128, on later Mk4, Mk5, and Q firmware before the fix.
Forty bits is about a trillion possibilities. That is still a large number, but it sits on the wrong side of feasibility: an attacker who knows the structure of the generator can enumerate candidate seeds offline, derive their addresses, and compare them against the public blockchain — no interaction with any victim or device required. The moment a derived address matches a funded one, the attacker holds its key. That is what appears to have happened here, at scale.
A build flag, not a failing part
The root cause, reconstructed in Block's analysis, was not a component that failed at runtime. It was a build-configuration mistake. The firmware defined a configuration macro as zero to disable one randomness path, but a supporting library checked only whether the macro existed — not its value. The check passed, and every request for randomness was silently routed to a non-cryptographic software generator called Yasmarang, seeded from a few predictable inputs: the chip's 32-bit unique identifier, a timer register, and the real-time clock.
The mistake entered the codebase with firmware v4.0.0 in March 2021 and persisted for more than five years. Nothing about it looked broken. Devices booted, seeds were produced, wallets worked, transactions confirmed. Every functional observation a user — or a tester — could make was consistent with a correctly working device. The defect lived precisely in the property that cannot be observed from output alone: whether the randomness was actually random.
The AI hypothesis
How the flaw was found is not established. What is documented is what Coinkite itself has said: the company stated it must assume someone used AI to review previous versions of its firmware, and that it had run one of the best available AI models over its own code a few weeks earlier — a review that did not surface the bug. Separately, press reports describe a developer reproducing the discovery after disclosure using an AI coding tool in a matter of minutes. None of this proves the attacker used AI; it is a hypothesis from the vendor, not a finding.
Whether or not this particular attacker used AI, the underlying economics have clearly shifted. Exhaustively re-reading years of old firmware releases used to be expensive, tedious, and rarely done — by defenders or attackers. Tools that can sweep entire code histories cheaply change what "obscure" means. A flaw that survived five years because nobody looked is a different kind of risk when looking becomes nearly free.
What open source and reviewed actually established
Coldcard's firmware is open source, and openness has long been treated as a security argument: anyone can read the code, therefore someone presumably has. The Coldcard incident is a sharp illustration of the gap in that reasoning. Availability for review is a precondition for verification. It is not verification. For five years, the decisive question — is this randomness cryptographically sound? — was answerable by anyone, and answered by no one who reported it.
This is not a new pattern. The 2023 Milk Sad disclosure documented how the Libbitcoin Explorer tool seeded wallet generation from a 32-bit timestamp, collapsing the keyspace to about four billion possibilities and enabling real thefts. The same year, Trust Wallet's browser extension shipped a comparable weak-entropy flaw. In each case the code was public, the failure mode was known to the field, and the discovery still came years after deployment.
The lesson is not that open source is a liability, and the wrong conclusion would be to retreat into opacity — hidden code has produced its own long history of latent flaws, with fewer paths to independent discovery. The lesson is narrower and more useful: openness creates the possibility of scrutiny, and possibility is routinely mistaken for the fact of it. What was missing in every one of these incidents was not access. It was a record of who actually examined what, with which methods, and what they established.
Bitcoin was not broken
It is worth being precise about what failed, because the distinction matters well beyond wallets. Bitcoin's protocol, hash functions, and signature scheme were untouched. The ledger did exactly what it is designed to do: it accepted validly signed transactions. The failure happened at the edge, before any cryptography ran — in the generation of the secret material a device fed into otherwise sound algorithms.
That boundary is the same one that governs any evidence system built on cryptographic commitments, including systems that anchor evidence to Bitcoin. A commitment anchored to Bitcoin establishes that the commitment existed no later than the confirmed anchor, and it makes any later alteration of the committed material detectable. It does not — and cannot — establish that the process which produced the committed material was sound. Cryptography verifies what it is given; it does not vouch for how the input came to be. Anyone building or buying assurance on cryptographic evidence should hold both halves of that sentence at once.
Reviewed is not verified — and evidence should say which
For data leaders, the transferable lesson is about the difference between assumed and demonstrated verification. Organizations routinely rely on claims with exactly the structure of "open source, therefore reviewed": the pipeline is documented, therefore it ran as documented; the quality checks are in the standard workflow, therefore they were executed; the dataset is the one that was assessed, therefore the assessment applies. Each claim may be true. What the Coldcard incident shows is how long a false one can survive when the property at stake is invisible in normal operation — and how abruptly the cost arrives when someone finally checks with adversarial intent.
The practical response is to demand evidence that distinguishes states which look identical from the outside. A declaration that a check occurred is different from a signed record of the check bound to the exact data state it examined. A claim that anyone could verify a delivery is different from a verification a recipient has actually performed. Systems fail quietly in the gap between those pairs; well-designed evidence makes the gap visible — it records what was verified, by whom, against what, and leaves the rest explicitly labeled as declared rather than demonstrated.
Five years of silence ended in twenty-five minutes. The window for treating "somebody could have checked" as equivalent to "somebody checked" is closing — for wallet firmware, and for data.
references
- Coinkite — Coldcard Security Advisory
- Block Engineering — Predictable RNG Fallback and 32-Bit Reseed in COLDCARD Firmware
- Decrypt — $38M in Bitcoin Drained by Coldcard Key Flaw Its Maker Thinks AI Found
- Decrypt — Coldcard Bitcoin Exploit Balloons to $88 Million as Attackers Keep Draining Wallets
- Milk Sad — Libbitcoin Explorer Weak Entropy Disclosure
See this evidence workflow on a real dataset.