Weak Seed Generation: The Coldcard Entropy Bug and the Migration Drill Every Self-Custodian Needs

Two promises, and only one of them gets talked about

The pitch for a hardware wallet is about secrecy. The private key is generated on a dedicated device, it is stored in hardware designed to resist extraction, it signs transactions internally, and it never appears on an internet-connected computer. All of that is real, and it defeats the entire category of attacks that steal keys from ordinary machines. It is also only half the security model, and the half that gets discussed.

The other half is that the key has to be unpredictable. A wallet key is not chosen from a list; it is drawn from a space so vast that guessing is hopeless. The BIP-39 standard that produces recovery phrases specifies initial entropy of between 128 and 256 bits, and 128 bits is the number that makes brute force meaningless — not difficult, but arithmetically pointless. That guarantee depends entirely on where the randomness came from. If the source is weaker than advertised, the resulting phrase looks completely normal: still twelve or twenty-four ordinary words, still passing every checksum, still restoring correctly on any wallet. Nothing about the device, the screen, or the words written on your backup card reveals the difference. Secrecy is something you can reason about — who saw it, where is it stored. Unpredictability is invisible, unverifiable after the fact, and taken entirely on trust.

What actually happened, in plain terms

In July 2026, Coinkite disclosed that seed generation on its Coldcard devices had been drawing randomness from the wrong source. The company's technical backgrounder explains the cause with unusual candour. During a 2021 migration to Bitcoin Core's libsecp256k1 library, seed generation moved from one function to another, and a guard intended to prevent the software fallback path from being used checked only whether a macro named MICROPY_HW_ENABLE_RNG was defined rather than what its value was. As the write-up puts it, the macro was defined as zero, so the error did not stop the build. The two candidate functions shared a name, the wrong one was silently selected, and instead of the device's hardware random number generator, seed creation used MicroPython's general-purpose Yasmarang software generator, seeded from values including the chip's serial number and timer registers.

The effect was a collapse in the search space an attacker faces. Against an intended 128 bits, Coinkite estimates roughly 40 bits of effective entropy on the Mk2 and Mk3 models, and roughly 72 bits on the Mk4, Mk5 and Q, which mix in additional entropy from their secure elements. Forty bits is within reach of ordinary computing. The advisory lists the affected ranges: firmware 4.0.1 through 4.1.9 on Mk2 and Mk3, seeds generated on Mk4 and Mk5 before version 5.6.0 standard or 6.6.0X Edge, and on Q before 1.5.0Q standard or 6.6.0QX Edge. The flaw shipped in March 2021 and was patched on 31 July 2026 — after an attacker had begun brute-forcing keys and draining the resulting wallets, in waves starting 30 July, with reported losses passing $130 million and TechCrunch noting that at least a dozen different attackers appeared to be involved. One victim quoted in that reporting captured what makes the case instructive rather than merely alarming: he had never shared his seed phrase with anybody, and his devices had never touched the internet.

Why a firmware update cannot repair an existing seed

This is the single most important sentence in the whole episode, and it is the one people skim: updating the firmware does not change or repair an existing seed. Coinkite states it directly in the advisory, and it follows from what entropy is. Randomness is consumed at the instant a key is created and never revisited. The words on your backup card are a fixed encoding of the number that was drawn on that day, from whichever source was wired up at that moment. Patching the source changes what future draws look like. It has no reach into a draw that already happened, any more than fixing a broken dice tower changes a roll from last year.

That makes the required action unavoidable and slightly counter-intuitive. The update is necessary, because you must not generate a replacement key on vulnerable firmware — the advisory is explicit that users should not generate a new seed on affected models until the update is installed. But the update is not the remedy; it is the precondition for the remedy. The remedy is generating an entirely new seed and moving the funds to it. Anyone who installs the patch, sees the reassuring version number, and leaves their coins where they are has performed the preparation and skipped the fix. It is worth generalising the lesson beyond one vendor: when a security advisory concerns how a secret was created rather than how it is stored, no software update will ever resolve it, and the presence of a patch should read as a starting gun rather than an all-clear.

