One Moment of Randomness
Part 1 of 6. This series is our attempt to work through the Coldcard incident together with you: what happened, why it was possible, and how self-custody gets safer for everyone. It gets technical as the series goes on, and we promise to keep it human. Today: the incident itself, and the question it forces.
Before anything else, the part that cannot wait until the end of an article: if you or anyone you know still holds coins on a Coldcard, move them. Not after the weekend. Now.
Generate a fresh seed on different, patched hardware and send everything there. A fourth wave of thefts ran through August 3, and the exploit was still in progress days later. Coinkite's own words: "Please treat this as urgent. Migrate your funds."
This is not a story about something that happened and ended. Wallets were still being drained a week in.
One practical note for anyone mid-rescue: the attacker is watching the same mempool you are. If your withdrawal is sitting unconfirmed, it can be outbid by a competing sweep of the same coins.
Use Replace-by-Fee, and pay whatever gets you into the next block. This is one of the very few moments in Bitcoin where overpaying on fees is the smart move. Alex Thorn, the researcher tracking the waves, gave the same advice: move immediately, fee up, win the race.
Now let's walk through what actually happened. Slowly, because the details matter for everything else in this series.
Twenty-five minutes
At 01:31 UTC on Friday, July 31, a Bitcoin wallet that hadn't moved in years signed a transaction.
Nothing about it looked unusual. The fee was ordinary, around 30 sat/vB. The signature was valid. To every node on the network, this was a dormant holder finally cashing out, the kind of transaction that happens every day.
Then a second dormant wallet signed. Then a hundred more.
By 01:56 UTC, twenty-five minutes after it began, 1,324 outputs had moved across 500 transactions packed into a window of just three blocks: 594 BTC, roughly $38 million, swept from about 500 separate wallets.
Most of it flowed into a single consolidation address, bc1qq85v2c926eg6pgxhwp6q7lf6cnsz80qs3fcu9r, where 562 BTC sat untouched.
Look at the craft of it. Consistent fee rates across hundreds of transactions. No change outputs anywhere, meaning each wallet was emptied to the satoshi in one clean motion. Batches sized to clear in consecutive blocks.
Rob Hamilton of AnchorWatch, who tracked the sweep in real time, described a fingerprint that reads as automated tooling: software written, tested, and aimed well in advance. Nobody improvises 500 perfect transactions in 25 minutes.
And it didn't stop. Hours later, Block security engineer Clay Garrett flagged a second wave: 695 more transactions carrying the same fingerprint. By August 2 the running total had reached 1,367 BTC drained from 4,585 addresses.
Then on August 3, Galaxy Research's Alex Thorn tracked wave four: another 449 BTC from 709 addresses. Total losses reached roughly 1,816 BTC across some 5,300 addresses. About $114 million.
The damage rippled outward too: bitcoin slipped under $63,000 as the scale became clear.
The victims did everything right
Here is the part that should stop you cold. The drained wallets did not belong to people clicking airdrop links or storing seeds in email drafts.
They belonged to Coldcard Mk3 owners: people who bought dedicated, air-gapped signing hardware, generated their seeds offline, and never let their keys near an internet-connected machine. No phishing. No malware. Nobody's device was ever touched, before or during the theft.
The targeting tells you everything about the preparation. Every drained wallet was single-signature. Each held more than 0.15 BTC. Most had been dormant for years, and their creation dates cluster between 2021 and 2026.
Dormant wallets were the perfect prey: high value, no monitoring, no alerts, owners who checked their balance twice a year and slept well in between. Some victims found out days later. Some may not know yet.
Imagine holding through two full market cycles, never selling, never moving, doing everything the hard way, and opening your wallet to a zero.
That creation-date window, 2021 to 2026, is the tell. It matches, almost exactly, the lifetime of a firmware bug.
The attacker already had the keys
A sweep this fast is not hacking in real time. Nobody brute-forces 500 wallets in 25 minutes.
The keys were computed in advance, offline, over days or more likely weeks. The attacker derived the addresses, matched them against the blockchain, watched the balances, built the tooling, and picked the moment. When the first transaction fired, every private key on the list was already in hand. July 31 wasn't a break-in. It was a harvest.
To understand how that is even possible, you need one idea, and it is the idea this whole series hangs on: every wallet you have ever created was born in a single moment. The instant a device picked your seed.
Everything that comes after, the steel backups, the air gap, the careful operational habits, only protects what was created in that moment. If the birth goes wrong, nothing downstream can ever repair it.
On Coldcard Mk3 devices, for five years, the birth went wrong.
The device carries a dedicated hardware chip whose only job is generating true randomness by harvesting physical noise. That chip is a large part of why you buy dedicated hardware at all.
But the firmware, which builds on the MicroPython runtime, also contains a software fallback for platforms that lack such a chip. The fallback stitches together "randomness" from predictable values like chip serial numbers and clock registers. For a game, harmless. For a seed, fatal.
Which path gets compiled into the firmware is decided by a configuration setting, and here is the entire disaster in one sentence: the check that read this setting tested only whether it existed, not whether it was switched on.
Like asking "is there a light switch on the wall?" when the question that matters is "is the light on?" The switch existed. The build system was satisfied.
Firmware version 4.0.1 shipped in March 2021 with the fallback quietly compiled in, on a device whose real randomness chip sat unused millimeters away. Every firmware through 4.1.9 carried it. No error, no warning, no visible difference in behavior, for five years, in open-source code anyone on earth could read.
The result: reported analysis puts the effective strength of affected Mk3 seeds at roughly 40 bits instead of the intended 128.
We unpack what a "bit" of randomness really means in part two, but here is the scale of the collapse. A 128-bit seed is a needle in a haystack the size of the universe, unguessable by every computer on Earth working together for longer than the universe has existed.
A 40-bit seed is about a trillion possibilities: a space that ordinary hardware can walk through completely, once, and keep forever. The attacker enumerated five years of possible weak seeds, derived their addresses, and simply collected the ones that held coins.
Check your device
From Coinkite's official advisory, the affected range:
- Mk2 and Mk3, firmware 4.0.1 through 4.1.9: the severe case. If your seed was generated on these versions, treat your funds as actively at risk and migrate now.
- Mk4, Mk5 and Q before the fixed versions (5.6.0 standard / 1.5.0Q): these produced about 72 bits of entropy instead of 128. Far harder to attack than the Mk3 case, and no thefts have been tied to it, but Coinkite calls it what it is: still serious. Migrate on your own schedule, but migrate.
- The dice-roll exception: if you added 50 or more of your own dice rolls when generating your seed, your entropy came from your dice, not the broken generator. Those seeds are safe from this specific flaw.
The advisory's order of operations matters, so follow it exactly: update the firmware first, then generate a fresh seed, verify the new backup and a receive address, send a small test transaction, confirm it arrives, and only then migrate everything. Keep the old backup until the migration is fully complete.
And one more honest sentence, whatever model you own: if your coins sit on any Coldcard, moving them costs you a transaction fee. Not moving them costs you sleep.
Updating firmware does not repair a seed that was born weak. Nothing does. That asymmetry decides itself.
One moment, one device
Sit with the shape of this failure for a moment. The people drained that week did everything our industry teaches.
Their loss was decided years before the attack, in a fraction of a second they never saw, by a code path they couldn't inspect, on the single device that generated their single secret.
Five years of flawless behavior afterward changed nothing, because the flaw wasn't in how the wallet was used. It was in how the wallet was born.
That is the real story, and it is bigger than one vendor. The entire security of a wallet, compressed into one moment of randomness on one machine. We made the architectural case for removing that single dice roll in One dice roll lost $38M. MPC rolls three., and this series takes the slower road to the same place.
Next in the series: what randomness actually is, and why the most expensive bugs in crypto history are all the same bug wearing different costumes. Then: what your 12 words really are, what the popular defenses fix and what they can't, and what wallet architecture looks like when that single moment doesn't exist at all.
A question before you go: do you actually know how the wallet you use today generated its keys? Not the brand. The mechanism. Most people have never asked.
And if you know someone still holding coins on an affected device, don't just share this article with them. Call them.