A single misplaced macro cost Coldcard users $130 million

Is your Coldcard affected by the entropy bug?

For five years, a single preprocessor guard in Coldcard's build configuration quietly routed Bitcoin seed generation through a software pseudo-random number generator instead of the device's hardware RNG. On July 30, 2026, someone finally used it.

If you generated a seed on a Coldcard Mk2 or Mk3 running firmware 4.0.1 through 4.1.9, that seed is at high risk. Coinkite estimates those devices produced roughly 40 bits of effective entropy instead of the intended 128 — about 1.1 trillion combinations, brute-forceable in hours on consumer GPUs, against roughly 3.4×10³⁸ for a properly seeded wallet . Mk4, Mk5 and Q owners got partial cover: secure-element reseeding lifted effective entropy to roughly 72 bits, which is materially better but not a clean exemption .

The defect entered the codebase in March 2021 with Coinkite's migration to the libngu cryptography library and went undetected until the first sweep . Galaxy Research has confirmed at least 1,719 BTC (~$111M) stolen with high confidence across three major waves and 14 smaller incidents, with total losses potentially reaching 2,055 BTC (~$130M) (video: PolarByte) .

What actually broke: the macro that silently disabled true randomness

The defect was a build-configuration error, not a broken cipher. When Coinkite migrated Coldcard's cryptography to the libngu library in March 2021 , seed generation began calling ngu.random.bytes(). At link time that call resolved to MicroPython's Yasmarang software pseudo-random number generator — an upstream function added in May 2018 — instead of the STM32 hardware true random number generator soldered onto the board . Every seed produced on affected firmware inherited that substitution, and nothing in the wallet's user interface signaled it.

The mechanism was a single preprocessor guard. Coinkite deliberately set MICROPY_HW_ENABLE_RNG to 0 to disable software fallbacks, and added an #error directive intended to halt compilation if the software path was ever pulled in. But the guard used #ifndef, which tests only whether a macro is defined — not what value it holds. Because the macro was defined-as-zero, the condition evaluated as "already defined," the #error never fired, and the fallback PRNG was silently compiled into every shipped binary .

Two conditions turned that typo into a five-year exposure window. First, both implementations shared an identical function signature, so the software and hardware paths were interchangeable at the call site — no compiler warning, no type mismatch, no runtime error. Second, the correct board-specific TRNG code was present in the binary. Reviewers auditing the firmware could open the source, confirm the hardware entropy routine existed, and reasonably conclude the device used it. What no one verified was end-to-end symbol resolution and call reachability from the wallet's actual seed-generation path . Code review answered "does the right function exist?" when the necessary question was "does the seed path actually reach it?"

The practical consequence is what made the theft scalable. Block's engineering review found that an attacker who can constrain three variables — device UID, timer state at boot, and prior RNG-call history — can reproduce candidate output streams entirely offline . No physical access to the device. No phishing for recovery words. No supply-chain interception. The attacker generates candidate seeds on their own hardware, derives the addresses, and checks them against the public blockchain for balances. A wallet sitting untouched in a safety deposit box is exactly as exposed as one plugged in daily.

