72 bits, not 128: the entropy gap draining Coldcard wallets

Bitcoin's strongest self-custody promise — keys generated offline, never touched by an internet-connected machine — held up exactly as designed. The randomness behind those keys did not.

72 Bits vs. 128: What Coinkite's Advisory Actually Says

The Coldcard incident is an entropy failure, not a hack: a firmware change made on 1 March 2021 replaced the device's hardware random number generator call (ckcc.rng_bytes, reading the STM32 RNG) with ngu.random.bytes, where a build-configuration fallback silently substituted a software pseudorandom generator seeded from public, hardcoded constants . The result: seeds generated on affected firmware carried roughly 72 bits of effective entropy on Mk4, Mk5 and Q, and as little as ~40 bits on Mk2 and Mk3, against the 128-bit design target for a BIP-39 seed . At those levels, a seed is guessable offline by anyone who works out the defect.

Quick Answer: A March 2021 Coldcard firmware change swapped the hardware RNG for a deterministic software PRNG, cutting seed entropy to ~72 bits on Mk4/Mk5/Q and ~40 bits on Mk2/Mk3 versus a 128-bit target. Attackers began draining wallets on 30 July 2026; TRM Labs tracked roughly 1,816 BTC (~$116 million) taken.

Coinkite published its advisory, "COLDCARD Mk3 Seed Generation Warning," on 30 July 2026 and last updated it on 1 August 2026 at 2:35 p.m. EDT, describing the root cause as a limited-entropy failure in seed generation and confirming the investigation is ongoing . Fixed firmware shipped on 31 July 2026 . The exposure window ran from March 2021 to July 2026 — over five years in open-source code that anyone could read.

Two clarifications matter before anything else. The secure element was never breached, and no remote or physical access to any device was required . The seeds were weak at the moment of creation, sitting in cold storage exactly as their owners intended. That distinction drives everything downstream: patching the firmware does not repair a seed already generated under the defect, and TAPSIGNER, OPENDIME and SATSCARD are unaffected because they run different codebases .

How the RNG Broke: Inside the March 2021 Firmware Migration

The defect traces to a single commit dated 1 March 2021 that replaced Coldcard's seed-generation call ckcc.rng_bytes — which read the STM32 hardware random number generator directly — with ngu.random.bytes(), routed through the newly adopted libngu library during a MicroPython migration . On paper the swap was a refactor. In practice, a build-configuration mismatch inside libngu silently redirected the call away from the chip's true random number generator and into a software pseudorandom generator seeded from public, hardcoded constants, according to the forensic reconstruction published by TRM Labs.

The mechanism is a textbook C preprocessor trap. Production builds defined MICROPY_HW_ENABLE_RNG as zero — the macro existed, but its value said "off." The libngu code checked only whether the macro was defined, not whether it was enabled. Both conditions read as true to the compiler, so the build produced no warning and no error. rng_get() bound cleanly to MicroPython's "Yasmarang" software PRNG instead of the STM32 TRNG, and the resulting binary looked, to every automated check, exactly like a correct one.

Yasmarang is not a cryptographic generator and was never intended to seed a Bitcoin wallet. On affected devices it drew its state from the chip's unique ID and timer registers — values that are either permanently fixed per device or narrowly bounded and partially observable. Coinkite is explicit that the STM32 hardware TRNG itself never failed at runtime . The silicon worked; nothing ever called it.

That distinction explains why the entropy collapse was so severe on the older line. Block's independent engineering analysis, referenced in Coinkite's own upgrade documentation, found that Mk2/Mk3 output can be fully deterministic once three inputs are fixed: the device unique ID, the timer state at the moment of generation, and the history of prior RNG calls. Reconstructing a seed then reduces to searching a small parameter space rather than a 128-bit keyspace. Coldcard's firmware upgrade page quantifies the result as entropy "critically low at just ~40 bits" on Mk3 seeds generated under firmware 4.0.1 through 4.1.9 .

