On 30 July 2026 an attacker began sweeping bitcoin out of wallets whose seed phrases had been generated by Coldcard hardware wallets running vulnerable firmware. The first wave emptied roughly 1,196 addresses in about 41 minutes. Three weeks later the widely-quoted total is approximately 1,816 BTC from more than 5,200 addresses — about $116 million at the time, considerably more at today’s price. Those are Galaxy Research’s figures, which TRM Labs cites in its own tracing work; TRM’s contribution is the attribution and the ranking of this as the third-largest crypto theft of 2026. Galaxy separately puts confirmed losses at 1,596 BTC across three waves and roughly 7,300 addresses, with an upper estimate near 2,055 BTC (~$130 million) if a suspected fourth wave is verified. The counts differ by source and by which waves are included, and the address totals do not pair with the coin totals interchangeably. We range-cite rather than pick one.

We covered the waves as they happened, and we published an explainer on how seed entropy fails. This guide is the thing we did not have then and which now exists: a complete, primary-sourced decision procedure for working out whether a specific seed on a specific device was ever at risk, and exactly what to do if it was. Coinkite has since published a full fixed-release matrix across five separate firmware tracks, two explicit exceptions that determine the answer for a large share of owners, a live Security Status page, and — on 20 August, two days ago — a second firmware release that changes how every future Coldcard seed is generated. Almost nobody has written up the exceptions, and the 20 August release has barely been covered at all.

What actually broke

A Coldcard is supposed to build your seed from a dedicated hardware random-number generator — a physical entropy source on the board. On the affected firmware the device bypassed that chip during key generation and fell back to a software substitute that was far more predictable than it should have been. The seed still looked like twelve or twenty-four ordinary words. It simply came from a much smaller space of possibilities than the words implied.

The severity is not uniform across models. On Mk2 and Mk3 the reduction was catastrophic enough to make seeds enumerable by an attacker with ordinary resources. On Mk4, Mk5 and Q, per Coinkite’s own advisory, the affected seeds carry approximately 72 bits of entropy rather than the expected 128. That 72-bit figure is Coinkite’s own preliminary estimate and should be read as such: the wallet security firm Wizardsardine has put the real number lower, in the 50 to 60-bit range. Neither figure is trivially brute-forceable today for a single target, and both are far outside the safety margin a cold-storage device is sold on. Coinkite classes the Mk4/Mk5/Q impact as “not as severe but still serious.” Treat it as affected. And note that the formal technical post-mortem was still listed as in progress as of 15 August, so these numbers may move.

The bug entered Mk2/Mk3 firmware at version 4.0.1 in March 2021 and persisted through 4.1.9 — more than five years in the field before disclosure. TAPSIGNER, OPENDIME and SATSCARD are built on different codebases and are not affected — though that is Coinkite’s statement about its own proprietary code, not an independently audited finding.

Step 1: identify your track and version

There are five separate release tracks and they do not share a version numbering scheme. This is the trap that has caught the most people: Edge is a distinct track, and an Edge build with a numerically higher version than the fixed standard release is not automatically fixed. Check the row that matches your device and track, not the biggest number you can find.

Source: Coinkite Security Advisory (published 30 July 2026, updated 1 and 14 August) and the COLDCARD Security Status page, which publishes this table as the minimum fixed releases and also offers a machine-readable endpoint. Every entry reads “or later”.

The 20 August release: what changed, and what it does not change

On 20 August 2026 Coinkite shipped a second security release — 5.6.1 for Mk4/Mk5 standard and 1.5.1Q for Q standard — describing it as the product of three weeks of sustained review since the 31 July hotfix, including AI-assisted review by frontier models and work by named external researchers. There is no new Mk2/Mk3 build and no new Edge build; 4.2.0, 6.6.0X and 6.6.0QX remain the current artefacts on those tracks, all dated 31 July.

Read the status page carefully and the distinction is precise. 5.6.0 and 1.5.0Q remain the minimum fixed releases; 5.6.1 and 1.5.1Q are the current recommended standard releases. Coinkite is not saying seeds generated on 5.6.0 are at risk. It is saying that if you are about to generate the replacement seed your migration depends on, generate it on the most reviewed firmware available. That is sensible and it is the reason to check your version again this weekend even if you already updated in July.

