The Coldcard Mk3 Entropy Flaw: How a Skipped Hardware RNG Exposed BIP39 Seeds

This entry documents what is currently known about the Coldcard seed-generation entropy flaw disclosed on 30 July 2026. It sits in our reference catalogue alongside Randstorm, MilkSad, the Trust Wallet LCG bug and the 2014 Ethereum presale key-generation flaws — all members of the same family: a cryptocurrency wallet whose private keys were derived from a random-number generator that was not actually random. This is an evolving disclosure; figures and attribution below are current to 31 July 2026 and will be updated as Coinkite’s formal technical review and further on-chain analysis land.

What is entropy, and why does a weak RNG break a wallet?

A BIP-39 seed phrase is a human-readable encoding of a random number. A 12-word phrase encodes 128 bits of entropy; a 24-word phrase encodes 256. The security of every key derived from that seed rests entirely on that number being genuinely unpredictable. 128 bits of real entropy is unsearchable — there is not enough energy in the observable universe to enumerate 2¹²⁸ possibilities.

But if the generator that produced that number can only ever emit, say, 2⁴⁰ distinct outputs, then the seed — no matter how it looks written on the card — is one of about a trillion possibilities. An attacker who understands the generator can produce every candidate offline, derive each candidate’s public addresses, and check them against the blockchain. When a match is found, the funds are theirs. The wallet’s cryptography was never broken; the randomness feeding it was. This is the exact mechanism behind Randstorm, MilkSad and the Trust Wallet LCG bug, and it is the mechanism here.

The July 2026 sweep: what happened on-chain

Between roughly 01:31 and 01:56 UTC on 30 July 2026 — a window of about 25 minutes spanning Bitcoin blocks 960188 to 960191 — approximately 594.48 BTC (about $38 million at the time) was swept out of around 500 single-signature addresses. AnchorWatch co-founder Rob Hamilton, who published an early on-chain breakdown, counted 1,324 spent outputs moved across roughly 500 transactions inside that three-block window, with about 562 BTC then consolidated into a single address that has not moved since. Hamilton’s first-pass read was that the pattern pointed to flawed entropy in wallet generation somewhere along the path.

Three details make the event look automated rather than manual, and consistent with an entropy attack. First, the extreme compression — hundreds of independent single-sig wallets drained in one tight window — is what a script firing against a pre-computed list of vulnerable keys looks like. Second, the drained wallets clustered in a narrow balance band, reportedly roughly 0.15 to 0.26 BTC each: the operator set a value floor and worked by expected payoff, which is rational when each candidate key costs compute to test. The affected coins spanned 2021 to 2026 — almost exactly the lifetime of the flaw. Third, researchers including Wizardsardine’s Kevin Loaec noted the sweep concentrated on BIP-84 native SegWit derivation paths, and Jameson Lopp reported that some wallets were only partially drained — consistent with a tool enumerating a limited derivation-path space rather than exhaustively emptying every address. The practical corollary, which Loaec flagged, is that a partially-drained wallet is not a safe wallet: the remaining balance can be taken in a later pass.

The number may not be final. Block security engineer Clay Garrett reported 695 earlier transactions carrying the same on-chain fingerprint as the confirmed set, accounting for a further 488.11 BTC. If those are part of the same operation, the total would rise to about 1,082.59 BTC (on the order of $70 million). That linkage is not confirmed, and neither Coinkite nor any researcher has established definitive public proof that the sweep exploited the Coldcard flaw specifically rather than another weak-entropy source. The timing and the technical fit are strong; the causal chain is not yet proven.

How the disclosure unfolded

The response happened in public and fast, over a single day, which is worth recording because it shaped the early reporting:

• 01:31–01:56 UTC, 30 July: the sweep executes across blocks 960188–960191; 562 BTC is consolidated to one address.
• Midday, 30 July: the first affected users report drained wallets publicly.
• ~17:35 UTC: Wizardsardine’s Kevin Loaec asks Coldcard holders to check their balances, following up that it was not a false alarm.
• ~18:10 UTC: Coinkite CEO Rodolfo Novak (NVK) responds publicly, initially attributing the reports to an individual compromised or leaked seed rather than a device-wide flaw — the assessment the company would revise within hours.
• Later, 30 July: Coinkite publishes its Mk3 Security Advisory, scoping the risk to Mk3 firmware 4.0.1–5.0.3 and stating Mk4/Q/Mk5 appeared unaffected on early analysis.
• 30–31 July: Block’s Bitcoin Engineering and Security team independently root-causes the bug, discloses privately to Coinkite, then publishes. Coinkite follows with a technical backgrounder that expands the scope to Mk4/Q/Mk5 (~72-bit) and ships emergency hotfix firmware — 5.6.0 for Mk4/Mk5 and 1.5.0Q for Q.