Newer hardware degraded differently, and less catastrophically. Mk4, Mk5 and Q mix secure-element entropy into the generation path, which breaks the pure-determinism result that applies to Mk2/Mk3. But the reseed step retained only 4 bytes of that secure-element material. Four bytes is 32 bits, which caps the number of distinguishable output streams at roughly 2^32 under otherwise known conditions — the arithmetic behind Coinkite's statement that Mk4/Mk5/Q entropy "may have been as low as ~72 bits" against a 128-bit design target .

Two structural features of the failure are worth isolating, because they generalise beyond this device:

• The failure was silent by construction. A misconfigured feature flag produced a clean build, a valid signature, and a device that generated plausible-looking BIP-39 words. There was no crash, no error screen, and no output a user could inspect to tell a strong seed from a weak one.
• Randomness has no self-test. Unlike a signing bug or a display bug, a degraded RNG produces output that passes casual inspection indefinitely. The defect shipped in firmware v4.0.1 and survived until July 2026 — a window of more than five years .

Coldcard's published firmware source shows what the intended path looks like: the standard new-wallet flow generates 32 random bytes, hashes them, and presents the word list for approval, while the Add Dice Rolls path folds each user-entered roll into the hash alongside device entropy . That second path is the reason a subset of affected devices produced sound seeds anyway — the dice supplied the randomness the compiler had quietly withheld.

Which Coldcard Firmware Versions Are Exposed?

Exposure is defined by the firmware version that was running when the seed was created, not by the version installed today. For the Mk2 and Mk3 lines, every build from 4.0.1 through 4.1.9 inclusive is affected, with effective entropy Coinkite's upgrade documentation describes as "critically low at just ~40 bits" . Mk4, Mk5 and Q devices sit in a milder band, with entropy potentially as low as ~72 bits against the 128-bit design target . Firmware v4.0.0 shipped on 17 March 2021 but was never released as a signed public binary, which is why the affected range starts at 4.0.1 .

The fixed builds shipped on 31 July 2026, one day after Coinkite published its advisory and roughly a day after the first sweep began . That leaves an exposure window running from March 2021 to July 2026 — a little over five years in which any seed generated on device randomness alone inherited the defect .

Three practical qualifiers matter when reading the table:

• Card products are out of scope. TAPSIGNER, OPENDIME and SATSCARD run separate codebases and were never routed through the affected library, so Coinkite lists them as unaffected .
• Dice rolls override the version. A seed created on vulnerable firmware but with at least 50 fair, independent, private rolls entered through Add Dice Rolls is not considered at risk from this RNG issue alone; 99 or more rolls contribute roughly 256 bits .
• A strong BIP-39 passphrase raises the bar. A unique 25th word makes offline reconstruction substantially harder even on an otherwise weak seed, though Coinkite does not present it as a substitute for regenerating .

Owners who cannot recall which firmware was on the device at setup should treat the seed as affected. Coldcard's upgrade page lists the current signed releases per line, and checking the installed version on the device screen only tells you where you are now, not where the seed came from .

Losses So Far: From $38 Million to $130 Million-Plus Across Four Waves

The confirmed theft total from the Coldcard seed-generation defect has not been finalized, but published forensic estimates converge on a range between roughly 1,083 BTC and about 2,000 BTC — from about $70 million to roughly $130 million — drained across multiple waves beginning 30 July 2026 . These are not competing final numbers. They are a sequence of snapshots taken as tracing widened, and reading them as rival claims produces a distorted picture of the incident's scale.

The first published figure covered the opening sweep only: approximately 594 BTC (~$38.3 million) taken from roughly 500 single-signature wallets in a 15–25 minute window on 30 July . Block's engineering analysis then linked 695 earlier related transactions moving a further 488.1 BTC, which pushed the combined figure to about 1,082.6 BTC . Galaxy Research independently documented 1,082.65 BTC (about $70.2 million) fully drained from 1,196 completely emptied addresses inside a 41-minute window on 30 July .