The substantive change is a policy one, and it is the most interesting thing Coinkite has done since the disclosure. Every newly generated seed now requires user-sourced entropy. You must supply one of the following: at least 65 key presses with unpredictable timing, 50 rolls of a physical six-sided die, or 128 physical coin flips. The requirement extends to generated Temporary Seeds and generated CCC Key C. Under the hood, the backup PRNG has been replaced — SHA-256 Hash_DRBG in place of Yasmarang — seeded at boot from the STM32 TRNG and reseeded with a 256-bit digest from both secure elements, and each new seed now mixes 32 bytes from the generator with 32 fresh bytes from SE1 and 8 from SE2 through a double SHA-256 before the mandatory user input is folded in.

In other words: the device will no longer let you take its word for it. The mitigation that protected the users who qualify for the dice exception below is now compulsory for everyone. One small hardening worth knowing if you have ever entered dice on a Q or Mk4 — holding a key down no longer counts as repeated rolls.

The release also carries fixes unrelated to the RNG bug, three of which matter to ordinary users. The device now re-verifies a staged PSBT immediately before signing and refuses with Transaction modified if a connected host altered it after on-device review, which closes a theoretical attack via a compromised USB port. SIGHASH_SINGLE and SIGHASH_SINGLE|ANYONECANPAY are blocked by default because later outputs can remain modifiable. And when a BIP-39 passphrase wallet is active, View Seed Words now shows the effective extended private key rather than the parent seed words — with backups of a passphrase wallet capturing the effective XPRV, not the parent words or the passphrase, which is a behavioural change worth understanding before you rely on a new backup.

Step 2: the two exceptions that can save you

Coinkite documents two circumstances in which an affected-firmware seed is not considered at risk from this bug. Both are narrow and both have to be true of your specific setup, not of your general practices.

Exception one: independent dice rolls

The flaw affects device-generated entropy. It does not remove entropy that you supplied. On affected firmware, Coldcard hashed the device-generated seed together with every roll entered through the Add Dice Rolls flow. So if you supplied enough genuine randomness yourself, the weak device contribution stops mattering.

Every word in “independent, private rolls” is load-bearing. Independent means a fair die, actually rolled, not a pattern you typed. Private means the sequence was never photographed, filmed, written into a phone, or performed where a camera could see it — the roll sequence is secret key material, exactly as sensitive as the seed words themselves. And the exception applies to the final seed words displayed after the dice were added; if you are unsure which set of words you actually funded, you do not qualify.

Exception two: a strong, unique BIP-39 passphrase

A BIP-39 passphrase is an independent barrier. Reduced seed entropy alone does not get an attacker to funds sitting in a passphrase wallet — they would have to discover the passphrase as well. This is genuinely why some affected users still hold their coins.

Three qualifications, all of them from Coinkite’s own text. First, this means a BIP-39 passphrase, not your Coldcard PIN; the PIN protects the device, not the key. Second, a short, common, patterned, quoted or reused passphrase may be guessable, and if that describes yours you should treat the funds as at risk immediately. Third — and this is the part most coverage omits — a strong passphrase reduces immediate exposure but does not repair the seed. Coinkite’s guidance is that passphrase users should still migrate as soon as practical. The passphrase buys you time to do it calmly. It is not a permanent answer.

Step 3: the decision tree

Step 4: migrating, when you have a second device

This is the easy case and you should engineer your way into it if you can. Use a second Coldcard already running fixed firmware to generate the replacement seed, and keep the affected device as the source of funds only.

1. Confirm the fixed firmware version is installed on the device that will generate the new seed.
2. Generate a new seed on that updated device.
3. Record the backup and verify it before depositing anything — read the words back, check the wallet fingerprint (XFP).
4. Verify a new receive address on the Coldcard’s own screen, not on your computer.
5. Send a small test transaction and confirm the new wallet works end to end.
6. Only then move the remaining funds.
7. Keep the old backup until the migration is complete and confirmed on chain.

Step 5: migrating when the Coldcard is your only device

Firmware 4.2.0 lets an Mk2 or Mk3 generate a correct replacement seed, so you do not need to buy new hardware to fix this. What you do need is discipline, because a one-device migration means alternating between two seeds on the same box and every swap is an opportunity to destroy a backup you still need.

