Coldcard Mk3 Entropy Bug: 594 BTC Swept—Who Must Migrate Now
A coordinated sweep removed approximately 594.5 BTC from around 500 single-signature addresses. Coinkite has now confirmed a seed-generation entropy defect affecting Mk3 and pre-hotfix Mk4, Mk5 and Q seeds—and installing new firmware alone does not repair keys that already exist.
On July 30, 2026, roughly 594.5 BTC moved from about 500 single-signature addresses in a tightly coordinated sweep. Exposure depends on the model and firmware that generated the secret: Mk3 seeds created on 4.0.1 or later face the most severe official warning, while Mk4 and Mk5 seeds created before 5.6.0 and Q seeds created before 1.5.0Q also require action. A verified original contribution of at least 50 private dice rolls or a strong, unique BIP-39 passphrase changes the risk, but nobody should ever enter seed words into a website or “checker.”
Check these four things first
- Which model generated the seed?
- Which firmware was active when the seed was created?
- Were at least 50 fair, private dice rolls added before the final words appeared?
- Has the wallet always used a strong, unique BIP-39 passphrase?
Move promptly, but verify every step. A wrong address, mistyped passphrase, bad backup or fake migration site can produce a faster and more certain loss than the entropy issue.
Seed-safety rule
Seed words must only ever be displayed or entered on trusted hardware during an intentional recovery. No website, browser extension, phone app, support representative or “entropy checker” needs them.
Key takeaways
- The entropy defect is real, but every swept address has not been independently attributed to COLDCARD.
- Mk3 device-generated seeds on 4.0.1+ are the highest-priority group in Coinkite’s advisory.
- Mk4/Mk5 seeds created before 5.6.0 and Q seeds created before 1.5.0Q are also in scope.
- Updating prevents future weak generation; it does not add entropy to an old seed.
- At least 50 original, fair and private D6 rolls change Coinkite’s classification; fewer or uncertain rolls do not.
- A PIN is not a BIP-39 passphrase, and even a strong passphrase is not a substitute for permanent migration.
What happened in the 594 BTC sweep
The blockchain shows a coordinated operation: about 500 transactions consumed 1,324 UTXOs from roughly 500 single-signature addresses, moving approximately 594.5 BTC. Confirmations appeared across blocks 960188, 960189, 960190 and 960191.
The confirmation span was about 01:36–01:51 UTC, or 15 minutes. CoinDesk’s broader reconstruction uses approximately 01:31–01:56 UTC, including broadcast activity. State the measurement before calling it a 15- or 25-minute sweep.
Atlas21 reported roughly 0.044 BTC in fees, a 0.41 BTC median source balance, a 29.9 BTC maximum and no analyzed source below about 0.15 BTC. About 562 BTC was consolidated into one output and was still reported as unmoved when the cited reports appeared. At $63,757/BTC, checked at 10:31 UTC July 31, the sweep was worth about $37.9 million; refresh that conversion before publication.
Is the theft conclusively tied to COLDCARD?
Not address by address. The defect is confirmed, Coinkite has issued migration guidance, and Block’s code analysis says active exploitation was underway. Public victim accounts include COLDCARD-generated seeds, and dormant-UTXO dates overlap the vulnerable period. Weakly generated keys are therefore a strong explanation.
I would not call this “500 confirmed COLDCARD users.” Evidence does not prove that every address came from one model, that every complete seed was recovered or that every affected model has a confirmed victim. Partial drains could reflect limited wallet-path scanning or recovery of individual keys. Coinkite’s suggestion that automated or AI-assisted review may have found the bug is speculation, not attacker attribution.
| Claim | Status |
|---|---|
| Entropy bug exists; 594.5 BTC sweep occurred | Confirmed |
| Mk3 4.0.1+ and pre-hotfix Mk4/Mk5/Q are exposed | Confirmed advisory |
| Every victim used COLDCARD | Unconfirmed |
| Attacker recovered full seeds or used AI | Unconfirmed/speculation |
| Taproot prevents weak-entropy attacks | Unsupported |
Which COLDCARD devices and firmware versions are affected?
The first thing I would establish is how and when the seed was created.
| Device | Firmware at creation | Assessment | Response |
|---|---|---|---|
| Mk1 | Any | Outside this regression | No action solely for this bug |
| Mk2/Mk3 | Through 3.2.2 | Outside this regression in Block’s analysis | No action solely for this bug |
| Mk2 | 4.0.0–4.1.9 | Vulnerable path per Block; not clearly classified in Coinkite’s headline advisory | Treat as potentially affected; seek clarification |
| Mk3 | 4.0.0 | In Block’s technical timeline | Treat conservatively as affected |
| Mk3 | 4.0.1–4.1.9 | At risk under Coinkite’s advisory | Migrate promptly |
| Mk4/Mk5 | Before 5.6.0 | Affected | Upgrade first, then create a new seed and migrate |
| Q | Before 1.5.0Q | Affected | Upgrade first, then create a new seed and migrate |
| TAPSIGNER / OPENDIME / SATSCARD | Any | Outside this issue per Coinkite | No action solely for this bug |
Block starts the Mk2/Mk3 defective path at 4.0.0; Coinkite’s public action threshold starts at 4.0.1. No public explanation for that difference was found, so 4.0.0 is not a basis for reassurance. The official archive lists 4.1.9 as final Mk3/Mk2 firmware; 5.0.3 belongs to Mk4.
Why your seed’s origin matters more than your device’s age
A weak seed remains weak after restoration to another wallet. A securely generated external seed does not become weak merely because it is imported into an affected COLDCARD. Model, firmware at generation, entropy source, dice, passphrase and auxiliary functions matter; purchase date, current firmware and air-gapped storage do not retroactively change the secret.
Quick risk classifier
| Secret origin | Classification | Response |
|---|---|---|
| Mk3 4.0.1+ device-generated, no/weak passphrase | Migrate promptly | New seed and on-chain transfer |
| Same with a strong, unique passphrase | Interim barrier | Preserve it exactly, then migrate |
| Mk3 with 50+ verified private rolls before final words | Outside this issue under Coinkite’s position | Verify procedure |
| Mk4/Mk5 before 5.6.0; Q before 1.5.0Q | Migrate promptly | Install fixed firmware before generation |
| New seed after fixed firmware | Fixed-generation scope | Verify backup, XFP and address |
| Independently generated imported seed | Outside primary scope | Review auxiliary secrets |
| Affected seed restored elsewhere | Still affected | Migrate |
| Origin/firmware unknown | Treat as affected | Migrate carefully |
| Random Seed XOR mask or paper key on affected firmware | Specialist review | Replace affected secret |
| Multisig with enough vulnerable keys to meet threshold | Quorum exposed | Specialist migration |
| One vulnerable key below threshold | No threshold failure by itself | Replace the key carefully |
The RNG integration error explained without code
During a 2021 migration, secret generation moved to a random-byte function whose library check asked whether a hardware-RNG macro existed, not whether it was enabled. The macro existed but was zero, so calls fell through to MicroPython’s Yasmarang software generator, initialized from device and timing data rather than a cryptographically secure source.
Block says affected Mk2/Mk3 version-4 firmware received no cryptographic reseed through this path. Mk4, Mk5 and Q mixed secure-element data, but only four bytes changed one 32-bit state word. Hashing limited inputs cannot create more possibilities. SHA-256, BIP-39 and Bitcoin were not broken; the integration of randomness was.
Why Mk3 exposure is more severe—and why “72 bits” needs context
Coinkite estimates about 40 bits for affected Mk3 generation and about 72 bits for Mk4/Mk5/Q under its model. Block warns that timers may correlate, identifiers may be partly known and a raw ceiling near 73 bits is not 73 bits of independent security. For a fixed fallback state and call history, it identifies at most 2³² secure-element reseed streams.
No universal cracking time follows. Cost depends on device, attacker knowledge, timing, UID, call history, derivation work and hardware. Block had not completed full end-to-end testing before disclosure.
Does installing firmware 5.6.0 repair an old wallet?
No. An update fixes future generation; it cannot add entropy to existing keys. Install verified 5.6.0+ on Mk4/Mk5 or 1.5.0Q+ on Q before creating a replacement. Use the official downloads and upgrade-verification guide, then check the post-install version on-device.
A new Mk5 or Q may ship with older firmware, so buying one is not enough. For destination research, see our COLDCARD review, hardware-wallet guide and secure-storage guide.
Are dice-generated COLDCARD seeds affected?
Coinkite says a seed is outside this issue if at least 50 fair, independent and private D6 rolls were added before the final words appeared. Fifty rolls contribute about 128 bits; 99 contribute about 256. Fewer, uncertain, recorded or reused rolls should be treated as affected. Never enter real rolls on a connected computer.
On fixed firmware, Coinkite says device entropy is sufficient and dice are optional—not a mandatory repair.
Does a BIP-39 passphrase protect an affected seed?
A strong, unique BIP-39 passphrase creates a different wallet and an independent guessing barrier. A name, quote, common phrase or reused password may be weak.
The COLDCARD PIN is not a passphrase. It protects physical device access, not keys reconstructed offline. Every passphrase typo creates another valid wallet, so back it up exactly and separately, record the XFP, power-cycle, re-enter it and confirm the same XFP. Coinkite still recommends a new-seed migration.
What single-signature users should do in the next 48 hours
This is an editorial plan, not an official deadline. Active exploitation makes delay unwise; rushed migration remains dangerous.
First 15 minutes
Ignore unsolicited support. Never enter a seed in a checker or use an address supplied by support. Check funds with an existing watch-only wallet or known public addresses, then record model, seed origin and firmware at generation. Unknown means potentially affected.
Today
Choose a verified destination. Install fixed firmware before generation. Create a new seed, back it up offline, recheck the words, power-cycle and confirm the XFP. Verify a receive address on the device. Send a small test, wait for confirmation and prove control before moving the remainder.
Next 48 hours and after
Transfer carefully, verifying every address. Splitting a transfer only limits operational-error impact; it does not change cryptographic exposure. Check expected accounts, change branches, passphrase wallets, temporary seeds and paper wallets. Keep the old backup until reconciliation is complete, then mark it retired, replace old allowlists/descriptors and never receive to it again.
See our wallet safety and recovery guide and asset-protection guide.
How to migrate without losing funds to a rushed mistake
| Mistake | Danger | Safer alternative |
|---|---|---|
| Seed in a checker | Immediate theft | Never disclose it |
| Generate before updating | Another affected seed | Verify fixed firmware first |
| Skip test transaction | Hidden address/backup error | Send and confirm a test |
| Confuse PIN/passphrase | No offline protection | Verify BIP-39 use |
| Lose or mistype passphrase | Permanent loss/wrong wallet | Separate backup and XFP check |
| Reuse old addresses | New funds return to exposed keys | Replace allowlists |
| Destroy old backup early | Missed accounts become unrecoverable | Retain until reconciled |
| Use factory firmware | May predate hotfix | Upgrade first |
What to do when an Mk3 is the only available device
Coinkite’s temporary option is a strong passphrase created entirely on-device: follow its passphrase guide, back it up separately, verify the XFP and destination address, and test before moving. Treat it as interim protection.
The advanced replacement path requires an empty Mk3 on 4.1.9, Import Existing → Dice Rolls, and at least 99 independent D6 rolls. Do not substitute New Wallet. One-device seed switching, restoration, backup and XFP checks make this error-prone; follow the complete official procedure.
Paper wallets, Seed XOR and other affected functions
Block found other secrets using the construction:
| Function | Potential impact | Review |
|---|---|---|
| New/ephemeral seeds | Weak wallet or temporary secret | Replace if affected |
| Random paper-wallet keys | Direct key exposure | Migrate; dice-only path differs |
| Random Seed XOR masks | Weak random mask | Recreate |
| Default deterministic Seed XOR split | Different path | Confirm mode used |
| Some cloning, USB, Key Teleport, Web2FA, Secure Notes and HSM material | Feature-specific risk | Rotate under official guidance |
An imported primary seed can be sound while an auxiliary secret is weak. See our paper-wallet resources.
Why no online entropy checker can safely test your seed
Risk is classified from generation history; no legitimate checker needs the words. Expect fake emails, ads, download pages, extensions, QR codes, screen-sharing requests, giveaways and compensation claims. Treat anyone who contacts you first as hostile.
An xpub cannot spend, but it exposes addresses, balances and history. Do not share it casually or create a watch-only wallet by uploading a seed. See our crypto-scam guide.
What the initial victim pattern does—and does not—prove
Atlas21 counted 490 native SegWit, five legacy and five nested SegWit addresses, with no Taproot victims. Taproot is not a defense: a weak master secret can affect every derived address. The pattern may reflect usage, scanning coverage or a balance threshold. Unmoved UTXOs are not proven safe.
No multisig output appeared in the initial set, but a quorum made from enough vulnerable keys can still fail. One vulnerable key below the threshold is a different risk and should be replaced carefully.
The questions Coinkite and wallet auditors still need to answer
The disclosure raises questions that should be addressed without inventing conclusions:
- Why did an open-source codebase not reveal the fallback earlier?
- Which automated tests should have failed when the hardware RNG was disabled?
- Why was a non-cryptographic PRNG reachable from secret-generation code?
- Why did the later reseed retain only 32 bits?
- Should entropy-source tests become mandatory in hardware-wallet audits?
- Should production devices expose entropy-health evidence?
- How should vendors design emergency key-migration communications?
- What does this incident show about long-term firmware maintenance?
My conclusion: the safe response is a new key, not a firmware-only fix
This is a key-generation failure, not a failure of Bitcoin. For an affected single-signature wallet, the durable response is a new seed created through verified fixed or independent generation, followed by an on-chain transfer.
Move promptly without converting cryptographic risk into operational loss: verify firmware, backup, XFP, address and test transaction. Keep the old backup until reconciliation is complete, and never enter seed words online.
Frequently asked questions
What is the COLDCARD entropy bug?
Affected firmware used a predictable software RNG fallback, with absent or limited cryptographic reseeding, when generating secrets.
Was 594 BTC really stolen?
The 594.5 BTC sweep is confirmed on-chain; attribution of every address to COLDCARD is not.
Which Mk3 firmware is affected?
Coinkite says 4.0.1+; Block traces the path to 4.0.0, which should be treated conservatively.
Are Mk4, Mk5 and Q affected?
Yes: Mk4/Mk5 seeds before 5.6.0 and Q seeds before 1.5.0Q.
Is Mk2 affected?
Block identifies Mk2 4.0.0–4.1.9. Seek direct Coinkite clarification and do not assume omission means safety.
Does updating protect an existing seed?
No. It fixes future generation; existing affected funds must move to a new seed.
Do 50 dice rolls change the risk?
Coinkite says 50+ fair, private D6 rolls added before final words protect against this issue alone. Uncertain means migrate.
Is the PIN a BIP-39 passphrase?
No. The PIN controls device access; a passphrase derives another wallet.
Does a strong passphrase permanently fix the seed?
No. It can add a strong interim barrier, but migration is still recommended.
Are imported seeds affected?
Independently secure imported seeds are outside the primary bug, though auxiliary secrets need review.
Must users buy a new wallet?
No. A verified updated Mk4/Mk5 or Q can generate a replacement; the Mk3 dice path is advanced.
Can an online tool check the seed?
No legitimate online tool needs the words. Entering them creates immediate theft risk.
