Between 01:31 and 01:56 UTC on Friday, 594 bitcoin left 500 wallets and never came back.
That is roughly $38 million in twenty-five minutes, moved as 1,324 chunks across 500 transactions inside a three-block window, with 562 BTC eventually consolidated into a single address that has not moved since.
The order in which the wallets emptied matters more than the total.
Chainalysis Reactor shows the attacker hit the largest balances first: cumulative losses hit roughly $30 million in the first ten minutes, then the sweep continued methodically through smaller wallets over the remaining fifteen. Among the ten largest victim wallets, three reportedly held $636K (10 BTC) or more.
You do not brute-force in that order, per this analysis. Brute force is blind — it finds whatever it finds, in whatever order it finds it. Prioritizing the fattest wallets first would, per this reasoning, require knowing, before you touch a single key, which keys are guessable and how much each one is worth.
That precision is the whole story. It means the weakness did not live in a user's backup, or their phishing hygiene, or their operational discipline. It lived in key generation itself — the one layer every user is told to trust completely and never inspect.
The weakness did not live in a user's backup or phishing hygiene. It lived in key generation itself — the one layer every user is told to trust and never inspect.
Here is what actually broke.
Coldcard's firmware calls a function to fetch randomness, and two implementations of that function sat in the codebase with identical signatures: the hardware generator Coinkite wrote, and a software fallback inherited from MicroPython.
A preprocessor guard was supposed to keep builds on the hardware path. But the guard checked only whether a setting was defined — not whether it was switched on.
So the build completed, cleanly, without complaint, against the fallback. No error. No warning. The device that was supposed to be your source of unguessable entropy was quietly seeding keys from the MicroPython substitute instead.
And that substitute drew from nonsecret chip data: the serial number and the clock registers.
The serial number is fixed factory metadata. The clock values are timing state an attacker can narrow or measure on a device of their own. Neither is a secret.
The result, on the Mk3, was reportedly a seed with roughly 40 effective bits of entropy against the 128 it was supposed to have. Block estimates the Mk4, Q and Mk5 reached about 72 bits thanks to extra entropy from their secure elements — better, but still short of target, and still short of unguessable.
The commit that introduced this dates to March 1, 2021, shipped in firmware 4.0.0. The drained coins spanned 2021 to 2026, matching the flaw's age almost exactly. For five years, devices reportedly presented on the premise that they make your key impossible to guess were shipping keys that could be enumerated.
Now the hardest part, because it is the part that dismantles the self-custody best-practice narrative.
The two largest victims had reportedly split their holdings across multiple independent wallets. This is textbook. It is exactly what the culture tells you to do — don't concentrate, don't create a single point of failure, spread the risk.
It made no difference. Every one of those wallets was generated by the same flawed firmware.
Redundancy assumes your failure points are independent. Splitting $4 million across multiple wallets protects you if the threat is a single compromised device or a single stolen backup.
It protects you against nothing if all those wallets were born from the same broken entropy source. Multiple weak keys are not more secure than one weak key. They are multiple weak keys, and the attacker who can guess one can guess all of them.
This is why the framing of "self-custody failure" is wrong. The victims, in the words of one commentator, were "the most knowledgeable and 'properly secured' bitcoiners." They ran dedicated cold-storage devices, kept coins offline for years, and split their funds precisely to survive theft.
They did everything the culture told them to do, and the flaw sat upstream of every one of those decisions — at the moment the key was generated, invisible and unfixable after the fact.
That last word is the one Coinkite keeps repeating in its own advisory. Updating the firmware does not repair a seed already created. A seed born weak stays weak — even, Trezor pointed out, if you restore it onto a different manufacturer's device. The weakness is baked into the key, not the hardware holding it.
Which brings us to how the flaw was found, and why the security model here does not just have a bug — it has a new adversary.
Coinkite says it has to assume "someone used AI to review previous versions of our firmware" to uncover the flaw. And in the detail that should keep every open-source maintainer awake: the company had run one of the best available models over its own code a few weeks earlier, and it "did not find this bug or anything serious."
Same tools, both sides. This time, in Coinkite's own words, it "did not help us, and only helped the bad guys."
Open-source firmware has always carried an implicit promise: many eyes make bugs shallow. But the eyes were human, occasional, and volunteer, while the flaw sat in plain sight for five years. AI does not get bored, does not skim, and does not stop at line 400. It reads the entire commit history, every version, looking for exactly this kind of silent divergence between what a guard checks and what it should check.
The maintainer scans the current code. The attacker scans every version that ever shipped — because old firmware means old seeds, and old seeds still hold coins.
That asymmetry is permanent now. Andrew Lazutkin of Tangem put the uncomfortable conclusion bluntly: this "is a good example of why open-source firmware should not automatically be equated with better security."
Look, finally, at the remediation, because the fix is itself a confession.
Coinkite's guidance for a safe new seed: a strong BIP-39 passphrase, at least 99 dice rolls, or both. Roll physical dice, ninety-nine times, to supplement the randomness the device was supposed to guarantee.
Casa's CEO called it a non-starter: "You just can't ask people to roll dice to be secure with your self custody. It's a non-starter for 99% of people."
He is right, and the reason he is right is the point. If the trust model worked, you would never touch dice. The device would make your key unguessable, and you would forget about it. Asking users to hand-generate entropy is an admission that the machine cannot be trusted to do the one thing it exists to do.
Blockaid's Ido Ben-Natan located the failure precisely: "a hardware wallet's security ultimately comes down to the firmware and systems users interact with but never see. That means safeguards have to be built in upstream, before a user ever takes control of their assets."
That is the shift. Security has moved upstream, become adversarial, and become continuous. The AI that scans your firmware never sleeps, and the seed you generated in 2021 is only as safe as a build guard you will never read.
The "set it and forget it" hardware key is a dead concept. Where the capital displaced by that death may flow is a separate question — one for the volatility-squeeze piece. This piece is only about why the trust that held it broke.
It broke at generation. Everything downstream — the cold storage, the wallet-splitting, the years of careful discipline — was built on a key that was never random to begin with.