Later Galaxy updates raised the count to three suspected waves totalling 1,367.05 BTC (about $88.6 million) across 4,585 addresses, with Galaxy's Alex Thorn noting the associated bitcoin remained parked in attacker-controlled addresses rather than being moved off . TRM Labs' forensic write-up went further, describing four distinct waves totalling approximately 1,816 BTC (~$116 million) across more than 5,200 addresses, including a later wave running from Friday midday to Saturday morning that took 208 BTC from 1,912 addresses . Outer-bound tracking cited by Decrypt referenced as many as 15 attacker clusters and roughly 2,000 BTC (~$130 million) , a figure consistent with the "over $130 million" framing carried in mainstream coverage by TechCrunch on 4 August .

The spread between $70 million and $130 million is not analyst disagreement so much as a difference in how many clusters each team had attributed at the time of writing. Multiple parties appear to have been exploiting the same weakness in parallel — Galaxy identified at least a dozen distinct attackers racing each other through the same address space, and TRM's own analysis notes that "transaction construction differs across the four waves, suggesting more than one attacker may be involved," while declining to attribute the activity .

Laundering behaviour so far looks exploratory rather than professional: a single 64.9 BTC deposit to Wasabi and 200 ETH sent to Tornado Cash on 4 August, a pattern TRM reads as inconsistent with organised groups such as the North Korea-linked TraderTraitor cluster . That matters for recovery odds: coins still sitting in identified attacker addresses are traceable, and exchanges have a target to freeze against if any of it moves to a regulated venue.

One caveat applies to every number above. Coinkite's own advisory declines to publish a confirmed stolen-BTC total and states that its investigation remains ongoing, meaning the company had not formally confirmed a direct causal link between the drains and the entropy defect at the time of reporting . Third-party forensics point strongly at the seed-generation path, but the gap between vendor confirmation and analyst inference is a real one — and it is also why opportunistic smaller thefts during the same window may or may not belong in these totals.

Why a Firmware Update Alone Doesn't Save Your Coins

Installing patched Coldcard firmware protects only seeds created after the update — it cannot repair a recovery phrase that was already generated with degraded entropy. Coinkite states this directly in its advisory and repeats it on the firmware upgrade page: the fix changes the seed-generation path going forward, and a weak seed stays weak forever . Anyone who created a seed on a Coldcard between March 2021 and the July 2026 patch needs a brand-new recovery phrase generated on fixed firmware, plus a full migration of funds to addresses derived from it.

The reason is arithmetic rather than policy. The entropy deficit was baked in at the moment of creation — Coinkite puts Mk3 seeds from firmware 4.0.1 through 4.1.9 at roughly 40 bits, and Mk4/Mk5/Q seeds at as low as ~72 bits against a 128-bit design target . New firmware cannot retroactively add randomness to a key that has already been derived, published as addresses, and in many cases already used on-chain.

Exposure therefore tracks the firmware version that was active when the secret was generated, not who owns the device today or what firmware it runs now. That widens the blast radius beyond the obvious case of a wallet still sitting on the original Coldcard. Anything the affected device produced from the same randomness path should be treated as suspect:

• Paper-wallet or exported private keys printed or written down from a Coldcard on vulnerable firmware.
• Seed XOR shares, where the masked components inherit the weakness of the underlying seed.
• Temporary seeds created on the device for short-term or segregated use.
• Device-generated passwords produced by the same random-number routine.
• Seeds later imported elsewhere — exporting or restoring the identical phrase into a Trezor, Ledger, mobile wallet or multisig quorum does not repair it, because the phrase itself is the defect.

Two conditions preserved seeds. The first is dice entropy: affected firmware hashed the device's own randomness together with every roll entered through Add Dice Rolls, and Coinkite treats 50 fair, independent, private rolls as contributing at least 128 bits, with 99 or more contributing roughly 256 bits — seeds meeting that bar are not considered at risk from this defect alone . The same entropy accounting appears in Coldcard's public firmware source for the dice path . The second is a strong, unique BIP-39 passphrase — the so-called 25th word — which acts as an independent barrier and makes offline reconstruction substantially harder . Even here, Coinkite still recommends migration: the passphrase raises the attacker's cost without repairing the weak seed underneath it.

