On July 31, 2026, roughly 594 BTC was swept out of Coldcard-generated wallets in about 25 minutes. The cause is a bug in Coldcard firmware that made the secret words some devices generated far easier to guess than they should be. If you created your seed phrase on a Coldcard at any point since March 2021, assume you are affected until you have checked, and plan to move your coins to a brand-new wallet.
The one-paragraph version
A Bitcoin wallet is only as secret as the randomness used to create it. Coldcard devices contain a dedicated chip whose entire job is to produce true randomness. Because of a coding mistake introduced in March 2021, the seed-creation process quietly stopped using that chip and used ordinary, predictable software randomness instead. The result: seeds that were supposed to be impossible to guess became guessable. Attackers guessed them, and started emptying wallets.
First, what a seed phrase actually is
Everything in your wallet flows from one starting point — a pile of random numbers. If an attacker can reproduce that pile of random numbers, they reproduce your entire wallet. Not "hack" it. Not "break the encryption." They simply recreate it, and then they can spend your coins as easily as you can.
How a wallet gets made — and where the bug livedThis is why the bug is so serious. Nothing later in the chain can rescue a starting point that was never random enough — the words, the keys and the addresses are all just math applied to that first step.
How much randomness went missing
Randomness is measured in bits. A Coldcard is designed to give your seed 128 bits — think of it as 128 independent coin flips that nobody witnessed. The affected firmware delivered far fewer. Each square below is one bit of genuine randomness.
Bits of real randomness in a device-generated seedCoinkite's own estimate. On an affected Mk3, roughly 88 of the 128 coin flips were never really flipped — an attacker only has to search what is left.
Why 40 bits is a catastrophe and 128 is not
Here is the part that trips people up: this is not a small shortfall. Every single bit you lose doubles how easy the wallet is to guess. Losing 88 bits doesn't make a wallet 88 times weaker — it makes it trillions of trillions of times weaker.
What it takes to guess a seed at each strength
~40 bitsMk3 — actively exploited
Guessable in hours on rented computing power. This is the level attackers broke this week.
~72 bitsMk4 / Mk5 / Q
Genuinely hard, but far below the margin the device promised — and margins only shrink as hardware improves.
128 bitswhat you should have had
Every computer on Earth working together would still be at it long after the sun burns out.
The bars are drawn in proportion to bits, which massively understates the real gap — because the difficulty doubles with every bit, the 128-bit bar is genuinely unreachable while the 40-bit bar is a weekend project. To be precise about the middle case: ~72 bits is not known to have been broken the way ~40 bits was, but it is nowhere near the security you paid for, and Coinkite says those seeds should be replaced too.
What actually went wrong in the code
In March 2021 the Coldcard team migrated some plumbing over to the same cryptography library Bitcoin Core uses. During that migration, the call that fetched randomness was swapped for a different one with an identical-looking name and shape. The new one resolved to MicroPython's built-in software random number generator rather than the hardware chip.
The developers had, in fact, tried to switch that software generator off. But the build-time check asked whether the setting existed rather than whether it was turned on — and since the team had explicitly set it to zero, the setting very much existed. The software generator got compiled in anyway.
The review gap, in a nutshell
What reviewers verified
"Is the true hardware randomness code present in the build?"
✓ Yes, it was there.
What nobody verified
"Does seed generation actually call it?"
✗ It didn't.
Think of a light switch wired to nothing. Everyone confirmed the switch was installed. Nobody flipped it and checked whether the light came on. The hardware randomness chip sat there, present and unused, for five years.
The timeline
Five years from mistake to theft
March 2021The bug ships in firmware 4.0.1
A library migration silently redirects seed randomness to software. Nobody notices.
2021 – 2026Thousands of wallets are created
Every seed generated on affected firmware carries the weakness, sitting quietly in cold storage.
July 31, 2026594 BTC swept in about 25 minutes
An attacker who had pre-computed the guessable keyspace drains wallets in a coordinated sweep. Galaxy Research later links roughly 1,200 addresses and over 1,000 BTC to the flaw.
July 31, 2026Coinkite publishes an advisory and emergency firmware
Fixed releases go out for every affected model, along with a technical write-up of the root cause.
Am I affected?
Work down these three questions in order.
Check your own situation
1. Where did your seed phrase come from?
SafeI created it somewhere else and only imported it into the Coldcard. The bug affects seed creation only.
Keep goingThe Coldcard generated it for me. Continue to question 2.
↓
2. Did you add dice rolls when you created it?
SafeYes — at least 50 fair, private rolls that were never written down or photographed. Your own dice supplied real randomness the bug could not touch.
Keep goingNo dice, or fewer than 50 rolls. Continue to question 3.
↓
3. Which model and firmware created the seed?
At riskMk3 running 4.0.1 through 4.1.9. This is the ~40-bit case — the one actively being drained. Move your coins now.
At riskMk4 or Mk5 before 5.6.0, or Q before 1.5.0Q. The ~72-bit case. Below the intended safety margin; Coinkite says replace the seed.
SafeSeed created on fixed firmware (Mk3 4.2.0+, Mk4/Mk5 5.6.0+, Q 1.5.0Q+), or on a device that predates the bug.
Not sure which firmware version you were running back when you set the device up? Most people aren't. Treat it as at risk and migrate — the cost of migrating unnecessarily is an afternoon and a transaction fee.
Affected and fixed versions
Model
Seed at risk if created on
Randomness
Fixed firmware
Mk3
4.0.1 – 4.1.9
~40 bits
4.2.0 or later
Mk4 / Mk5
anything before 5.6.0
~72 bits
5.6.0+ (Edge 6.6.0X+)
Q
anything before 1.5.0Q
~72 bits
1.5.0Q+ (Edge 6.6.0QX+)
The single most misunderstood point: updating your firmware does not repair a seed you already have. The weak seed was written down on your backup card years ago and the attacker's guessing job got easier the moment it was created. Updating protects the next seed you generate. You must create a new wallet and move your coins to it.
What to do, in order
Update the firmware first
Install the fixed release for your model from Coinkite's official download page, verifying the signature as you normally would. Nothing you generate before this step is trustworthy.
Generate a brand-new seed — with dice
On the updated device, create a new wallet and add at least 50 of your own dice rolls. This is belt-and-braces: even if the device's randomness were compromised again tomorrow, your dice carry the security on their own.
Back it up and verify the backup
Write down the new words, then confirm the device shows the same first receive address after a restore check. Do not skip this — you are about to trust this backup with everything.
Send a small test transaction
Move a token amount to the new wallet first and confirm it arrives and is spendable. Then, and only then, move the rest.
Move everything, and treat the old seed as burned
Sweep the remaining balance to the new wallet. Never reuse the old seed phrase for anything, and don't leave a dust balance behind on it.
What this does not affect
Seeds you created elsewhere and merely imported into a Coldcard. The bug is in seed generation.
Seeds created with 50+ private dice rolls, per Coinkite. At 99 rolls, your dice alone contribute roughly 256 bits.
TAPSIGNER, OPENDIME and SATSCARD — different products, different codebases.
Other hardware wallet brands. This is a Coldcard firmware bug, not a Bitcoin problem. Bitcoin itself worked exactly as designed here; it faithfully honored signatures from keys the attacker legitimately reconstructed.
The lesson worth keeping
The uncomfortable truth of this bug is that nothing looked wrong. The devices worked. The seeds looked random. Verification of the firmware signature would have passed. Public source code did not catch it for five years, because the code that mattered was present in the repository — it just was never actually called.
It's worth being precise about that last part, because "open source" gets used as a security guarantee it can't quite deliver. Coldcard firmware is source-available: GPLv3 until 2020, then relicensed to MIT plus a Commons Clause that forbids selling or building a commercial service on the code. Coinkite calls it "verifiable" rather than open source, which is fair — you can read it and reproduce the build, but the licence discourages the kind of active downstream forking that puts many independent eyes on a codebase. That's not what caused this bug, and plenty of fully open-source projects ship bad bugs too. But "you can read the source" and "someone competent has read this specific function" are very different promises, and only the second one would have caught this.
That is a strong argument for the two habits our community has always pushed: roll your own dice when you generate a seed, so your security never rests entirely on a manufacturer's implementation, and use multisig with devices from different vendors for meaningful amounts, so a single vendor's mistake can't drain you. Neither habit costs much. This week both of them look very cheap indeed.