Entropy you can count: why dice survived this

There is one group of users this did not reach, and the reason is worth understanding because it generalises to every vendor. Coldcard and several other devices allow you to supply your own entropy by rolling physical dice and entering the results, which is mixed into the seed. Coinkite's advisory states that the issue affects device-generated entropy and does not remove independent entropy supplied with dice, and that with at least 50 fair, independent rolls that were never recorded or exposed, it does not consider the resulting seed at risk from this issue alone — because at that threshold the dice input alone contributed at least 128 bits.

The structural point is not that dice are magic. It is that they are the only part of the process you can personally verify. You cannot audit a firmware build, confirm which symbol a linker resolved, or test whether a number you were handed was drawn from a hardware source or a software one — and this incident demonstrates that a vendor with a strong security reputation and open firmware could not detect it either, for over five years. Fifty die rolls, in contrast, is something you can count while you do it. Each fair roll of a six-sided die contributes about 2.58 bits, so fifty rolls comfortably exceeds the 128-bit target on their own, which means the seed remains strong even if every other entropy source in the device were worthless. The conditions matter and are easy to get wrong: the dice must be fair, each roll independent, and the sequence must never be photographed, written down or typed anywhere else — an exposed roll sequence hands over the very thing that was protecting you. A strong BIP-39 passphrase is a related but separate control, described by Coinkite as an independent barrier and, importantly, as a distinct wallet-security choice rather than a substitute for good entropy; a weak passphrase adds very little.

The migration drill, step by step

Every self-custodian should be able to run this without improvising, because the situations that demand it — a vendor advisory, a suspected exposure, a phrase that was once photographed — arrive without notice and reward calm. Work in this order. First, update the device to fixed firmware, and confirm the version on the device rather than assuming the update applied. Second, generate a completely new seed on that updated device, adding your own dice entropy if it supports it. Third, write the new phrase down offline and verify the backup before it protects anything, by wiping the device and restoring from your written copy, then confirming the receive addresses match — an unverified backup is a guess, and this is the step people skip. Fourth, send a small test amount to the new wallet and confirm it arrives and can be spent onward. Fifth, move the remaining balance. Sixth, and only then, retire the old seed: destroy the old backup once you are certain nothing remains on it, and never restore it onto a device again.

Two hazards deserve naming because they turn a recoverable situation into a loss. The first is haste. A publicised drain creates pressure to move funds immediately, and rushing produces the classic self-inflicted errors — a mistyped address, an unverified backup, a phrase typed into a phone to save time. The test transaction exists precisely to absorb that pressure, and the few minutes it costs are the cheapest insurance in this whole procedure. The second is the follow-up scam. Every publicised incident is immediately followed by helpful strangers: migration assistants, urgent messages from support you never contacted, tools that will check whether your seed is affected. Any of these that asks for your recovery phrase is a theft, without exception — Ledger's own guidance on recovery phrases makes the general rule plain, and the direction-of-contact test in our guide to fake support desks disposes of the whole category, since real support answers channels you opened rather than opening them. Finally, keep a plain note of when each seed was generated, on which device and firmware version, and whether you supplied dice. It takes a minute, and it is what turns the next advisory from an anxious afternoon of guessing into a thirty-second check of whether it applies to you at all.

Authority sources used

Outbound links are included for verification and entity authority, not decoration.

• COLDCARD Security Advisory: seed generation warningCoinkite
• Technical Deep Dive into the Entropy IssueCoinkite
• Hackers steal over $130M by exploiting bug in offline hardware walletsTechCrunch
• BIP-39: Mnemonic code for generating deterministic keysBitcoin Improvement Proposals
• What is a Secret Recovery Phrase and how to keep it safeLedger Academy

FAQ