"The randomness was never random — it was a deterministic function of numbers an attacker can guess. That's why forty bits collapses to hours on commodity GPUs" (video: Techsters Haven, Random Numbers Aren't Random: The 40-Bit Wallet Heist).

The entropy cost was severe but not uniform across the product line. Instead of the intended 128 bits, the flawed path seeded from device serial ID and boot-time clock state, yielding roughly 40 bits of effective entropy on Mk2 and Mk3 units running firmware 4.0.1 through 4.1.9, and roughly 72 bits on Mk4, Mk5 and Q, where secure-element reseeding partially masked the defect . Forty bits is about 1.1 trillion combinations — searchable in hours on ordinary GPU hardware — against roughly 3.4×10³⁸ for a correctly generated 128-bit seed . That gap between "trillions" and "undecillions" is the entire difference between a wallet an attacker can grind through and one they cannot.

Which Coldcard models and firmware versions are safe now

A Coldcard is patched only if it runs one of five specific builds: Mk2/Mk3 on 4.2.0 or later, Mk4/Mk5 standard on 5.6.0 or later, Q standard on 1.5.0Q or later, Mk4/Mk5 Edge on 6.6.0X, or Q Edge on 6.6.0QX . Anything below those numbers on its own track still contains the software PRNG fallback. Coinkite's current recommended standard builds as of August 2026 are 5.6.1 for Mk4/Mk5 and 1.5.1Q for Q .

The version-numbering trap is worth stating plainly: Standard and Edge are separate release tracks, not a single ascending sequence . An Edge build labelled 6.x is numerically higher than a standard 5.6.1, but that number says nothing about whether the standard firmware on a different device is patched — and an older Edge build below 6.6.0X is unpatched despite carrying a "6" in front. Read the track first, then the number.

Check the installed build on the device itself rather than inferring it from a purchase date or a shipment batch. Navigate to Advanced > Upgrade > Show Version and compare the result against the table above . Coinkite also halted shipments of vulnerable stock and destroyed the remaining inventory, so newly purchased units should ship patched — but a device that sat in a drawer, a safety deposit box, or a reseller's shelf since 2021 almost certainly did not update itself .

Verification before flashing is not optional housekeeping here. An incident of this profile draws imitation firmware and phishing pages, and a hardware wallet that accepts an unsigned image is a worse failure than the entropy bug itself. Coinkite directs users to confirm both the SHA-256 hash and the GPG signature of any downloaded build :

• macOS — import Coinkite's public key into GPG Keychain, then verify the signature file against the downloaded firmware.
• Linux — run gpg --verify signatures.txt and confirm the SHA-256 digest matches the published value.
• Windows — use Kleopatra to check the detached signature before transferring the file to the device.

One more boundary applies to every row in that table: installing a fixed build protects seeds generated after the update. It does nothing to a seed that already exists on the device, which is a separate decision covered below.

Decision criteria: do you need to migrate to a new seed?

Migrate unless you can prove your seed came from an exception. The working rule from Coinkite is blunt: if a seed was generated on affected firmware — 4.0.1 through 4.1.9 on Mk2/Mk3, or any pre-fix build on Mk4, Mk5 and Q — treat it as compromised, no matter how long the wallet has sat untouched . Dormancy is not protection. The weak entropy is baked into the private key itself, and an attacker reconstructs candidate keys offline from device UID, timer state and prior RNG-call history — the device never has to be touched, and the owner never has to reveal a recovery word .

Only two conditions take a seed off the migration list, and both must be verified honestly rather than assumed.

• Exception 1 — dice-roll entropy. A seed created with at least 50 fair, independent, unrecorded dice rolls (12-word) is not considered at risk from the RNG defect alone; 99 or more rolls, the 24-word standard, contributed roughly 256 bits . Every qualifier matters. Rolls that were written down, photographed, generated by an app, or cut short of the minimum do not qualify.
• Exception 2 — a strong BIP-39 passphrase. A unique, high-entropy passphrase sits outside the compromised generation path and forms an independent barrier. But short, common, patterned or reused passphrases stay guessable once the underlying key space has already collapsed, and Coinkite still recommends migration even for passphrase users .

The timing question answers itself. Roughly 90% of the stolen coin remained unmoved as of August 7, 2026, which means the operation is still in an accumulation phase rather than a cash-out phase . Sweeps were also not confined to one burst: Galaxy Research flagged a suspected fourth wave of 449 BTC across 709 addresses on August 4 (video: PolarByte). Wallets that survived the first waves were not skipped for a reason — they simply had not been reached yet.

One more filter before you decide: uncertainty counts as exposure. If you cannot recall which firmware version was running the day the seed was created, or whether those dice rolls were genuinely unrecorded, the honest classification is "affected." Migration costs one on-chain fee and an afternoon of careful work. The alternative is holding a key whose search space may already be inside an attacker's precomputed candidate set.

How to migrate funds safely: the 6-step path

Coinkite's published migration path is a fixed sequence: update firmware, generate a completely new seed on the patched device, verify the backup, verify a receiving address, send a small test transaction, move the remaining funds, then destroy the old backups . The order matters more than any single step. Generating a seed before the firmware update reproduces the defect; moving funds before verifying the backup means a single failed restore permanently strands the balance you just rescued.

Step one is the firmware flash itself, and it is the only step where a mistake is recoverable at no cost. Verify the SHA-256 hash and GPG signature of the downloaded file before writing it to the device — GPG Keychain on macOS, gpg --verify signatures.txt on Linux, Kleopatra on Windows . Confirm the result under Advanced > Upgrade > Show Version before proceeding .

Step two is where the structural fix becomes visible. On patched firmware, master seed generation draws fresh entropy from three independent hardware sources on every single generation: the STM32 true random number generator plus both secure elements, SE1 and SE2 . No single source determines the output, so the failure mode that produced roughly 40 bits of effective entropy on Mk2/Mk3 has no equivalent single point of collapse.

The user-entropy layer is now mandatory and cannot be skipped. The patched flow requires one of three inputs, hashed together with the device-generated value so that neither side alone determines the seed :

• Dice rolls — minimum 50 for a 12-word seed, 99 for a 24-word seed.
• Coin flips — 128 flips.
• Key mashing — at least 65 timed presses, where the timing between presses supplies the randomness.

Readers who do not want to trust device hardware at all have a fourth option: the Dice Rolls Only workflow excludes device-generated entropy from the seed entirely, so the resulting key depends on nothing but physical dice . That path costs more time — 99 careful rolls is a genuinely tedious 20 minutes — and it shifts the entire risk onto whether your dice are fair and your rolls unrecorded. It is the correct choice for anyone whose confidence in the manufacturer has not survived the past month, and unnecessary for anyone who accepts the three-source design.

Steps three through five are the verification block, and skipping them is the most common way a technically correct migration still loses money. Write down the new seed words, then use the device's own backup-verification flow to confirm the words you recorded match what the device holds. Verify a receiving address on the Coldcard screen against what your wallet software displays. Send a small test transaction and confirm it arrives before moving the balance . Only after the test confirms should the remaining funds move in step six, followed by the physical destruction of every old backup — the old seed remains sweepable indefinitely, and 90% of the stolen coin from this incident was still sitting unmoved in attacker addresses as of August 7, 2026, which tells you the attacker is patient rather than finished (video: PolarByte).

One hard rule applies throughout: never enter a seed phrase into any website claiming to check whether your wallet is vulnerable . No legitimate vulnerability check requires your recovery words. Every site asking for them is a second theft layered on top of the first, and incidents of this profile reliably attract them.

How the attackers drained wallets: exploitation timeline

The theft ran as a coordinated offline brute-force campaign, not a live intrusion. The first sweep began on July 30, 2026 at 01:10 UTC, draining 1,082.65 BTC (~$70.2M) from 1,196 addresses in 41 minutes . Because candidate seeds could be reproduced from device UID, timer state and prior RNG-call history without ever touching the hardware, victims had no signal to react to — the first evidence was an outbound transaction (The Hacker News, 2026-08).

Disclosure lagged the attack. Coinkite published its first advisory on July 30 and expanded the scope on August 1 at 2:35 p.m. EDT, roughly 30 hours after the first wave had already completed . That gap matters for anyone still deciding how urgently to migrate: the sweeping ran ahead of the public warning, so "I checked the news and nothing had happened yet" was never a safety signal (video: PolarByte).

Subsequent forensic work showed the sweeps continued in structured waves. Galaxy Research confirmed 1,596 BTC across three major waves plus 14 smaller incidents, and flagged a suspected fourth wave of 449 BTC from 709 addresses on August 4 . Galaxy later raised its high-confidence figure to at least 1,719 BTC (~$111M), with total losses potentially reaching 2,055 BTC (~$130M) . Roughly 90% of the stolen coin remained unmoved as of August 7, and Galaxy shared attacker addresses with US federal law enforcement, exchanges and investigation firms (video: PolarByte). Elliptic, TRM Labs, Galaxy and Block are all running parallel investigations (Techsters Haven, 2026-08).

The individual cases show how little physical security helped. Canadian holder Jonathan Goodman told Bloomberg that his Coldcard — kept in a bank safety deposit box — was drained within seven minutes of the wallet loading, a reported $1.6M loss (video: PolarByte).

"The attacker never needed the device. They needed the math the device produced," — summary of Block's engineering review, which found candidate output streams could be reconstructed entirely offline (source: The Hacker News, 2026-08).

Context matters for reading the pattern: the sweeps landed inside a broader stretch of pressure on Bitcoin infrastructure. BTCPay Server warned merchants of a critical authentication flaw on August 7 and advised them to update and shut down servers, Foundation's BTCPay-hosted Lightning node was drained overnight, and Boltz took infrastructure offline citing rising AI-assisted attacks (video: The Defiant). For a Coldcard holder still weighing migration, the operational read is simple: the address set is already enumerable offline, and the 90% that has not moved is inventory, not immunity.

Which migration path fits your situation

The right migration path depends on three variables: the size of the balance, whether the seed was generated with independent dice rolls, and whether you can independently verify your firmware version and its GPG signature. Coinkite's guidance treats a new seed on patched firmware as the default outcome for every affected device, with only two narrow exceptions — 50 or more fair, unrecorded dice rolls, or a strong and unique BIP-39 passphrase . Everything below is a way of deciding how fast you move, not whether you move.

• Cold-storage holder with a large balance: migrate first, optimize later. The exposed key space is already enumerable offline, and the first sweep drained 1,082.65 BTC from 1,196 addresses in 41 minutes on July 30, 2026 . Accept the inconvenience of a fresh backup, a new receiving address and a test transaction rather than waiting for a quieter week.
• Small balance, or a seed you believe came from dice: verify the exception before you rely on it. The carve-out applies only to fair, independent, unrecorded rolls — 50 minimum for a 12-word seed, 99 or more contributing roughly 256 bits . If you cannot recall the roll count, whether the die was fair, or whether the sequence was written down anywhere, the exception does not apply and migration is the safer read.
• Mk4, Mk5 or Q users counting on secure-element mitigation: migrate anyway. Coinkite estimates roughly 72 bits of effective entropy on those models versus about 40 bits on Mk2/Mk3 . Better is not the same as intended: the design target was 128 bits, and 72 bits is a materially smaller search space than the standard your custody assumptions were built on.
• Anyone who cannot confirm firmware version or signature: treat the device as worst case. Standard and Edge are separate release tracks, so a 6.x Edge number does not imply a fixed standard build, and the version check lives under Advanced > Upgrade > Show Version . If SHA-256 and GPG verification is beyond your comfort level today , assume exposure and migrate.

A BIP-39 passphrase sits between these categories rather than replacing them. It is an independent barrier, but Coinkite notes that short, common, patterned or reused passphrases may be guessable, and still recommends migration . Treat it as time bought, not risk removed. And whichever path you take, no verification step should ever involve typing a seed phrase into a website that offers to check whether you are affected .

What this means for hardware wallet security going forward

The Coldcard entropy failure is best read as a build-system audit failure, not a cryptography failure. The underlying primitives — libsecp256k1, the STM32 TRNG, the secure elements — were all sound and all present in the shipped binary; what failed was the verification that the seed path actually called them . Reviewers confirmed the correct board-specific code existed but never traced end-to-end symbol resolution and call reachability from the wallet seed path, so a preprocessor guard that tested only whether MICROPY_HW_ENABLE_RNG was defined — not that it was non-zero — let a software PRNG ship for roughly five years . For the category, the lesson is blunt: air-gapped does not mean audit-proof, and link-time and compile-time checks need the same rigor applied to the cryptography itself.

The industry response has been structural rather than cosmetic. Coinkite halted shipments of vulnerable stock and destroyed remaining affected inventory , and the hotfix now excludes MicroPython's fallback PRNG object from the build entirely while adding a build-time RNG symbol check so the wrong symbol cannot resolve silently again . On the forensic side, Elliptic, TRM Labs, Galaxy Research and Block are all investigating independently, and Galaxy has shared attacker addresses with US federal law enforcement, exchanges and investigation firms — with roughly 90% of the stolen coin still unmoved as of August 7, 2026 (video: PolarByte) .

Context matters here too. The theft landed inside a difficult stretch for Bitcoin infrastructure generally: BTCPay Server warned merchants of a critical authentication flaw on August 7, 2026 and advised them to update and shut down servers; Foundation's BTCPay-hosted Lightning node was drained overnight; and Boltz took infrastructure offline citing rising AI-assisted attacks (video: The Defiant) . Faster, cheaper offline analysis raises the value of every latent implementation defect, which shortens the window between "discovered" and "exploited."

The concrete takeaway: treat firmware provenance as part of your threat model, not an afterthought. Verify SHA-256 hashes and GPG signatures before every flash , and where a vendor offers a workflow that removes device randomness from the equation — Coldcard's "Dice Rolls Only" seed generation, or the mandatory user-entropy step of 50+ dice rolls, 128 coin flips or 65+ timed key presses — use it . Entropy you generated yourself is the one input no build-time macro can quietly disable.

Frequently asked questions

How do I check if my Coldcard is running vulnerable firmware?

On the device, go to Advanced > Upgrade > Show Version and compare the number against the fixed release for your exact model and track. Patched builds are 4.2.0 or later for Mk2/Mk3, 5.6.0 or later for Mk4/Mk5 standard (5.6.1 is the current recommended build as of August 2026), and 1.5.0Q or later for the Q (currently 1.5.1Q) . Edge firmware is a separate track with its own numbering — 6.6.0X for Mk4/Mk5 Edge and 6.6.0QX for Q Edge — so a higher-looking 6.x Edge number does not mean you are running a fixed standard build . Before flashing anything, verify the SHA-256 hash and GPG signature of the downloaded file using GPG Keychain on macOS, gpg --verify signatures.txt on Linux, or Kleopatra on Windows .

Do I need to move funds if I generated my seed with dice rolls?

Per Coinkite, a seed created on affected firmware using at least 50 fair, independent, unrecorded dice rolls for a 12-word seed — or 99 or more rolls for a 24-word seed, which contributes roughly 256 bits of entropy — is not considered at risk from the random number generator defect alone . The qualifier matters more than the count. The rolls must have been genuinely random, physically independent, and never written down or photographed; if you used a loaded or unfamiliar die, reused a recorded sequence, or cannot recall whether you hit the minimum, treat the seed as unverified and migrate. Coldcard's post-fix documentation now makes the user-entropy step mandatory and offers a "Dice Rolls Only" workflow that removes device randomness from seed generation entirely .

Can updating firmware alone fix an already-compromised seed?

No. Firmware repairs the process that generates future seeds; it cannot retroactively add entropy to a seed that was already produced under the flawed path. The hotfix excludes MicroPython's fallback software PRNG from the build and adds a build-time RNG symbol check so the wrong function can no longer resolve silently, and master seed generation now draws fresh entropy from three independent hardware sources — the STM32 true random number generator plus both secure elements, SE1 and SE2 — on every generation . None of that touches keys already in circulation. Coinkite's migration path is explicit: update firmware, generate a completely new seed on the patched device, verify the backup and a receiving address, send a test transaction, move remaining funds, then destroy the old backups .

Does a BIP-39 passphrase protect an affected seed?

A strong, unique BIP-39 passphrase adds an independent barrier that an attacker must clear even after reconstructing the underlying seed, so it materially raises the cost of an attack. But the protection is only as good as the passphrase itself — short, common, patterned, or reused passphrases remain guessable, and an attacker who has already narrowed the seed space to a manageable candidate set can pair that work with a dictionary or credential-reuse attack. Coinkite recommends migrating to a new seed regardless of whether a passphrase is in use . Treat a passphrase as time bought, not as a substitute for regenerating the seed on patched firmware.

How much Bitcoin was stolen in the Coldcard entropy exploit?

Galaxy Research has confirmed at least 1,719 BTC — approximately $111 million — with high confidence, and estimates total losses across all identified waves may reach 2,055 BTC, or roughly $130 million (video: PolarByte). The first sweep began on July 30, 2026 at 01:10 UTC and drained 1,082.65 BTC (about $70.2 million) from 1,196 addresses in 41 minutes . A suspected fourth wave of 449 BTC from 709 addresses was flagged on August 4. As of August 7, roughly 90% of the stolen coin remained unmoved, and Galaxy shared attacker addresses with US federal law enforcement, exchanges and investigation firms; Elliptic, TRM Labs, Galaxy and Block are all investigating . Figures remain provisional while attribution work continues.

Enjoyed this article? Subscribe to get new stories by email whenever they're published.

Subscribe