The Coldcard Seed Entropy Flaw (July 2026): Who's at Risk and Exactly What to Do

Security advisory — updated 31 July 2026. This is a fast-moving incident. The technical scope is still being refined by both Block and Coinkite, and the numbers below come from their public disclosures as of this writing. If you generated a seed on a Coldcard, read the "Who is affected" section and act — do not wait for the story to fully settle. And a warning that matters on a day like this: no legitimate party will ever ask for your seed words, and no website can "check" whether your seed is affected. Firmware comes only from coldcard.com, verified.

In a 25-minute window on 30 July 2026 (01:31–01:56 UTC), roughly 594 BTC (about $38 million) was swept out of around 500 separate single-signature wallets, and more funds remain exposed on weak seeds that have not yet been swept. The wallets had one thing in common: their seeds were generated on a Coldcard hardware wallet. This is not a phishing story, not malware on someone's laptop, and not a leaked paper backup. The seeds themselves were weak from the moment they were created, because of a firmware bug in how the device generated randomness.

We say this as a site that has recommended Coldcard for years as a serious cold-storage device — including in our own hardware wallet buying guide and Coldcard setup guide. That is exactly why we are covering it plainly: trustworthy seed generation is one of the two critical jobs a hardware wallet exists to do, and here it failed. Below is who is at risk, why it happened, and the precise steps to move your funds to safety.

What went wrong, in one paragraph

A wallet's private keys live in a search space so large (~2²⁵⁶) that nobody can guess them — if the seed behind them was picked with real randomness. A 24-word seed encodes 256 bits of entropy (12 words encode 128); Coldcard generates 24 words by default. A firmware error that shipped in Coldcard v4.0.0 in March 2021 caused affected devices to skip the hardware random number generator and fall back to a predictable software generator seeded by non-secret chip data (the device's serial number and timer registers). According to Block's engineering write-up, the root cause was a macro/library mismatch: the firmware defined MICROPY_HW_ENABLE_RNG as zero, but a supporting library, libngu, checked whether that macro was defined rather than whether it was enabled — so seed generation silently fell back to MicroPython's deterministic "Yasmarang" generator. The result: instead of an astronomical range, some devices were drawing seeds from a small, enumerable one. An attacker could pre-compute those candidate seeds offline, check which ones held bitcoin, and sweep them — without ever touching your device or your backup.

How weak, by model — and where the two disclosures disagree

The severity is not uniform, and the two primary sources do not fully agree. Read both numbers for your model:

• Coldcard Mk2 and Mk3 — the confirmed-theft group. Block identifies the vulnerable code path in firmware v4.0.0 through v4.1.9 (merged 1 March 2021, shipped 17 March 2021); Coinkite's user advisory frames the affected Mk3 range as 4.0.1 through 5.0.3, the last supported branch for that model. Check your firmware against both ranges. Block puts the search space at fewer than 2^40.7 candidates as a ceiling — and warns that when the chip's unique ID and call history are known, generation can become fully deterministic. Coinkite rounds this to "about 40 bits." Either way: reported estimates put brute-forcing it at roughly a day on a single machine with a GPU.
• Coldcard Mk4, Q, and Mk5 — the disputed group. These models mix in extra entropy from their secure element at boot. Coinkite estimates ~72 bits effective; its user-facing Mk3 advisory says the Mk3 issue does not extend to these models, while its own technical backgrounder quantifies them at ~72 bits — which is why the 5.6.0/1.5.0Q emergency firmware exists at all. Block is more pessimistic: it reports the reseed truncates the secure element's contribution to at most 32 bits of secret entropy (~2³¹ average enumeration effort), because the remaining bits derive from non-secret data. Until that discrepancy is resolved, the prudent position is to treat a single-sig seed generated on-device on a Mk4/Q/Mk5 before the emergency firmware as potentially brute-forceable — not as comfortably safe.

Coinkite has stated that TAPSIGNER, SATSCARD, and OPENDIME are not affected (different code and architecture), and seeds created before the March 2021 change are not affected.

Who is affected

Work through this honestly — the question is always "where did the seed come from," not "which box is it in now." And one default rule up front: if you cannot establish on which device and firmware your seed was generated, treat it as affected.