The advisory's own sequencing matters as much as the decision to migrate. Coinkite prescribes updating first, generating a new seed, recording and verifying the backup, confirming a receive address on the device screen, sending a small test transaction, then moving the remainder — and cautions that "mistakes in the recovery process could cause more damage than the vulnerability itself" . Rushing a migration under alarm conditions is its own loss vector.

Self-Custody Under Fire: What Bitcoiners Are Saying

The Coldcard incident has reopened a debate the Bitcoin community thought it had settled: whether self-custody, as currently practised by retail holders, is realistically safe. The criticism is not that hardware wallets failed to stop an attacker — no attacker ever touched a device — but that a silent code-path change five years earlier defeated users who followed every published best practice. Podcaster Guy Swann described it as the worst hit in Bitcoin history to the most knowledgeable and properly secured bitcoiners, a framing that captures why this landed differently from a phishing sweep or an exchange failure.

The sharpest institutional critique came from asset managers. ARK Invest digital-asset research director Lorenzo Valente argued that consumers "have traded counterparty risk for software risk, hardware risk, supply-chain risk, phishing risk, backup risk" , a substitution he treats as under-examined rather than obviously favourable. Amicus co-founder David Lawrence put the conclusion in blunt allocation terms — "I'm safer to just buy IBIT" — and the flow data did not contradict him: US spot Bitcoin ETFs absorbed roughly $620 million in net inflows in the days following the hack, including about $102 million on 7 August within a weekly total above $750 million, before reversing to a $144.6 million net outflow day .

The most damaging objection, though, came from inside the self-custody industry. Casa CEO Nick Neuman rejected the dice-roll mitigation as a viable consumer standard — "You just can't ask people to roll dice to be secure with your self custody" — a pointed concession given that Coinkite's own advisory treats 50 private independent rolls as the bar for at least 128 bits of contributed entropy . A mitigation that only works for the small fraction of owners who used it before the flaw was known is, in practice, a design failure rather than a user failure. The corollary is that passive security — safety without ongoing vigilance — remains out of reach for most holders.

"AI-assisted code review can now find latent bugs at a speed that is outpacing even industry's most seasoned experts... if your firmware is open-source or has ever been public, assume it's already being read by attackers and defenders alike," — Rodolfo Novak (NVK), CEO, Coinkite (source: Bitcoin Magazine)

Novak apologised publicly, said the company was "heartbroken," took "full accountability for the firmware bug," and committed to supplying victims with a written incident summary specific to their loss and transaction data for police reports, insurance claims or private investigations . That accountability does not restore funds. Victim Jonathan Goodman, who lost $1.6 million, wrote that he never shared his seed, his devices never touched the internet, and everything was stored in safes: "None of it mattered" . Compounding the damage, the disclosure window itself became attack surface: holders scrambling to verify advisory instructions under time pressure are the ideal targets for impersonation of the advisory, which is why every migration instruction should be read from Coinkite's own domain rather than a link received by email or direct message.

The honest reading is that neither camp won. Self-custody removed counterparty risk and, as the on-chain response showed, let hundreds of thousands of coins be moved defensively within hours — no regulator, no withdrawal queue, no permission required. It also concentrated the entire failure domain into one vendor's build configuration. Both statements are true at once, and treating either as the whole story is how holders end up mis-sized in the next incident.

Is Bitcoin Really Moving? Reading the On-Chain Fallout Correctly

The verifiable on-chain signal from this incident is a long-term-holder migration in the low hundreds of thousands of BTC — not a systemic exodus. Checkonchain data relayed by Casa CEO Nick Neuman and reported by Decrypt put roughly 233,000 BTC moving out of wallets dormant 155 days or longer, a 1.38% decline from the recent long-term-holder supply record, with about 22,000 BTC of that landing on exchanges . That is the number to anchor on: coins leaving cold storage in the days after the 30 July advisory, most of them re-secured rather than sold.

