Coldcard Key Exposure: What Happened and What to Verify

Coldcard key exposure" has been the phrase moving through Bitcoin circles this week, attached to a number that keeps climbing: north of 1,800 BTC pulled from hardware wallets that were never connected to the internet. That detail is what makes this different from a typical exchange hack. Coldcard is an air-gapped signing device — the whole product exists so your keys never touch a networked computer. The keys got taken anyway, because the flaw was never in the network path. It was in how the seed was generated in the first place.

A claim like "hardware wallet flaw linked to $70 million stolen in 41 minutes" is an extraordinary one, and it deserves the scrutiny extraordinary claims get: a paper trail separating a device design flaw from a stolen backup, a compromised signing computer, malicious firmware, phishing, or an operator who simply exposed a seed. That scrutiny happened. Coinkite investigated its own product, confirmed a real firmware defect, published the affected version ranges, and shipped a patch. This piece works from that confirmed record, not from the headline.

What Caused the Coldcard Key Exposure

Block's engineering team, which coordinated disclosure with Coinkite before publishing, traced the root cause to a single preprocessor check: firmware library libngu "incorrectly checks whether [a] macro is defined rather than whether it is enabled." That macro, MICROPY_HW_ENABLE_RNG, controls whether seed generation pulls from the STM32 chip's hardware random number generator. Because the check asked is this defined instead of is this on, a production build shipped since March 2021 silently fell back to MicroPython's deterministic "Yasmarang" generator — seeded only from the device's unique ID and timer state, with no fresh entropy collected afterward.

The practical result, per Block's analysis, is a search space an attacker can brute-force offline: as low as 2^0 if every device parameter is known, up to roughly 2^40.7 for early Mk2/Mk3 firmware, and up to 2^41.3 for later models without the secure-element reseed — nowhere close to the 128 bits a seed is supposed to carry. An attacker never needs your device, only a public address to check candidate seeds against, which public blockchain data provides for free. That's also the correct read on the "41 minutes" figure: it describes the window between the first and last on-chain movement, not how long the underlying compromise took to prepare. The seed may have been recoverable for years before anyone moved on it.

Coinkite's own advisory adds a detail worth knowing if you used "Add Dice Rolls": the device hashed your dice entropy together with its own weak device-generated contribution. That's normal design — dice rolls are meant to strengthen a seed — but it means the safety of a dice-augmented seed depends on how much real entropy you actually put in.

How Much Bitcoin Was Actually Stolen

Two respected research firms are reporting two different numbers, and neither is final. TRM Labs puts confirmed losses at 1,816 BTC ($116M) across 5,200+ addresses, flagged as preliminary since funds are still moving. Galaxy Research separately confirmed 1,596 BTC across three waves, warning a suspected fourth could push the real total past 2,055 BTC ($130M), from at least 15 separate attackers working the same weak seed space independently.

The confirmed bug doesn't mean every reported loss this week traces to it. An individual claim still needs its own evidence: the affected transaction IDs, the exact device model and firmware version the seed was generated under, whether a BIP39 passphrase was in use, and the wallet policy (single-sig or multisig). A user who typed a seed into a laptop, reused a passphrase, or approved a transaction they didn't independently verify has a different incident than this one, even if it looks identical from the outside — the chain shows a valid signature authorized the spend, not who actually provided it.

Is Your Coldcard Affected?

Per Coinkite's advisory, exposure depends on the firmware version your seed was generated under — not your current firmware, not your purchase date:

• Mk2 / Mk3: seeds generated on firmware 4.0.1–4.1.9. Patched in 4.2.0.
• Mk4 / Mk5 (standard): before 5.6.0. Patched in 5.6.0.
• Mk4 / Mk5 (Edge): before 6.6.0X. Patched in 6.6.0X.
• Q (standard): before 1.5.0Q. Patched in 1.5.0Q.
• Q (Edge): before 6.6.0QX. Patched in 6.6.0QX.

Updating firmware today does not repair a seed already generated under an affected version — it's exactly as weak after the update as before it. The one documented exception: Coinkite states a seed built from "at least 50 fair and independent" dice rolls, never recorded or exposed, is not at risk "from this RNG issue alone." That qualifier is doing real work — it covers this bug, not every risk to that seed.

What Coinkite Wants You to Do

Generate a new seed on patched firmware, send a small test transaction to confirm the new wallet works, then move the rest. Do it today — waiting for a final loss number doesn't reduce your exposure, and every day an old seed stays active is another day it can still be checked.

Build a Signing Workflow That Assumes the Host Is Hostile

A hardware wallet is an independent verifier, not a magic object. The connected computer building your transaction can be compromised; the device's job is to keep the seed isolated and show you the real transaction details before you approve anything. If you sign on a PSBT-based workflow, compare what the device displays against what actually broadcasts — amount, fee, destination, and change output — since a swapped destination is caught here or not at all. Keep a seed and any BIP39 passphrase as two separate secrets, stored apart; together, they're one component pretending to be two. For larger balances, a 2-of-3 multisig policy means one exposed seed isn't enough to spend, at the cost of real operational complexity — every cosigner, backup, descriptor, and recovery path has to actually be tested, not just written down.

If You Suspect Compromise, Preserve Evidence First

Don't wipe the device, overwrite the coordinator, or post recovery details before you've recorded the affected transaction IDs, wallet policy, firmware version, and timestamps, and kept the connected computer's current state intact if malware is plausible. Then move remaining funds using a clean signing environment to a freshly generated seed — never to another address derived from the same compromised one, and never to another PSBT signed on the same host you don't yet trust.

What Miners Should Verify Too

A solved block is only as safe as the address it pays, and that address is only as safe as the seed behind it. Confirm which firmware version actually generated your current seed, not which version you're running now. If you can't prove your seed predates the affected window, treat it as compromised. And don't route every future block reward to one address that's also done casual duty elsewhere — a dedicated payout policy with a tested recovery path holds up better than a general-purpose wallet that happens to also collect mining rewards.

Where NexusPool Fits

NexusPool never touches your keys — it's non-custodial by design, and a solved block pays your address directly, at 0% fee, with nothing routed through a balance you'd have to trust. That design removes one kind of trust and leaves the other entirely in your hands: the pool was never in a position to protect the key on the other end. Payout Preflight lets you verify exactly where a reward would land before you ever win one — it can't tell you whether the seed securing that address is sound. Only you, and Coinkite's advisory, can do that.

We wrote about a different "verify the mechanism, not the headline" story last week, when BIP-110's chain split had headlines racing ahead of the actual math. This one runs the other way: the headline undersold it, the root cause is confirmed, and the correct response is to act today, on your own hardware, against the vendor's own advisory — not a summary of it, including this one.

Trust nothing. Verify your own seed's birthdate against Coinkite's list, not against a headline.

---

Sources: Coinkite official advisory · Block Engineering, independent technical report · TRM Labs · Galaxy Research, via BitcoinWorld · The Hacker News.