The takeaway for anyone reading older coverage: the initial “Mk3-only, newer models safe” framing — which several outlets captured — was superseded the same day. Treat any account that still says Mk4/Q/Mk5 are unaffected as out of date.

Root cause: the wrong random-number generator came along for the ride

The technical mechanism is now documented in Coinkite’s own backgrounder and in an independent report from Block’s Bitcoin Engineering and Security team. It is a chain of small, individually plausible mistakes that combined into a serious one.

Coldcard’s firmware is built on MicroPython, which ships two random-number implementations behind a single function name: the STM32 chip’s true hardware RNG, and a deterministic software fallback (a Yasmarang-family PRNG) for boards that lack hardware support. Which one compiles in is chosen by a build macro, MICROPY_HW_ENABLE_RNG. Because Coldcard provides its own separate hardware-RNG wrapper, the maker set that macro to zero, intending to use neither MicroPython path. Setting it to zero, however, does not disable MicroPython’s generator — it selects the software fallback.

That alone should have been caught, and there was a guard meant to catch it. But the guard in the supporting library (libngu) was written with #ifndef — it checked only whether the macro was defined, not whether it was enabled. A macro defined as 0 is still defined, so the guard passed, the build succeeded with no error, and the wallet-generation path silently bound to MicroPython’s software fallback. The carefully written hardware-RNG code the maker intended to use was still present in the binary — it was simply, by accident, only being used for less important things. Prior security review had confirmed the correct code existed in the firmware; it had not verified which implementation the seed-generation path actually reached across the two submodules.

What was the fallback seeded from? On first use it initialised from the MCU’s unique ID (fixed factory metadata, partly exposed as the device’s USB serial number) XOR’d with the SysTick counter, plus two real-time-clock registers. None of these is a cryptographic secret. The UID is fixed and readable; the timer values are constrained, correlated, and on some cold boots effectively static. After that single initialisation, no fresh entropy was collected — every subsequent output was a deterministic step from that state. So for a known device and call history, the entire seed was reproducible.

Both Coinkite and Block describe their analyses as preliminary. Block published its report before completing full empirical testing of exploitability, stating plainly that it did so because active exploitation was already under way, and it defers to Coinkite’s forthcoming definitive technical review. Block also noted that none of its own products or customers — including its Bitkey wallet — are affected, since they do not share this codebase. Independent corroboration arrived quickly: Bitcoin Core contributor instagibbs reproduced the Mk2/Mk3 path on a fresh device, and multiple researchers converged on the same weak-entropy conclusion.

Why the numbers differ: 40 bits vs 72 bits

The severity depends on the device generation, because Coldcard’s later hardware mixed in a little extra material:

• Mk2 / Mk3 (firmware 4.x through 5.0.3): no cryptographic entropy reached the generator at all. For a known UID, timer state and call history the output is fully deterministic. Coinkite’s preliminary estimate of the effective search space is about 40 bits; Block’s loose upper bound with hidden timers is under 2⁴¹. Either way, this is inside brute-force range.
• Mk4 / Q / Mk5: these devices added secure-element entropy from SE1 and SE2 at boot — but the reseed kept only four bytes of the hashed result and overwrote just a single 32-bit word of the generator’s state. That caps the securely-distinguished search space at 2³² (about 2³¹ on average), roughly 72 bits under the maker’s framing. Meaningfully harder than the Mk3, still far below the 128-bit standard, and a target that a well-resourced adversary cannot be assumed unable to reach. Hashing the output with SHA-256d and adding the BIP-39 checksum does not help: deterministic post-processing cannot manufacture entropy that was never in the input.

Upgrading the firmware does not repair a seed that a vulnerable version already generated. Exposure tracks the firmware that was running when the seed was created, not the device’s manufacture or purchase date, and not its current firmware. The only fix for an affected seed is to generate a new one correctly and move the funds.

This is what makes the incident harder than a normal patch. Coinkite shipped the Mk3’s final firmware (5.0.3) in June 2023, so this advisory lands roughly three years after the model left active support — and it concerns seeds created as far back as 2021. A dormant holder may power the device on once every few years and miss the notice entirely. The lesson generalises beyond Coldcard: seed provenance — which firmware, on which device, generated a given seed — is now a first-class security property that outlives the hardware, and auditing it is a standing maintenance obligation rather than a one-time setup step.

Affected and unaffected, at a glance

Affected (seed generated on this firmware, without a passphrase or dice):