Separate measurement frameworks produce different totals for the same week, which is why the fallout has been so easy to misread. CryptoQuant data cited by CryptoSlate counted 77,402 BTC moving out of older UTXO age bands, alongside 39,600 BTC in sub-1-BTC outputs on 31 July — the largest single day for that cohort since November 2022 — and 7,300 BTC in sub-10-BTC exchange deposits . Daily active addresses climbed from about 645,000 on 30 July to nearly one million the following day, the highest reading since 10 December 2024 . Old-UTXO-band accounting and dormancy-based long-term-holder accounting are not the same metric, and neither is interchangeable with "selling."

Two cautions apply when handling these figures:

• Dollar-denominated headline totals are unverified. A widely circulated "$15 billion self-custody exodus" framing has no attributed primary-source figure behind it as of publication. Treat it as separate from the roughly 233,000 BTC dormancy observation until Glassnode or Checkonchain publish a sourced, methodology-documented number.
• Movement is not liquidation. Only about 22,000 BTC of the migrated coins reached exchanges , and Casa reported that a meaningful share of migrating users were Ledger and Trezor holders moving to multisig — not Coldcard owners at all . Precautionary re-keying by unaffected users inflates every age-band metric without implying distress.
• Attacker holdings still sit on-chain. Galaxy's Alex Thorn noted the stolen BTC remained in attacker-controlled addresses , so a portion of the "movement" in any given band is theft flow, not holder behaviour.

Scale matters for sizing the damage against the base. Even the outer-bound theft tracking cited by Decrypt — roughly 2,000 BTC across as many as 15 attacker clusters — sits below one percent of the coins that moved defensively in the same week, and far below the total self-custodied supply. Neuman's read was that "somewhere between ~10x-100x the amount of bitcoin stolen was moved to safety as people sounded the alarm," which he called "a giant flashing neon sign showcasing the resilience that self-custody adds to the network" . Losses of this size are a firmware-vendor problem, not a repricing of the custody model.

The durable takeaway is measurement discipline. Age-band spikes, active-address surges and exchange-deposit upticks all moved together in the first week of August, and any one of them read alone supports a conclusion the others contradict. Coin days destroyed and dormancy metrics were, in effect, temporarily distorted by a security event rather than by market conviction . Traders using long-term-holder supply as a positioning input should carve out the 30 July–7 August window explicitly, or accept that their signal is measuring a wallet migration they have already priced.

What to Watch Next

The four questions that will settle this incident are all still open as of 13 August 2026: whether Coinkite formally attributes the drained addresses to the entropy defect, how many affected holders actually rotate seeds, whether an attributed on-chain migration figure ever gets published, and whether ETF flows keep absorbing displaced self-custody demand. Coinkite's advisory, last updated 1 August 2026, explicitly states the investigation is ongoing and publishes no confirmed stolen-BTC total . Until that closes, every loss figure in circulation is a forensic estimate, not a vendor-confirmed count.

Watch these four markers specifically:

• Formal attribution. No public confirmation yet ties the drained addresses exclusively to the entropy bug rather than to phishing, seed-backup compromise, or unrelated vectors. TRM Labs already noted that "transaction construction differs across the four waves, suggesting more than one attacker may be involved," and declined attribution .
• Migration compliance. The unknown that matters most for future losses is what share of the March 2021–July 2026 seed cohort actually generates a fresh phrase on fixed firmware — Mk2/Mk3 4.2.0+, Mk4/Mk5 5.6.0+, Q 1.5.0Q+ . Weak seeds left funded stay guessable indefinitely.
• An attributed migration figure. Estimates of defensive movement range from roughly 233,000 BTC out of long-term-holder wallets to 77,402 BTC across older UTXO bands . A methodology-labelled figure from an established on-chain analytics provider would resolve the gap.
• Custodial substitution. US spot Bitcoin ETFs took roughly $620 million in net inflows in the days after the hack, including about $102 million on 7 August, before reversing to a $144.6 million net outflow day . Sustained inflows would indicate a durable shift toward regulated wrappers; a fade suggests the reaction was tactical.

