The Pentest Nobody Ordered: The $130 Million Randomness Failure
How a five-year-old Coldcard RNG bug exposed Bitcoin wallets, drained 594 BTC in 25 minutes, and left a much larger pool of vulnerable seeds behind.
In twenty-five minutes, 594 bitcoin left five hundred wallets that hadn’t moved in years. Bitcoin wasn’t hacked, a wallet lied about its randomness. Every security system rests on an assumption nobody re-checks. This is what happens when that assumption was wrong from the first thirty seconds.
A Theft, or a Loss?
A hardware wallet promised true randomness for five years. Then a thief proved it had been lying, and the company found out the same night everyone else did.
Somewhere, a person bought bitcoin in 2021. Did the responsible thing: moved it off an exchange, onto a Coldcard, a small dedicated device built for exactly one job, generating a secret no one else could guess. Watched the screen produce twenty-four ordinary words. Wrote them on paper, not on a phone. Put the device in a drawer. Went on with five years of life.
She isn’t one person. Call her nothing, because that’s the point, she’s a stand-in for roughly five hundred wallets that all did the same thing, correctly, by every instruction the device gave them. The device was the one that lied. Starting around 01:10 UTC on July 30, 2026, while every one of those drawers sat closed and every one of those devices sat powered off, an attacker who had never touched any of them, anywhere, walked out with roughly 594 bitcoin in about twenty-five minutes, the largest balances taken first, more than $30 million in the opening ten minutes alone. Confirmed, on-chain, and not in dispute. The single largest chunk, 562 of those coins, sat consolidated in one attacker-controlled address within hours, unspent, motionless, like a confession no one has signed and no one has cashed.
Bitcoin was not hacked. Its elliptic-curve cryptography held. SHA-256 held. What failed sat one layer beneath all of it, in the place every security system quietly assumes is solved and almost never re-tests: whether the randomness at the very beginning was actually random.
Loaded dice
Here is the whole story in one image, and it’s worth holding onto because everything technical below is just this image with more decimal places.
Creating a wallet is rolling dice. Good entropy is a fair die, every face equally likely, no way to predict the next roll from the last. A hardware wallet’s job is to be a very good, very fast dice-rolling machine, one that rolls hundreds of times per second inside a chip built for nothing else, and hands you the result dressed up as twenty-four ordinary words. And the blockchain, public, permanent, unforgeable, is the casino’s overhead camera. It doesn’t stop a loaded die from being rolled. It just means that eventually, someone reviewing the tape can prove the game wasn’t fair.
What happened at Coinkite is that the dice-rolling machine broke, quietly, and kept handing out results that looked exactly like fair rolls. The camera kept running the whole time. Nobody thought to check the footage until money was already gone.
How the dice got loaded
Every Bitcoin wallet’s secret starts as raw entropy. BIP-39, the standard nearly every wallet uses, takes 128 to 256 bits of that randomness, appends a short checksum, and slices the result into eleven-bit chunks, each mapped to one of 2,048 words. Twelve words encode 128 bits; twenty-four words encode 256. The words are not the secret in any mystical sense, they are a human-readable costume worn by a very large binary number. A twenty-four-word Coldcard seed sounds twice as safe as a twelve-word one. It isn’t, once the dice underneath are loaded. You cannot out-word a loaded die.
Here is what the record confirms, carefully attributed. A March 2021 firmware integration error routed seed generation away from the device’s STM32 hardware random number generator and into a deterministic software fallback, MicroPython’s own generator, a routine called Yasmarang. According to Block’s analysis, the underlying cause was a library that checked whether a hardware-RNG flag existed rather than whether it was enabled, quietly binding affected builds to the software path. Critically, Yasmarang isn’t seeded once and left alone: Block’s own framing is that an attacker who can determine or sufficiently constrain three things, the device’s unique ID, its timer state, and the prior sequence of RNG calls made before the key was generated, can reproduce candidate output streams entirely offline, without ever touching the device. That’s a narrower, harder target than “guess a fixed number,” but a small, enumerable one all the same, next to the effectively infinite space true hardware randomness is supposed to provide.
Yasmarang: Yasmarang is a deterministic software random-number generator. Unlike a true hardware RNG, it doesn’t create fresh physical randomness by itself; once its starting state is known or sufficiently constrained, its future output can be reproduced.
“RNG calls”: An RNG call is simply one request made to the generator for some random bytes. The number and timing of those calls matter because they change the generator’s internal state. In this case, an attacker would need to account not only for the device’s unique ID and timer state, but also for how many random values had already been requested before the seed was generated. That’s why the attack is better described as reconstructing a constrained sequence of possible outputs, rather than simply guessing one fixed secret.
The record is clear on mechanism: the hardware-RNG-flag bug, the fallback to Yasmarang, the dependency on device UID, timer state, and RNG-call history, these are what Block’s analysis documented, not conjecture. The resulting entropy is Coinkite’s own estimate, not an independently verified figure: roughly 40 bits on the older Mk2/Mk3, about 72 on the newer Mk4, Mk5, and Q, against the 128 a twelve-word seed is meant to carry. Block was careful to call this a reduction in search space, not a proven brute-force benchmark, no published exploit timing exists. The direction is solid. The exact difficulty of walking that smaller space is still an estimate, not a fact.
Exposure here is broader than a single model, and worth stating precisely: anyone who generated a Coldcard seed since 2021, on any model, Mk2, Mk3, Mk4, Mk5, or Q, is inside the affected population. What varies by model isn’t whether you’re exposed, but by how much: as mentioned earlier, roughly 40 bits of remaining entropy on the older Mk2/Mk3, about 72 on the newer lines. Two things exempt a seed regardless of model. At least 50 independent, private dice rolls entered at setup, real dice, the low-tech kind, supply roughly 128 bits Coinkite says the flaw never touched, because that randomness never passed through the broken generator at all. A strong, unique BIP-39 passphrase helps too, though Coinkite is explicit that this is a mitigation, not a repair, and still recommends migrating. Everyone else in the affected window, no dice, no passphrase, seed generated since 2021, should treat their seed as compromised whether or not anything has been taken yet. Wallets generated before 2021 are unaffected.
Multisig doesn’t buy an exemption either, and this isn’t inference, it’s what the researchers who build multisig tools for a living said directly. Wizardsardine, which builds Bitcoin multisig custody software, stated plainly that any setup where Coldcard signatures alone are sufficient to meet the signing threshold is at risk, and that miniscript wallets built the same way carry the same exposure. The logic is simple once stated: multisig’s safety argument depends on each key’s randomness being independent of the others. If every key in a 2-of-3 setup came from a Coldcard on the same vulnerable firmware, “requiring multiple signatures” hasn’t added the redundancy anyone assumed it had, it’s added the same broken process signing itself twice.
Even the start date is contested, Block traces the regression to firmware 4.0.0 in March 2021, while Coinkite’s own advisory lists the affected range beginning a version later, at 4.0.1. Foundation Devices’ CEO, examining the commit history, traced the bug to a single sweeping rewrite that same month, roughly 120 files changed, removing Coldcard’s last GPL-licensed code and adopting new cryptographic libraries, including Bitcoin Core’s own libsecp256k1. This wasn’t neglect. It was active, well-intentioned modernization, and the regression rode in with everything else the rewrite did right. The strongest independent confirmation of that timing isn’t in the commit log at all, it’s on-chain: Galaxy Research found that every drained wallet was created after March 17, 2021, which is about as close as blockchain forensics gets to a fingerprint match. The bug sat in that state, in open-source code readable by anyone, for roughly five years before it drained a single wallet. So much for the comfort that many eyes make all bugs shallow.
The casino camera, working exactly as designed
None of what came next required touching a single victim’s device. Once an attacker suspects a seed came from this specific broken machine, the attack runs entirely offline: reconstruct the small set of seeds the machine could plausibly have rolled, derive each candidate’s address the same way any wallet software would, and check that list against Bitcoin’s public ledger, which, being public, confirms a match without ever alerting the owner. No password prompt. No failed login. No signal on the victim’s end at all. The device stayed in the drawer, powered off, while its contents were matched against a candidate list computed somewhere else entirely, the camera doing its job, proving the roll after the fact, to a thief who checked the tape first.
The company found out with everyone else
Here is the sequence most coverage compresses into a single paragraph, and it changes the shape of the story once it’s laid out properly. This was not a known bug that finally got exploited. It was a live theft that forced the disclosure.
Coinkite has said it was unaware of the flaw until the day the sweep began. Independent security researchers, not the manufacturer, drove the first public alarm, Kevin Loaec of Wizardsardine was among the earliest practitioners to flag it publicly, ahead of any official advisory. Coinkite’s own first advisory named only the Mk3, on firmware 4.0.1 and later. Block’s engineers circulated an independent root-cause analysis at 01:49 UTC on July 31, roughly a day after the theft began, identifying the exact mechanism: an RNG integration error routing key generation through MicroPython’s deterministic Yasmarang fallback instead of the device’s hardware chip. Coinkite widened its own disclosure to cover the Mk4, Mk5, and Q lines a few hours later, at 06:46 UTC that same day. By August 1, Loaec was confirming publicly that the newer models were being actively drained too, the same day Galaxy Research’s tracked total kept climbing. The company was still revising its own account of which devices were exposed while an attacker, or attackers, were still emptying more of them.
That’s the real picture: not a slow-motion failure everyone had years to notice, but a sprint where the public understanding of the bug’s scope was still being revised while money kept moving. The five-year dormancy explains how the vulnerability got there. It doesn’t explain the response, nobody had time to be slow about that part.
The scale, meanwhile, refused to hold still, and refuses even now. The July 30 sweep of roughly 594 bitcoin was the opening wave, not the whole event; Galaxy tracked the full attack window at 41 minutes, from 01:10 to 01:51 UTC, with more addresses drained than the first wave alone captured. A second wave brought the confirmed total to 1,159 BTC by August 1; a third pushed it to 1,367 BTC, worth about $89 million, by August 2. By August 3, Galaxy drew an explicit line between what it could verify and what it merely suspected: 1,596 BTC across three confirmed waves and fourteen smaller footprints, held with high confidence, versus a fourth wave it believed was “substantially the work of an attacker” but had not confirmed, which, if included, would put the total closer to 2,000 BTC, or roughly $130 million. By August 5, press aggregation of on-chain data put total losses at that same $130 million figure. Read the pattern in that sequence, not just the headline number: every count so far has been a floor, not a ceiling. Behind one of those addresses is a name: Toronto entrepreneur Jonathan Goodman posted publicly that he lost roughly 18.25 bitcoin, worth about C$1.6 million, to the sweep, a real loss, on the record, standing in for what the running total otherwise keeps abstract.
The oldest bug, the newest reflex
Then Coinkite’s chief executive, Rodolfo Novak, said something worth being exact about, because the loose version of it has already spread further than the precise one. Coinkite’s advisory speculates that the attacker likely used AI-assisted code review to find the flaw in Coldcard’s public source, not that AI review is now benevolently surfacing old bugs for defenders everywhere, but that it may have handed an adversary a faster way to search five years of open-source history than any human team managed in that time. That’s a meaningfully different, and more uncomfortable, claim than “a new era of bug discovery.” It says the search for dormant assumptions got cheaper, and it didn’t get cheaper for the people defending them first.
Coinkite has been careful to call this a suspicion, not a finding, there is no confirmation of how the attacker actually found the bug, and security engineers were quick to point out that the failure mode itself needed no AI to explain it. This is among the oldest classes of bug in the field, This is among the oldest classes of bug in the field, the same basic failure mode has appeared in Debian's OpenSSL RNG failure, Sony's PlayStation 3 ECDSA nonce-reuse flaw, Android's SecureRandom failure, and the controversy surrounding Dual_EC_DRBG. None of those needed a language model to be found or exploited. What would be new, if Coinkite’s suspicion holds up, isn’t the bug. It’s the asymmetry: a defender who has to manually re-audit five years of commits against a growing list of once-solved assumptions, against an attacker who may only have needed to point a tool at the same code and ask it to look.
The deeper failure isn’t the flag, though, or even who might have found it first. It’s what the flag represents: a place where everyone, for five years, treated a solved problem as still solved. Hardware wallets exist to answer one question, is this random? and once Coldcard shipped an answer, no one, including the people who wrote the code, went back and asked it again. That’s the spine under every layer of this story, technical and human both. A false assumption doesn’t announce itself. It just sits in the code, correctly formatted, syntactically fine, quietly not doing what everyone believes it does.
This wasn’t even the first warning this year. In early July, weeks before Coldcard’s disclosure, researchers at Coinspect had already published findings on a separate weak-randomness flaw in older software wallets, a different bug, a different codebase, the same underlying failure mode, tied to more than $5 million drained across several blockchains since May. Two unrelated teams, two unrelated products, the same assumption quietly failing in the same season. That’s not a coincidence worth dismissing. It’s a pattern that was already visible before Coldcard confirmed anything, to anyone paying attention to the right layer of the stack.
What the patch cannot touch
Coinkite fixed the flag. Every affected track, Mk2, Mk3, Mk4, Mk5, Q, standard and Edge, has a corrected release, and going forward the machine rolls fair dice again. But a patch changes how the next roll happens. It cannot reach back and re-roll a die that was already loaded when someone read the result off the screen. A wallet built on a weak roll stays weak forever, firmware updated or not, until someone actively generates a new seed and moves the funds to it, and that migration is not automatic, not enforced, and depends entirely on an owner who read the advisory and acted on it. Somewhere between “seed generated in 2021” and “advisory published in 2026” sits five years of drawers nobody thought to reopen.
There’s a name worth giving this, because the shape of it will outlive Coldcard specifically. Call it entropy debt: a security promise made once, at creation, that compounds silently for as long as nobody re-tests it. Technical debt announces itself eventually, the software slows down, the build breaks, someone has to pay it off or watch the system degrade. Entropy debt is quieter than that. It carries no symptom at all. A wallet with loaded dice underneath behaves identically to one with fair dice, right up until someone else finds the loaded roll first. The debt doesn’t compound in visible interest. It compounds in the size of the population who never finds out they owe it.
The economics of a roll nobody has to re-check
This is where the story stops being only a security story. Migrating to a new seed costs something now, a network fee, a careful afternoon, the risk of a mistake made while moving the very thing you’re protecting. Not migrating costs nothing today, visibly. The bill only arrives if an attacker’s candidate list happens to include your specific address, out of a space Coinkite puts in the tens of billions on the worst-affected devices. That’s entropy debt’s actual mechanism: the safe action is expensive now, the unsafe action is free until the moment it isn’t, and the same person pays both the convenience and the eventual price. No patch changes that arithmetic. Only migration does, and migration is a choice nobody is forced to make.
It’s also an information asymmetry with no fix in sight. Bitcoin’s whole design lets anyone verify a balance, a transaction, a proof of reserves. It has no equivalent way to let a user verify, after the fact, that their own entropy was ever good. That check happens once, invisibly, inside a chip, and then disappears into twenty-four ordinary-looking words. A user can no more audit their own dice roll after the fact than a buyer can un-crack an egg to check it was fresh. The asymmetry runs one direction only: the manufacturer eventually finds out if the machine was broken. The user finds out only when someone else finds their wallet first, or never, if their wallet simply sits there, correctly migrated or not, for another five years.
The number underneath the number
Every entropy failure reduces to the same arithmetic in the end: how large is the space an attacker has to search, against how much sits behind it. At 128 bits, the space is larger than anything brute-forceable with existing or foreseeable compute, and the question is moot. At 40 bits, the space is one a well-resourced attacker can walk end to end, and the question becomes a cost-benefit spreadsheet, compute cost per candidate against expected bitcoin recovered per match. Once that spreadsheet turns positive, the incident stops being hypothetical. Five hundred wallets found in twenty-five minutes is what a positive number looks like once someone runs it.
The wallets are still there. The devices are still powered off, sitting in drawers, screens dark. Somewhere in that number is the woman from the opening, the one who did everything right in 2021, who wrote her words on paper and not on a phone, who has no way of knowing whether her particular roll was fair or loaded until someone, somewhere, finishes checking. She is still holding words she believes are secrets, the same words she was handed on the day the machine rolled for her without either of them knowing the dice were loaded. Somewhere between those two facts, the wallet that hasn’t moved and the search space that hasn’t gotten any smaller, is a race with no starting gun and no announced finish line: whether she migrates before the arithmetic finds her first.
Note on multisig
Multisig does not automatically protect against weak key generation. A multisig wallet is only as strong as the keys needed to satisfy its signing threshold.
For example, in a 2-of-3 wallet, an attacker would need two valid private keys to spend the funds. If all three keys were generated through the same vulnerable Coldcard RNG path, the keys may share the same underlying weakness, so requiring two signatures does not provide the independence normally expected from multisig.
But if the keys came from independent, unaffected sources, for example, different hardware wallets or externally supplied entropy, multisig can still provide meaningful protection. The important question is not simply “Was this wallet multisig?” but “How were the keys that can satisfy the threshold generated?”
Bottom line: Multisig provides redundancy only when the keys themselves are independently secure. Three keys produced by the same broken randomness process are not three independent rolls of the dice.
If this made you feel seen, challenged, or called you’re not alone. Lights On is for those who crave more than noise, trends, and surface takes. Your presence here means something. Subscribe and stay with the signal.
Sources:
https://wizardsardine.com/blog/