• Mk2 and Mk3 on firmware 4.0.0 (17 March 2021) through 5.0.3, the final Mk3 release. Coinkite phrases its user warning as “4.0.1 or any later version.” The regression commit is dated 1 March 2021 and first shipped in v4.0.0.
• Mk4, Q and Mk5 on their production firmware prior to the emergency hotfix — reduced (~72-bit) rather than catastrophic, but still below standard.

Considered safe from this specific flaw:

• Any seed protected by a genuine BIP-39 passphrase (the extra secret layered on the seed — not the device PIN). Coinkite rates these minimal-risk, because the passphrase supplies secret material the attacker does not have.
• Any seed originally created with at least 50 fair, independent, private dice rolls, which inject entropy outside the device generator. The arithmetic is why the number works: a fair six-sided die yields about 2.585 bits per roll (log₂6), so 50 rolls contribute roughly 129 bits and 99 rolls roughly 256 — genuine entropy the device RNG never touched. The rolls have to be real and independent; reusing a memorable sequence defeats the purpose.
• Mk1; and Mk2/Mk3 on firmware through v3.2.2, which used the hardware RNG directly.
• TAPSIGNER, OPENDIME and SATSCARD — different codebases, not affected.
• Multisig quorums where a sufficient number of keys came from unaffected devices. Note the corollary: a multisig built entirely from vulnerable Coldcards inherits the weakness — a secure quorum has to include enough independently-generated keys.

The blast radius is wider than seed phrases

Because the same faulty generator fed everything that needed randomness, the exposure is not limited to BIP-39 seeds. Per Block’s analysis, the same stream produced Coldcard paper-wallet private keys (where the output is the key, with no BIP-32 derivation to hide behind — the public address is a direct validation oracle), random seed-XOR split masks, some device-cloning and USB-encryption ECDH keys, Key Teleport transfer keys and secondary passwords, Web2FA material, and generated Secure Notes passwords. Any secret a vulnerable Coldcard generated from its RNG, rather than one you supplied, should be treated as potentially exposed. Manually-entered and BIP85-derived passwords are not directly affected, provided the underlying wallet seed itself was generated safely.

How to tell if you are affected, and what to do

Work through this calmly. A rushed migration is itself a way to lose coins.

1. Establish how the at-risk seed was generated. If it was created on a Mk3 (or any Coldcard on 4.0.0+) with no passphrase and no dice rolls, treat it as at risk. If you used a strong BIP-39 passphrase, or added 50+ real dice rolls at creation, this flaw alone does not put that seed at risk — but confirm you understand the difference between a passphrase and the PIN.
2. If the Mk3 is your only device, use a passphrase as an interim measure. On the device, apply a long, unique, random BIP-39 passphrase, record it separately from the seed words, and move funds to the resulting wallet. Verify the wallet fingerprint (XFP) after a power-cycle before depositing — every passphrase, including a typo, produces a different valid wallet.
3. Preferred fix: generate a brand-new seed on an unaffected/updated device and migrate. Coinkite has shipped an emergency hotfix — firmware 5.6.0+ for Mk4/Mk5 and 1.5.0Q+ for Q — that generates entropy correctly. Generate a fresh seed there (a passphrase and/or 99 dice rolls on top is prudent), verify the backup and a receive address on-screen, send a small test transaction, confirm it arrives, and only then move the balance. Keep the old backup until the migration is fully confirmed.
4. Advanced, single-device option: a dice-only seed. On an empty Mk3 running 4.1.9, use Import Existing → Dice Rolls and enter at least 99 rolls of a fair six-sided die. That dedicated path hashes the roll sequence directly and bypasses the device generator entirely — do not use the normal “New Wallet” flow for this, as it would use the RNG. The roll sequence is secret key material: never photograph it or enter it into a networked device.

Restoring the seed onto a different device does not help. The weakness lives in the seed itself, not in the device currently holding it, so importing an affected seed into another Coldcard — or a different brand entirely — changes nothing. Trezor publicly made this exact point to its own users when reassuring them their funds were safe: a weak seed stays weak wherever it is loaded. The only remedy is a new seed generated with proper entropy.

If your funds are in a multisig

Multisig changes the calculus but does not automatically save you. Block’s report is explicit: a Coldcard used in a multisig arrangement composed exclusively of vulnerable devices remains fully exposed, and a quorum of secure devices is required to protect against the issue. Translate that to your own setup by counting how many independently-secure keys you truly have:

• A 2-of-3 where two keys were generated on affected Coldcards is effectively broken — an attacker who can derive both weak keys reaches the threshold without you.
• A 2-of-3 with only one affected key still meets its threshold from safe keys, so funds are not immediately derivable — but you have lost a factor of redundancy and should rotate the weak key rather than rely on the margin.
• Any quorum you cannot audit — where you are unsure which firmware generated which cosigner — should be treated as suspect until you establish provenance for each key.