• Act now (highest risk): you generated a seed on a Mk2 or Mk3 running the vulnerable firmware (v4.0.0/4.0.1 onward), held single-sig, with no BIP-39 passphrase (or a weak one). Your funds may already be reachable by an attacker.
• Act now: a multisig quorum where the number of affected signers meets or exceeds your signing threshold — two vulnerable Mk3s in a 2-of-3 is enough; it does not take all three. If enough keys are guessable to sign, the quorum is spendable.
• Act now (scope disputed, don't gamble on it): a modern Mk4/Q/Mk5 single-sig with no passphrase, seed generated on-device before firmware 5.6.0/1.5.0Q. Coinkite's estimate (~72 bits) suggests you have time; Block's (~2³¹ effort) suggests you may not. Migrate.
• Plan a calm migration (weeks, not minutes): any of the above plus a strong BIP-39 passphrase. Coinkite's early analysis is that funds behind a passphrase are at minimal risk from this issue — the passphrase is doing its job as a second lock. But because the base seed is weak, an attacker who enumerates it can then attack your passphrase offline at scale. "Strong" therefore means high-entropy and randomly generated — think six or more truly random words (~128 bits), never a name, date, or memorable phrase, and never typed into a phone, browser, or compromised computer. If your passphrase doesn't meet that bar, you belong in the "act now" group.
• Not at emergency risk: a Coldcard seed inside a multi-vendor multisig (e.g. Coldcard + BitBox + Trezor in a 2-of-3) — one weak key is not enough to spend as long as your affected signers stay below your threshold, and the swept wallets were single-sig. Or a seed you generated with verifiable dice entropy: Coinkite counts 50–98 independent, private rolls as ≥128 bits (safe from this issue) and 99+ rolls as ~256 bits — if you rolled fewer than 50, treat the seed as affected. Or any seed created before March 2021.

Exactly what to do

The single most important rule: do not reuse a potentially weak seed, and do not erase anything until your funds are confirmed somewhere safe. Buying a new device and importing the same words does nothing — you would move a guessable seed into a new box.

1. Verify your existing backup — and erase nothing yet. Confirm you have a correct, readable backup of your current words before touching anything. Your old seed must stay loaded and spendable until the migration is finished.
2. Emergency stopgap (acute group): add a strong passphrase and move funds behind it today. This is Coinkite's own first-line mitigation and it requires no new hardware: create a high-entropy, unique BIP-39 passphrase on the device, which derives a brand-new wallet, and send your funds there. Two non-negotiable checks, because every passphrase — including one with a typo — produces a valid wallet: verify the new wallet's master fingerprint on the device screen against your coordinator before sending anything, and verify the receive address on-device. This is a stopgap, not the destination: the base seed underneath is still weak.
3. Update firmware — modern models only. Coinkite's emergency hotfix — 5.6.0 for Mk4/Mk5 and 1.5.0Q for the Q — fixes entropy generation going forward. Download only from the official Coldcard downloads page and verify it. Two things it does not do: it does not repair any seed already created on affected firmware, and there is no hotfix for Mk2/Mk3 — those models need the migration below, not an update.
4. Generate the new permanent seed on an unaffected device, with dice. The clean path is to create the new seed on a patched modern Coldcard (after step 3) or another vendor's device — using 99+ dice rolls, which Coldcard hashes directly without using the device RNG at all (Coinkite's own description). On Mk4/Q/Mk5 the Seed Vault lets you hold the new seed alongside the old one. If a Mk3 is your only device: Coinkite documents an advanced dice-only path (an empty Mk3 on firmware 4.1.9, 99+ rolls), but the erase-and-restore dance it forces — erase, create new seed, record an address, restore the old seed from backup to sign the sweep, then restore the new one — adds a failure point at every restore. The passphrase stopgap from step 2 is the safer route while you obtain an unaffected signer.
5. Move the funds — how you do it depends on your risk group. If you are in the acute group and have not already secured funds behind the step-2 passphrase, assume the attacker holds your key too: sweep all UTXOs in a single transaction with a competitive fee, into the new wallet, leaving no change behind on the weak seed — a slow, partial migration gives an attacker time to race you. If you are in the calm group, do it deliberately: a small test send first, confirm you control the destination (fingerprint + on-device address check), then move the rest. Our transfer guide and seed backup test cover the mechanics.
6. For meaningful holdings, upgrade the architecture. This incident is the textbook argument for multi-vendor multisig: with independent seeds from different manufacturers, a single implementation flaw in one vendor cannot drain you — which is why every swept wallet was single-signature.

The lesson that outlives this bug

Cold storage security depends on two things, not one: physical isolation and the quality of the randomness at the moment the seed is born. A reputable hardware wallet does not remove the second risk if you trust its generation process blindly. That is why the "advanced" practices — a strong passphrase, self-generated dice entropy, real multi-vendor multisig, and the ability to rotate to a new seed without drama when something like this happens — are better understood as baseline controls for serious amounts. No single layer replaces the others. The people who layered them are the ones reading this week's news calmly.

We will update this page as Block and Coinkite refine the scope. If you know someone who uses a Coldcard and doesn't follow Bitcoin news closely, send them here — a heads-up may be the difference between acting and losing funds.

Frequently Asked Questions

Does updating the firmware fix my existing seed?

No. The 5.6.0 / 1.5.0Q hotfix makes newly generated seeds safe. A seed created on affected firmware stays weak forever — the only fix is generating a new seed properly and moving the funds to it.

Is the Coldcard hardware itself broken?

No. This was a firmware bug in how randomness was gathered, not a flaw in the secure elements or the physical device. A patched device generating a dice-roll seed is sound. The trust lesson is about verifying generation, not about the box.

Are TAPSIGNER, SATSCARD, or OPENDIME affected?

No. Coinkite states they use different code and architecture and are not affected. Seeds generated before March 2021, and seeds built from 50+ independent private dice rolls, are also outside this issue.

I'm in a multisig — do I need to panic?

Count your affected signers against your threshold: two vulnerable Coldcards in a 2-of-3 can already sign — that needs urgent action. Below the threshold, one guessable key cannot spend, and the wallets swept in this incident were single-signature; plan an orderly replacement of the weak signer.

Sources

• Block Engineering (30 Jul 2026) — Predictable RNG Fallback and 32-Bit Reseed in COLDCARD Firmware
• Coinkite (30 Jul 2026) — COLDCARD Mk3 seed generation warning and Technical Deep Dive into the Entropy Issue
• Coldcard — official firmware downloads
• CoinDesk (31 Jul 2026) — Major bitcoin wallet flaw drains $38 million worth of BTC in 25-minute sweep
• Lunaticoin (31 Jul 2026, Spanish) — FONDOS EN RIESGO: Qué ha pasado en COLDCARD y CÓMO actuar