1. Verify the written backup and wallet fingerprint of the affected seed first. Do not proceed until you can restore it.
2. Install firmware 4.2.0 or later and confirm the version on the device.
3. On an empty device, generate the new seed. Record and verify its backup, its fingerprint, and one receive address.
4. Restore the affected seed and send a small test transaction to the verified new address.
5. Restore the new seed and confirm the fingerprint matches and the test funds arrived.
6. Restore the affected seed and move the remaining funds.
7. Restore the new seed and confirm the full balance. Keep the old backup until every coin has arrived and confirmed.

Coinkite also documents an optional Dice Rolls Only path, reached through Import Existing > Dice Rolls, which excludes all hardware-generated randomness and hashes your roll sequence directly. On the current firmware it requires 50 rolls for a 12-word seed or 99 rolls for 24 words. This is an advanced procedure and it is not necessary — the normal New Wallet flow is corrected, and on 5.6.1 and 1.5.1Q it now forces you to contribute entropy anyway. Choose it only if you are confident you can perform and verify it, and never photograph, digitise or type the roll sequence into a networked computer; the sequence and any final hash the device displays are secret key material.

Six traps

1. Assuming a higher Edge version number means fixed. Standard and Edge are separate tracks. Match your row exactly.
2. Thinking the firmware update fixed the seed. It fixed new seed generation. Your existing key is unchanged.
3. Confusing the PIN with a BIP-39 passphrase. Only the passphrase provides the independent barrier.
4. Moving funds to a “new wallet” that restores the same seed. New device, same words, same problem. The seed is what is broken.
5. Rushing. Coinkite’s own guidance says it plainly: rushing a wallet migration can create a more immediate risk than the issue you are trying to address. Most self-custody losses are self-inflicted during panicked handling.
6. Generating a new seed before updating. On an un-updated device you would simply generate a second affected seed.

Where the stolen coins are

Most of the stolen bitcoin has not moved. The widely-repeated “90% unmoved” figure is from 4 August and is now stale; on Galaxy Research’s 14 August accounting, 1,531 of 1,778 BTC remained unmoved — about 86% — with roughly 246 BTC having moved, around 65% of it into coinjoins. The first break in dormancy was a transfer of 30.185 BTC (~$1.94 million) on 7 August, which was widely reported at the time as 1.5% of the haul and has since been superseded by the larger figure. Whether this is an attacker waiting out the heat, an operational-security failure in progress, or an inability to move size without being flagged, nobody outside the investigation knows. It is worth understanding what this means for a victim: the coins being traceable is not the same as the coins being recoverable, and no meaningful recovery has occurred. Coinkite says law enforcement authorities continue to investigate and are keeping the company informed. For scale, DefiLlama has logged 219 hacks worth $1.26 billion across crypto so far in 2026 — and two more chains had incidents this week alone, with MANTRA halting its blockchain after an exploit and BounceBit announcing it will sunset its chain entirely following a $3 million loss.

The wider lesson, stated carefully

The reflex reaction to this incident — loudest from firms that sell custody — has been that self-custody is too hard for ordinary holders. That reads the failure backwards. What failed here was not the principle of holding your own keys. It was a single closed-source entropy path in a single vendor’s firmware, undetected for five years because almost nobody independently verifies the randomness of a seed their device hands them.

The generalisable rule is narrower and more useful: do not let one device be the sole source of the randomness that secures your savings. Supplying your own dice entropy is exactly the mitigation that protected the users who qualify for the exception above, and it cost them ten minutes at setup. A strong, well-backed-up BIP-39 passphrase is the second independent layer, and it is why some affected users still have their coins. Both were available to every owner before 30 July, documented in the manual, and skipped by most people because the device said it had it covered. Coinkite’s own recommendation, published 20 August, is now exactly that stack for any wallet holding a meaningful balance: the standard Dice Rolls option executed honestly with genuine rolls, a strong and unique BIP-39 passphrase, and where appropriate a multisig arrangement suited to your threat model. It took a $116 million loss to make that guidance mandatory rather than optional.

If you own a Coldcard and you have not checked which firmware built your seed, that is this weekend’s task. It takes about ten minutes and there is no deadline at which the risk expires.

This is field guide #28 in our “how to read the primary source yourself” series. The companion pieces are our explainer on hardware-wallet entropy and how seeds are generated, and our running coverage of the four theft waves. All of them, and the other twenty-five, are indexed in the Bitcoin Investor’s Reading Room.