The fix for an affected multisig is coordinated key rotation, not a rushed sweep: generate replacement key(s) on safe, hotfixed hardware, build a new wallet descriptor that swaps out every vulnerable cosigner, verify the new descriptor and a receive address on each signing device, send a test transaction, then migrate the balance to the new multisig. Multisig coordinators such as Nunchuk and Unchained are the tooling most users will run this rotation through; follow your coordinator’s current published guidance for the mechanics, and keep the old wallet’s records until the new quorum is confirmed.

One hard truth: if a wallet has already been swept, the coins are gone. On-chain transactions do not reverse, and any service promising to “recover” stolen Bitcoin for a fee is a second scam aimed at people already harmed by the first. The value of acting now is protecting what has not yet been taken — partially-drained wallets, and wallets the attacker has not reached yet.

A note on how this was found: AI cuts both ways

Coinkite has said it was unaware of the bug until the day of the sweep, and that it had recently run one of the best available AI models over its own firmware for security review — which did not surface this issue. Its working assumption is that someone else used AI to study the long-public, open-source firmware and found the flaw first. Whether or not that is precisely how it happened, the shape of the incident is a preview of a real dynamic: defenders and attackers now hold the same automated code-analysis tools, and a subtle, years-old cross-submodule symbol-resolution bug is exactly the kind of needle those tools are good at finding in a large haystack. That is a strong argument for treating any long-lived, entropy-critical code path as a standing audit target rather than a solved problem — the assumption behind our own vulnerability research.

Where KeychainX fits

We are a wallet-recovery firm, and we want to be precise about what that does and does not mean for an incident like this, because the honest answer matters more than a reassuring one.

We cannot reverse a completed theft. Nobody can. What our forensic work can do is help you answer the questions that determine your actual exposure: whether a given seed or wallet was in fact generated on affected firmware; whether address-derivation and transaction patterns are consistent with the flaw; and, if you are locked out of your own not-yet-drained wallet, recovering access so you can migrate before an attacker gets there. Determining which BIP-84 (native SegWit) and other derivation paths are exposed, and reconstructing how a seed was produced, is the same forensic work we apply to Randstorm, MilkSad and presale-era wallets. If you hold funds on an affected Coldcard, the most important step is the free one: move them, following the steps above.

Frequently asked questions

Is my Coldcard hardware defective?
No. This is a firmware issue, not a physical hardware fault. The device’s real hardware RNG works; a build-configuration and library-guard mistake meant the seed-generation path did not use it. The relevant question is which firmware was running when your seed was created.

I have a BIP-39 passphrase on my seed. Am I safe?
Coinkite rates passphrase-protected seeds as minimal-risk from this flaw, because the passphrase adds secret material the attacker does not have. Make sure you mean a true BIP-39 passphrase, not the device PIN, and keep protecting it — never enter it on a website or untrusted device.

Does updating my firmware fix an existing seed?
No. Updating fixes future seed generation only. A seed created by vulnerable firmware stays affected. You must generate a new seed and move the funds to it.

Only my Mk3 was named at first — are Mk4, Q and Mk5 really involved?
Coinkite’s initial advisory called them “not affected based on early analysis,” but the maker’s own follow-up and Block’s independent report show they share the underlying fallback and reach only about 72-bit effective entropy — better than the Mk3 but still below the 128-bit standard. Coinkite has issued a hotfix for them; generate any new seed only after updating.

How much was taken?
About 594.48 BTC is confirmed in the 30 July sweep. Block researchers flagged an additional 488.11 BTC in earlier transactions with a matching fingerprint, which would bring the total near 1,082.59 BTC if linked — not yet confirmed.

Has it been proven that the sweep exploited this Coldcard flaw?
Not definitively, as of 31 July 2026. The timing and technical fit are strong, and multiple independent researchers reached the weak-entropy conclusion, but no public proof establishes the exact source. Treat the flaw as real and act on it regardless of the attribution question.

Can KeychainX get my stolen Bitcoin back?
No — on-chain theft is irreversible, and anyone claiming otherwise for a fee should be avoided. We can help assess whether a seed is affected and help you recover access to and migrate a wallet that has not yet been drained.

KEYCHAINX AG, Baar, Canton of Zug, Switzerland — over 1,000 wallets recovered since 2017. This page is original security research published for reference; it is not affiliated with or endorsed by Coinkite. Primary sources: the Coinkite Mk3 advisory and technical backgrounder, and the Block Bitcoin Engineering report. Contact us for a free assessment or a video call; we reply within 24 hours.