ColdCard Entropy Incident — the $38M RNG failure & how to remediate
In the early hours of July 30, 2026, ~594 BTC (~$38M) was swept from 500 single-signature wallets in about 25 minutes. Their keys were never leaked, their devices were never touched. The seeds themselves were born weak — a hardware-wallet random-number bug that shipped for over four years. This page explains exactly what happened, why it happened, and what every ColdCard owner needs to do.
If you generated a seed on any ColdCard after March 2021 and you did not add at least 50 independent, private dice rolls or protect it with a strong, unique BIP-39 passphrase, treat the wallet as compromised right now. Updating firmware does not repair existing seeds — you must migrate funds to a new seed. Fixed firmware is out (Mk3 → 4.2.0, Mk4/Mk5 → 5.6.0, Q → 1.5.0Q, Edge → 6.6.0X / 6.6.0QX). Migrate calmly, methodically — never in a panic.
01What happened — the 25-minute sweep
Between roughly 01:31 and 01:56 UTC on Thursday, July 30, 2026, an automated operation drained 500 separate single-signature Bitcoin addresses — 1,324 unspent outputs, approximately 594.48 BTC (~$38M) — across four consecutive blocks (960188 → 960191). The attacker then consolidated 562 BTC into a single address, where it still sat untouched as of this writing.
594.48
BTC swept (≈ $38M)
500
Wallets drained
1,324
UTXOs taken
~25 min
Total sweep window
0.044 BTC
≈ $2,800 in total fees
0
Multisig wallets touched
The fingerprint of the attack is the story:
Every drained address was single-signature. Not one multisig wallet, not one Taproot address was touched.
Every target was filtered by balance. The median victim lost 0.41 BTC (~$26,500); the hardest-hit lost 29.9 BTC (~$2M); nobody lost less than 0.15 BTC. This was a curated hit list, not a spray-and-pray.
The funds were old and dormant — many addresses had been untouched since 2021, precisely when the vulnerable firmware began shipping. One victim bought a Coldcard in 2021, generated a 24-word seed on-device, and never let it near a computer. His address was swept anyway.
No keys were "leaked" in the usual sense. No phishing, no malware, no $5 wrench. The attacker recomputed the victims' seeds from public information.
Within hours, the community triangulated the cause: faulty entropy in wallet seed generation. Bitcoin Core developer instagibbs reproduced the vulnerability on a fresh Mk3 device and confirmed: "Mk2/3 vuln, I don't think mk4 is but can't be certain." By the end of July 30, Coinkite — the maker of ColdCard — had published a formal security advisory admitting the flaw was in its own firmware, in its own random-number handling. Total damage across the first 24 hours: ~1,000 BTC / $70M+ per industry reporting, as additional weak seeds were discovered and drained.
02Timeline of a four-year-old bug meeting reality
MAY 2018
The upstream MicroPython fallback PRNG (a non-cryptographic generator called Yasmarang) is added to the codebase Coinkite would later embed. This is the origin of the misleading "eight-year-old bug" figure — the code is that old; it only affected ColdCard seed generation from 2021.
MAR 1, 2021
The fatal regression commit lands: Coinkite migrates elliptic-curve operations to Bitcoin Core's libsecp256k1 via the embedded libNgU library. Wallet seed generation silently moves from Coinkite's hardware-TRNG path to a software fallback.
MAR 17, 2021
Ships to users in firmware v4.0.0 (advisory scope starts at 4.0.1, March 2021). Every Coldcard seed generated from this point is far weaker than it looks.
MAR 2022
Mk4 development mixes 32 bits of secure-element entropy into the PRNG state — a partial mitigation that never fixes the root cause. Mk4/Q/Mk5 seeds get ~72 bits of effective entropy instead of the Mk3's ~40.
JUL 30, 2026 · 01:31–01:56 UTC
💥 THE SWEEP.
500 addresses, 1,324 UTXOs, ~594.5 BTC (~$38M) drained in ~25 minutes; 562 BTC consolidated to one address. No multisig, no Taproot, all old single-sig wallets.
JUL 30 · 13:19 UTC
A victim posts on Reddit: "Full panic, one of my wallets was drained." A heartbreakingly ordinary story: 2021 Coldcard, 24-word seed, never touched a computer.
JUL 30 · 17:35 UTC
Kevin Loaec (Wizardsardine / Liana) asks Coldcard users to check balances: "Hoping this is a nothing-burger but doing my job here." Ninety minutes later: "This is not a drill."
JUL 30 · 18:10 UTC
Coinkite CEO NVK initially responds: "No need to panic. Someone loaded a compromised seed onto a Coldcard…" — the classic leaked-seed pattern. He retracts it hours later: "We are all hands on deck doing a deep dive on everything, technical post soon."
JUL 30 · end of day
Coinkite publishes the Mk3 Security Advisory and the Technical Deep Dive into the Entropy Issue. The bug is theirs; the seed-generation RNG was wrong for 4+ years.
JUL 30 → 31 · overnight
Emergency hotfixes ship for every model and release track: Mk3 4.2.0, Mk4/Mk5 5.6.0 (standard) & 6.6.0X (Edge), Q 1.5.0Q (standard) & 6.6.0QX (Edge). Block's Bitcoin engineering & security teams publish an independent technical analysis the same day.
JUL 31, 2026 · NOW
You are here. The stolen BTC still hasn't moved. The investigation continues. Fixed firmware exists. Affected seeds do not get repaired by it — migration is required.
03Root cause — how a 40-bit seed got shipped for 4+ years
The mechanism is a small masterpiece of how huge disasters hide inside tiny mistakes. Here is the chain, in plain language.
The hardware TRNG that was never consulted
A Coldcard is supposed to generate your seed using a true hardware random number generator (TRNG) — a dedicated circuit in the STM32 chip producing genuine physical randomness. Coinkite wrote its own wrapper around that hardware, which is exactly the right practice. To avoid conflicts, the production build set a configuration flag, MICROPY_HW_ENABLE_RNG, to zero — telling the underlying MicroPython system: "don't use your built-in RNG, we have our own."
The off-by-one-thought bug
A separate library the firmware relies on — libNgU, added in the March 2021 migration to libsecp256k1 — needed to check whether that hardware RNG was available. It checked whether the flag was defined… not whether it was enabled. The flag was defined. Its value was zero, meaning "off" — but the check only asked "does this exist?" and the answer was yes. The build completed with no error and no warning, and quietly wired seed generation to MicroPython's software fallback instead of the hardware chip.
The exact guard
The relevant preprocessor guard used #ifndef — which tests whether MICROPY_HW_ENABLE_RNG is defined, not whether its value is nonzero. Coinkite defined the macro as zero, so the guard passed and the intended #error never fired. Seed generation resolved the rng_get() symbol to MicroPython's software fallback instead of Coinkite's board-specific TRNG.
What the fallback actually was
The software fallback is Yasmarang — a small, non-cryptographic pseudo-random generator, seeded from the chip's fixed factory serial number and a couple of timer registers. None of those are secrets. Feed a predictable input into a predictable algorithm and you get a predictable output that merely looks random. It passes the eye test. It fails reality.
On Mk3 hardware, Coinkite's own estimate puts the search space at ~2⁴⁰ (~1.1 trillion combinations). That number is comically small next to the 2¹²⁸ a 12-word seed is supposed to offer — small enough that a well-resourced attacker generates every possibility offline and checks each against funded addresses. On the current Mk4, Q and Mk5, a boot-time reseed pulls entropy from the secure elements (SE1/SE2), but the code keeps only 32 bits of it, capping the meaningful search space near 2³² (~4 billion) — around 2⁷² total once timing states are counted. Better. Still nowhere near the target. Coinkite calls this "a material improvement that still does not reach the target."
Why the open-source audits missed it
ColdCard's firmware is fully open source and has been reviewed — including by Coinkite itself. The reviews confirmed the correct hardware TRNG was present in the compiled binary, but never verified which of the two identically-named rng_get() functions the seed-generation path actually reached — the end-to-end symbol resolution and call reachability. The good code was in the building. It just wasn't the code that answered the door. Present is not the same as used.
NVK's own admission in the technical backgrounder is disarmingly honest: most of the randomness on the Coldcard was coming from a software PRNG "that I didn't know was actually in the source code base" (inherited from a MicroPython submodule), while the hand-built hardware TRNG "was still running, but just by chance, and only for less important things." Two functions shared the same name, and the wrong one quietly won.
The fix — the blind spot is now a build error
The hotfix does something almost poetic: the build now explicitly excludes MicroPython's fallback PRNG object and adds a compile-time RNG symbol check that fails unless the board-specific object defines the global rng_get() symbol and the upstream fallback object defines no symbols. The exact blind spot that let this ship for four years is now a build failure. The hotfixes add no new features — they just generate entropy correctly.
Same poisoned well
The weak generator did not only touch seeds. Coinkite confirmed it also affected paper-wallet keys, seed XOR masks, cloning & USB encryption, Key Teleport, Web2FA, and Secure Notes passwords — plus ephemeral keys for Clone/Key Teleport and BIP-85 seeds derived from a compromised seed. The rot ran deep because everything drank from the same well.
The AI angle
Coinkite says it has to assume the attacker used AI to comb through old versions of the open-source firmware and find the flaw. The gut-punch: the company ran one of the best available AI models over its own code weeks earlier, and it "did not find this bug or anything serious." Same tools, both sides of the fight. In NVK's words: "it did not help us, and only helped the bad guys." He warns every open-source developer: "If your firmware is open-source or has ever been public, assume it's already being read by attackers and defenders alike." Independent researchers (LLFOURN, Block, and others) have since published their own attack-cost models and analyses.
04Scope — what's affected, what isn't
The early headlines fixated on the Mk3, which is misleading. This is a Coldcard problem, not an Mk3 problem. Every current model generated weakened seeds too — the Mk3's near-deterministic worst case just happened to be what got hit first. Exposure depends on which firmware generated your seed, not the age of your device or its current firmware.
Device
Firmware that generated the seed
Effective entropy
Status
Mk3
4.0.1 → 4.1.9 (Mar 2021 → 4.2.0)
~2⁴⁰ — near-deterministic for a known device/startup state
CRITICAL
Mk2
v4 firmware
Essentially no real cryptographic entropy (Block analysis)
CRITICAL
Mk4 / Mk5
Before standard 5.6.0 or Edge 6.6.0X
~2⁷² (32-bit secure-element reseed)
SERIOUS
Q
Before standard 1.5.0Q or Edge 6.6.0QX
~2⁷²
SERIOUS
Mk1
Any
— (predates the bug)
CLEAR
Mk2/Mk3 on pre-4.0.0 firmware
Any seed made before v4.0.0
Used the real hardware generator
CLEAR
Mk3 on 4.2.0+
Seeds generated after update
Corrected
CLEAR
TAPSIGNER / OPENDIME / SATSCARD
Any
Different codebases entirely
NOT AFFECTED
Block (Bitkey) / Trezor products
—
Independent implementations; no Block products affected
CLEAR
Important correction
You'll see an "eight-year-old bug" figure in some coverage. That's the age of the vulnerable MicroPython fallback code (added upstream May 2018) — not how long Coldcard seed generation was affected. The regression entered in a single commit dated March 1, 2021, shipped in v4.0.0 on March 17, 2021, and the partial Mk4 reseed arrived in March 2022 without ever fixing the root cause. Affected seeds span a little over four years, not eight.
The dice & passphrase exceptions
The bug affects only the device-generated portion of the entropy. Two things you may have supplied yourself are unaffected:
Dice rolls: if you entered 50–98 fair, independent, private rolls via Add Dice Rolls, the dice alone contributed at least 128 bits of entropy; 99+ rolls ≈ 256 bits. Coinkite: "If you entered at least 50 fair and independent rolls, and the rolls were not recorded or exposed, we do not consider the resulting seed at risk from this RNG issue alone." Fewer than 50 rolls, or you don't remember → migrate.
BIP-39 passphrase (the 25th word): a strong, unique passphrase is an independent secret the device never generates — it creates an entirely separate wallet. Early analysis says such seeds are at minimal risk from this bug. Note: your PIN is not your passphrase. The PIN unlocks the device; it has nothing to do with this bug. Even with a strong passphrase, Coinkite still recommends migrating to a freshly generated seed when practical.
A bad seed follows you everywhere
A seed created on an affected Coldcard stays weak even if you restore it onto a different brand of device — a Trezor, a Ledger, a new Coldcard. The weakness lives in the numbers, not the hardware. You cannot launder a bad seed by moving it. The fix is a genuinely new seed, not a migration of the old one.
05Are you affected? A five-minute checklist
Did you generate the seed on a Coldcard after March 2021?
If the seed was made on any Coldcard (Mk2/Mk3/Mk4/Mk5/Q) after March 2021, keep reading. If it was made on an Mk1, or on an Mk2/Mk3 running firmware before 4.0.0, or on a non-Coldcard device — you're clear on this specific issue.
Check the firmware version that was installed at seed-creation time.
On the device: Advanced → Upgrade → Show Version. Exposure depends on the firmware in use when the seed was generated — not the device's age, not its current firmware.
Did you add at least 50 independent, private dice rolls?
50–98 rolls ≈ ≥128 bits from dice alone; 99+ ≈ 256 bits. Only counts if the rolls were fair, independent, private, and actually entered via Add Dice Rolls. If you're unsure how many, or whether they were private — treat the seed as affected.
Is the wallet protected by a strong, unique BIP-39 passphrase?
A genuinely strong passphrase (long, random, never reused, never stored digitally) is an independent barrier — minimal risk from this bug alone. A short, common, patterned, quoted or reused one is not protection. Still migrate when practical.
Does the wallet still hold funds?
Empty wallet or already migrated to a fresh seed elsewhere? You're done — the risk lives only in wallets still holding funds under a seed the broken firmware produced.
When in doubt, migrate
The single most dangerous phrase in self-custody right now is "I think I'm fine." The downside of a wrong "fine" is total loss; the cost of migrating is an afternoon of careful work. Coinkite, Block, Shinobi and the whole industry agree: if you can't prove the dice/passphrase exception, assume exposure.
06Remediation — step by step
First: calm
Coinkite's advice is the most important sentence in this whole affair: "Rushing a wallet migration can create a more immediate risk than the issue you are trying to address." Verify every backup, every address, every fingerprint. Send a small test transaction before you move the rest. A careful hour beats a panicked ten minutes.
Option A — fastest: move funds to a different hardware wallet
If you have (or can get) a hardware wallet that is not a Coldcard — Trezor, Bitkey, Foundation, etc. — send your funds there. This is the quickest, simplest way to get coins someplace secure. Caveat: the destination wallet must have a new seed generated on the new device. Restoring your old Coldcard seed into it does nothing but move the weakness.
Option B — interim: passphrase wallet on the existing device (temporary)
If you need breathing room before a full migration, a strong unique passphrase creates an entirely separate wallet that the attacker cannot compute from your weak seed alone:
Generate a strong passphrase. Shinobi's guidance: at minimum six random words from the BIP-39 word list, chosen with a proper source of randomness — do not pick words yourself. Coinkite's official passphrase instructions are linked in the sources below.
Set it on the device and verify. Enter the passphrase on the Coldcard, check the wallet fingerprint (or a receive address), power-cycle the device, re-enter the passphrase, and confirm the fingerprint matches. A typo'd passphrase silently creates a different wallet.
Move funds to the passphrase wallet. Send your funds there. Keep the passphrase written down and stored separately from the seed words.
Understand this is temporary. This buys you enough security to plan — it is not the destination. Continue to Option C (or A) for the permanent fix.
Option C — the proper fix: update firmware, generate a new seed, migrate
Update the firmware first. Mk3 → 4.2.0+; Mk4/Mk5 → standard 5.6.0+ or Edge 6.6.0X+; Q → standard 1.5.0Q+ or Edge 6.6.0QX+. (Full procedure in section 07.) Remember: standard and Edge are separate release tracks — do not assume an older Edge 6.x release is fixed just because its number is higher than the standard release.
Do not generate any new seed until the fixed firmware is confirmed installed.
Generate a completely new seed on the updated device. The fixed firmware's device-generated seed is sufficient — dice are optional now. If you use a passphrase, back it up exactly and store it separately.
Record and verify the new backup. Write the words down, re-verify them on-device, and record the wallet fingerprint (XFP). Power-cycle and confirm the fingerprint is stable.
Verify a receive address on the device's own screen. Never trust an address shown only on your computer.
Send a small test transaction to the new wallet and confirm it arrives. Even better: test sending from the new wallet too, so you know the seed works in both directions.
Only then move the remaining funds. Sweep the old wallet(s) to the new address(es).
Keep the old backup until the migration is fully confirmed — the complete balance arrived and is confirmed. Then destroy it carefully (shred paper, and understand steel backups can only be physically destroyed).
One-device Mk3 migration
If the affected Mk3 is your only device, firmware 4.2.0 lets it generate a replacement seed correctly — you don't need newer hardware. But you must carefully alternate between the old and new seeds on one device: verify the old seed's written backup and fingerprint → install 4.2.0 → generate the new seed, record and verify it → restore the old seed and send a small test to the new address → restore the new seed and confirm receipt → restore the old seed and move the rest → restore the new seed and confirm. If a second device with fixed firmware is available, use it instead — it's far less error-prone.
Option D — advanced: dice-only seed (zero device RNG trust)
For those who want a replacement seed that never touches the device's random-number generator at all — after updating to 4.2.0, use Import Existing → Dice Rolls and enter at least 99 rolls of a fair six-sided die. This dedicated dice-only path hashes the roll sequence directly; it does not use the device's generator. This is explicitly an advanced procedure:
The dice sequence is itself secret key material — never photograph it, save it digitally, or enter it into a networked computer.
Follow Coinkite's dice-roll method documentation (linked below) before attempting it.
The same one-device alternation rules apply: verify backups and fingerprints at every step, test with a small amount, keep the old backup until done.
Special case — multisig with affected Coldcards (Peter Todd's warning)
No multisig wallet was drained in the sweep — but that's not a free pass. Core contributor Peter Todd flagged a specific edge case: a 2-of-3 with two affected Coldcards and a third uncompromised device. The moment you move funds, your script is revealed for the first time (it was previously hidden behind the address hash) — and the attacker now knows enough to race you using the two compromised keys. If you haven't reused addresses, MARA mining pool's private-mempool service (Slipstream) can mine your transaction privately, keeping pubkeys secret until they're in a block. If you've already reused addresses, just move funds ASAP — and afterwards, rebuild the wallet with healthy keys.
What does NOT protect you
Updating firmware does not repair an existing seed. The weak seed already exists; a patch stops the bleeding, it doesn't heal the wound.
Restoring the seed into another brand of wallet. Bad numbers stay bad.
Your PIN, trick PINs, or the device lock. PIN has nothing to do with this bug.
Moving coins to a new address derived from the same seed. The attacker can compute every child key.
BIP-85 child seeds. Derived from a compromised parent, they're compromised too.
Hoping it was only Mk3. Mk4/Q/Mk5 seeds at ~2⁷² are below any sane security target.
07Upgrading firmware — and verifying it
Official upgrade path, from Coinkite's docs (last updated July 31, 2026 — the day the hotfixes shipped):
What you'll need
Your Coldcard + a microSD card up to 32 GB, FAT32/FAT12
A Micro-USB power source (power-only cable preferred)
An internet-capable computer to download the firmware file
The procedure
Check your current version. Power on, enter PIN, then Advanced → Upgrade → Show Version. Compare against the latest on coldcard.com/docs/upgrade.
Download the correct firmware. The 20xx-…-coldcard.dfu file for your model and release track (standard vs. Edge), from the official downloads page only. Mk3: 4.2.0 · Mk4/Mk5: 5.6.0 (std) / 6.6.0X (Edge) · Q: 1.5.0Q (std) / 6.6.0QX (Edge).
Verify the hash (strongly recommended). Compare the SHA-256 of the downloaded file against the value in the official signatures.txt next to your version. Windows: certutil -hashfile <file>.dfu SHA256 · macOS: shasum -a256 <file>.dfu · Linux: sha256sum <file>.dfu.
Verify the PGP signature (strongly recommended). Coinkite signs signatures.txt with key 4589779ADFC14F3327534EA8A3A31BAD5A2A5B10 (Peter D. Gray / DocHex). On Windows, use Kleopatra (Gpg4win); expect "Good signature from…". The "key is not certified with a trusted signature" warning is normal.
Load it. Copy the file to the microSD, eject, insert into the unlocked Coldcard: Advanced → Upgrade → From MicroSD, select the file. The red LED lights during install — do not power off during the upgrade (interrupting an Mk4 upgrade puts it into recovery mode).
Confirm. After reboot, enter your PIN prefix, verify the two hardware-specific words shown, complete the PIN, and watch for the green GENUINE LED. Re-check Show Version.
Red LED still lit after restart? Bless the firmware: Advanced → Upgrade → Bless Firmware. That confirms to the device that you approve the change.
Then, and only then
With fixed firmware confirmed, go back to section 06, Option C: generate the new seed, verify, test, migrate. Firmware update ≠ remediation. It's step one of it.
08Hardening — never rely on one vendor's randomness again
This is not Coldcard's unique curse. Milk Sad (2023) exposed wallets built with a tool that used a timestamp as its only entropy. Randstorm exposed millions of browser wallets from 2011–2015. Ill Bloom — disclosed just three weeks before this incident — hit five separate wallet implementations with weak seed generation. Different vendors, same failure mode, again and again. Harden in ways that don't depend on any one company getting it perfect:
Add a BIP-39 passphrase. It layers a secret the device can never generate or leak — and as this incident just proved, it's the difference between a scare and a catastrophe. Every drained wallet was passphrase-free.
Contribute your own entropy. 99+ fair dice rolls via the device's dice-roll feature means you're not trusting any black box to be honest about its randomness. Rolling dice is a pain; losing everything is worse.
Multisig across vendors. A 2-of-3 spread across different manufacturers means a flaw in any single device, firmware, or RNG cannot drain you on its own. Not one multisig wallet was touched in this sweep. This is "don't trust, verify" turned into architecture.
Verify receive addresses on the device's own screen, never on your computer.
Test every new wallet — both send and receive — with a small amount before committing real savings.
Buy hardware directly from the manufacturer and verify firmware signatures on every update.
Keep firmware current — while understanding what a patch can and cannot undo.
Treat custody as a practice, not a purchase. The 2021 buyers who got swept set up once and never looked back. Sovereignty is a discipline you keep, not a product you own.
09The stolen coins & the ongoing investigation
There is a strange, quiet coda to all of this. As of July 31, the stolen 594 BTC has not moved: ~562 sit in the consolidation address, ~32 on an intermediate hop, and not a single satoshi has gone to an exchange or mixer. The attacker is sitting on $38M in the open — and the next time those coins twitch will be the first real clue to who holds them.
Investigation status: Coinkite's investigation is ongoing, with a formal technical review promised. Independent researchers (Block, LLFOURN, instagibbs, and others) have published their own analyses.
Attribution: Coinkite assumes AI-assisted code review of its open-source history found the flaw; it is "committed to working with affected users who want to pursue a police report, insurance claim, or their own investigation," including a written incident summary and transaction data. Chainalysis is reportedly tracking the funds.
Broader fallout: the industry expects other wallet codebases to be probed next — open-source projects that generate key material are now under a microscope, with AI-assisted auditing on both sides of the fight.
Your duty: reach out to anyone you know who might hold a Coldcard-generated seed. Most people don't read Bitcoin news daily, and many don't yet know they're exposed.
10Sources & further reading
Primary sources first. Verify everything yourself before acting — that's the whole lesson.
The Coldcard Hack: A Timeline of the $38M Entropy Failure — Zachary Addair, Bitcoin Wellhttps://bitcoinwell.com/blog/the-coldcard-hack-a-timeline-of-the-dollar38m-entropy-failure-and-how-to-keep-it-from-happening-to-you
Coinkite Releases Fixed Firmware After Coldcard Bug; AI Likely Involved In The Breach — Bitcoin Magazinehttps://bitcoinmagazine.com/business/coinkite-releases-fixed-firmware-after-coldcard-bug-ai-likely-involved-in-the-hack
Coinkite Dice Roll Method (dice-entropy guidance)https://coldcard.com/docs/dice-rolls