The concrete takeaway is narrower than the headlines. If your seed was created on a Coldcard between March 2021 and the July 2026 patch without 50-plus private dice rolls or a strong unique BIP-39 passphrase, treat it as compromised now and migrate to a new seed on patched firmware — patching alone does not repair it . Everyone else should watch the four markers above before rewriting a custody policy around a single vendor's defect.

Frequently asked questions

Is my Coldcard wallet compromised right now?

Your exposure depends on the firmware version that was running when the seed was created, not the version installed today. Coinkite's advisory identifies Mk2/Mk3 firmware 4.0.1 through 4.1.9 as the critically affected range, with entropy measured at roughly 40 bits, while Mk4, Mk5 and Q seeds made before the fixed builds may have carried about 72 bits against a 128-bit design target . To check, open the device's settings and review the firmware version and upgrade history, then compare the version active on your setup date against the affected ranges; if you cannot reconstruct that history and the wallet was created between March 2021 and the July 2026 patch, assume it falls inside the window .

Does updating my Coldcard firmware fix an existing seed?

No. Installing fixed firmware prevents weak seeds from being generated in future, but it cannot retroactively add entropy to a recovery phrase that was already created — both Coinkite's advisory and its firmware upgrade page state this explicitly . Anyone who created a seed on affected firmware must generate an entirely new recovery phrase on a patched build and move funds to addresses derived from it. Coinkite's recommended order is: update firmware, generate a new seed, record and verify the backup, confirm a receive address on the device screen, send a small test transaction, then move the remainder. The advisory also cautions against rushing, warning that "mistakes in the recovery process could cause more damage than the vulnerability itself" .

I used dice rolls or a passphrase when I set up my Coldcard — am I safe?

Both measures provide protection independent of the device's random number generator. Affected firmware hashed the device seed together with every roll entered through Add Dice Rolls, and Coinkite treats 50 fair, independent, private rolls as contributing at least 128 bits of entropy, with 99 or more contributing roughly 256 bits; seeds meeting that bar are not considered at risk from this issue alone . A strong, unique BIP-39 passphrase — the so-called 25th word — similarly makes offline reconstruction substantially harder. The qualifiers matter: rolls must be genuinely random, unobserved and entered on the device. If you rolled fewer than 50 times, reused a passphrase, or are unsure, Coinkite still recommends migrating to a fresh seed as best practice .

Are TAPSIGNER, OPENDIME or SATSCARD affected?

No. Coinkite confirms that TAPSIGNER, OPENDIME and SATSCARD are not affected by this defect because they run on a different codebase from the Coldcard seed-generation path that failed . The flaw traces to a single Coldcard firmware commit dated 1 March 2021 that switched the seed call from the STM32 hardware generator to a library route where a build-configuration fallback substituted a software pseudorandom generator seeded from public constants . That code path does not exist in the card products, so no migration is required for them on account of this incident.

Is the "$15 billion" self-custody migration figure accurate?

Treat it as unverified. No primary source reviewed at publication corroborates a $15 billion migration total, and the headline figure appears to derive from loosely aggregated wallet-movement estimates rather than a single attributed dataset. The measurable on-chain signals are narrower and better sourced: Decrypt, citing Checkonchain data relayed by Casa CEO Nick Neuman, reported roughly 233,000 BTC leaving long-term-holder wallets dormant 155 days or more, about 22,000 BTC of which went to exchanges , while CryptoSlate, citing CryptoQuant, logged 77,402 BTC moving out of older UTXO bands and daily active addresses rising from about 645,000 on 30 July to nearly one million the next day . Crucially, none of these datasets separate emergency migrations from ordinary movement or sales, and Casa noted that many migrating users were Ledger and Trezor holders adopting multisig rather than Coldcard owners. Consider the figure unresolved pending attributed analysis from Glassnode or Checkonchain.

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

Subscribe