In a 41-minute window between 01:10 and 01:51 UTC on July 30, 2026, spread across nine blocks, an attacker began sweeping bitcoin out of Coldcard wallets. The first wave took roughly 594 BTC, about $38 million. As of August 4, Galaxy Research puts confirmed losses at 1,596 BTC, roughly $100 million, drained from about 7,300 addresses across three confirmed waves plus fourteen smaller incidents. A suspected fourth wave, if confirmed, would take the total to roughly 2,055 BTC (~$130 million). Galaxy reports at least fifteen independent attackers now working the flaw, and that every coin taken in the first three waves remains unmoved. Many of the drained wallets had not seen a satoshi move since 2021.
Nobody was phished. No malware ran on anyone's computer. No exchange was breached, no smart contract was exploited, and no owner did anything wrong. The wallets were hardware wallets, held offline, which is the configuration normally described as the safe one.
The cause was a change to Coldcard firmware made on March 1, 2021. From that point forward, affected devices stopped using their hardware random number generator when creating a wallet. The keys they produced were guessable from the moment they were created, and they stayed guessable for five years until somebody did the guessing.
Everything rests on one number
When you set up a hardware wallet, the device generates a single large random number. That number is called the seed. Every private key in the wallet, and therefore every address and every coin, is derived from the seed by a fixed public formula that anyone can run.
That design is deliberate and normally good: it means your seed phrase alone can restore the entire wallet on any device. It also means the seed is the only secret. There is nothing else protecting the funds. If somebody learns your seed, they have your bitcoin, and no password or device or firmware update changes that.
So the security of a hardware wallet reduces to one question. Is the seed genuinely unguessable?
The intended answer is 128 bits of true randomness, which is roughly 3.4 followed by 38 zeros in possible values. That number is not searchable.
What the device was supposed to do, and what it did
A Coldcard contains a dedicated hardware random number generator, a component that produces genuine randomness from physical noise. That is what the seed was meant to come from.
A commit dated March 1, 2021, which shipped in firmware 4.0.0, changed a build setting so that the hardware generator was not actually being used. The failure that made this invisible is small and specific: a check in a supporting library tested whether the configuration setting was present, and never tested whether it was enabled. The check passed. The device believed it was drawing from hardware randomness.
What it drew from instead was a software substitute seeded from the chip's serial number and its clock registers. Neither of those is secret. A serial number is fixed and printed on the device. The clock value at the moment of setup falls inside a narrow, predictable range.
The result was an effective 40 bits of entropy rather than 128 on the Mk2 and Mk3. The later models are also affected, less severely on paper and worse in practice: the Mk4, Mk5, and Q produce roughly 72 bits of nominal strength, but Block's engineering team found only about 32 bits actually reaching the final seed.
Why 40 bits is not a smaller version of 128 bits
It is worth doing this arithmetic plainly, because the gap is not intuitive.
- 128 bits is about 340,000,000,000,000,000,000,000,000,000,000,000,000 possible seeds.
- 40 bits is about 1.1 trillion possible seeds.
A trillion sounds large. It is not. A single ordinary machine can work through a list that size, and a well-equipped attacker can do it quickly and cheaply. Forty bits is not weak randomness. It is, for practical purposes, zero randomness. The wallets were open the entire time to anyone who chose to look.
How that becomes a theft
This is the part worth understanding clearly, because the attack requires zero contact with the victim.
- Generate every seed the broken code could have produced. The attacker does this offline, on their own hardware, using the same public derivation formula the wallet uses.
- Derive the addresses for each candidate seed. Again, public formula, no interaction with anyone.
- Check those addresses against the blockchain. The blockchain is public. Anyone can see which addresses hold coins.
- Sweep whatever is funded. For any address holding bitcoin, the attacker already has the private key, because they just derived it in step one.
There is no step where the attacker touches your device, your computer, your email, or your exchange account. The entire attack is computation performed against public data. This is why nothing an owner did, and nothing an owner could have done differently in their daily habits, would have prevented it.
Why 25 minutes. All of the work above happens in advance. The moment the first sweep transaction hits the network, it is visible to everyone, and other people who have done the same computation begin racing for the remaining coins. So an attacker in this position precomputes the whole list and broadcasts everything at once. The narrow window is evidence of preparation, not of a fast attack.
Why those wallets. Every drained wallet was single-signature. Many had been dormant since 2021. The age of the coins tracks the flaw's timeline closely, which is what you would expect if the affected population is exactly "seeds created on the broken firmware and never moved."
The two things that worked
Nothing about user vigilance protected anyone here. Two structural choices did.
A BIP-39 passphrase. This is an additional secret you choose yourself, and it is mixed with the seed before any keys are derived. An attacker who reconstructs your exact seed still derives the wrong addresses without it. Coinkite's position is that seeds used with a passphrase are at minimal risk from this issue. The exception is a passphrase that was ever typed into an internet-connected device, which reintroduces the ordinary ways a secret can leak.
Multisig. A multisig wallet requires signatures from several keys, generally created on separate devices. Reconstructing one broken seed produces one key. If the wallet needs two of three, one key is not enough to move anything. Every wallet drained in this incident was single-signature, and that is not a coincidence.
Both of these are decisions made once, at setup, by people who were not reacting to any specific threat. The controls that held were structural, and they held against a failure mode nobody knew existed.
What to do if you hold a Coldcard
Assume you are affected if you own any Coldcard and generated its seed on the device after March 2021. Patched firmware by model:
| Model | Effective entropy | Fixed firmware |
|---|---|---|
| Mk2 / Mk3 | ~40 bits | 4.2.0 or later |
| Mk4 | ~72 bits nominal, ~32 measured | 5.6.0+ (Standard) · 6.6.0X+ (Edge) |
| Mk5 | ~72 bits nominal, ~32 measured | 5.6.0+ (Standard) · 6.6.0X+ (Edge) |
| Q | ~72 bits nominal, ~32 measured | 1.5.0Q+ (Standard) · 6.6.0QX+ (Edge) |
| Mk1, Tapsigner, Opendime, Satscard | not affected | no action |
Updating the firmware does not repair a seed that already exists. It only fixes generation going forward. The remediation, in order:
- Add a strong, unique BIP-39 passphrase on the device and move your funds to the resulting wallet. This is the immediate step, and it works because it changes which keys your seed derives.
- Update to the patched firmware for your model from the table above, then generate a completely new seed and move funds to it. A patched device is only safe for seeds created after the patch.
- Alternatively, generate the replacement seed using manual dice rolls, at least 99 of them. Dice supply entropy from outside the device, so the broken generator never participates. This works regardless of which model you hold.
Take care during the migration itself. Moving funds under time pressure is exactly the condition in which people make a different, more ordinary mistake.
Firmware updates fix future seed generation. They cannot repair a seed that already exists. Any seed created on the affected firmware is permanently compromised, and none of the stolen bitcoin is recoverable.
What is established and what is not
Two things deserve stating plainly, because reporting moved quickly and not all of it agrees.
The affected model list, and how this article got it wrong. On July 31 we reported that the Mk4, Q, and Mk5 were unaffected, because that is what Coinkite's advisory said at the time, and we treated the wider claims circulating that day as unconfirmed. Coinkite revised the advisory at 9:33am EDT on July 31 to add firmware fixes for those models, and the wider claims were right. We were reading secondary coverage that still carried the earlier version. The lesson is the one we printed and then failed to follow ourselves: on a fast-moving disclosure, go to the vendor advisory directly, and re-check it, because the vendor's own understanding changes by the hour.
How the flaw was found. Coinkite notes that its firmware source has always been publicly viewable, and suggests the attacker likely used an automated tool to review that code and find the defect before the company did. Coldcard co-founder NVK has framed this as AI-assisted code review finding latent bugs faster than experienced humans. Treat the AI attribution as informed speculation rather than established fact: no technical evidence of the attacker's tooling has been published. What is not speculation is that five years of public source went unexamined until someone with the right tooling looked.
The causal link. Coinkite initially framed its warning as precautionary rather than as a confirmed explanation of the thefts. Galaxy Research has since traced the sweeps and the attribution is no longer seriously in doubt, though a complete public forensic account has not been published.
Securing the unseen
Most crypto security advice concerns your behavior. Do not click that, do not type your phrase there, verify the address. That advice is worth following, and it would have done nothing here. The seeds were compromised at the moment of creation by a build flag five years ago, and the owners had no way to observe it.
This is the sharpest version of a pattern we keep finding when we take incidents apart. The expensive failures are rarely in contract logic. They are in keys, in the systems that generate and hold them, and in the operations around them, which is the same conclusion we reached taking apart the AFX validator-key drain. Here it goes one step further than usual: the keys were never sound to begin with.
What survives a failure you cannot see is structure. A passphrase means one recovered secret is not enough. Multisig means one broken device is not enough. Both cost you something in convenience, and both were the difference between the wallets that were emptied on July 31 and the ones that were not.
Learn more at 0xhades.io/research