Weak Entropy in Coldcard Firmware: Root-Cause Analysis and On-Chain Loss Reconciliation

Abstract. Between 30 July and 7 August 2026, at least 1,719 BTC (about US$111 million) was swept from Bitcoin addresses whose seeds had been generated on Coldcard hardware wallets. No device was stolen, no PIN was guessed, and no user was phished. The cause was a build-configuration error shipped in Coldcard firmware 4.0.1 on 17 March 2021, which silently bound seed generation to MicroPython's deterministic Yasmarang PRNG instead of the STM32 hardware random number generator, reducing effective seed entropy from a designed 128 bits to roughly 40 bits on Mk2/Mk3 and roughly 72 bits on Mk4, Mk5 and Q. This paper reconstructs the root cause from vendor and third-party disclosures, reconciles the divergent loss estimates published by Galaxy Research, TRM Labs and the trade press, quantifies the exposure surface, and situates the incident within a fifteen-year pattern of entropy failures in cryptocurrency software. Two findings are load-bearing: the published totals disagree by roughly 30 per cent and no single headline number is defensible on its own, and the incident is not closed — exploitation was continuing at the time of writing, and no firmware update can repair a seed that already exists.

Key findings

1. The root cause is a build-configuration error, not a break in Bitcoin's cryptography. BIP-39, secp256k1 and the device's secure element all behaved exactly as designed. The defect sat one layer below them: in which random number generator ended up linked into the shipped binary.
2. Effective seed entropy fell to roughly 40 bits (Mk2/Mk3) and 72 bits (Mk4/Mk5/Q) against a 128-bit design target. Block's analysis placed the ceilings below 2^40.7 and 2^73.3 respectively.
3. Published loss estimates disagree by about 30 per cent, spanning 1,596–2,055 BTC. Galaxy Research's confirmed figure on 7 August was 1,719 BTC (~$111 million); TRM Labs put it at 1,816 BTC (~$116 million). The defensible statement is a range, not a headline.
4. The exposure window is five years and four months — 17 March 2021 to 31 July 2026. Any seed generated on affected firmware in that window without at least 50 private dice rolls should be treated as compromised.
5. Patching does not remediate. The fix protects future seed generation only. Migration of funds to a freshly generated seed is the sole remedy, and it is a manual, per-user action.
6. Exploitation preceded disclosure by roughly 30 hours and remains ongoing. Galaxy Research now attributes the pattern to multiple independent actors rather than one operator, which changes the risk profile for any wallet still unmigrated.
7. This is the fourth publicly documented mass entropy failure in fifteen years. Android's SecureRandom (2013), Profanity (2022), Randstorm and Milk Sad (2023) and now Coldcard share a failure signature. The class is systemic, not vendor-specific.

1. Background: why entropy is the whole game

A Bitcoin wallet is a number. A 12-word BIP-39 seed encodes 128 bits of randomness, and every private key, public key and address in the wallet is derived deterministically from it. Nothing else about the wallet is secret. The PIN, the secure element, the air gap and the tamper-evident bag all protect the seed after it exists; none of them protect the moment it is created. If that moment produces a number an attacker can guess, every other defence is decoration.

Entropy is simply the count of numbers the attacker has to try. At 128 bits the search space is 2¹²⁸ — a figure with 39 digits, beyond the reach of any conceivable machine. At 40 bits it is 2⁴⁰, about 1.1 trillion candidates. That is not a theoretical reduction; it is a weekend's work.

The attack itself is embarrassingly parallel and requires no interaction with the victim. An attacker enumerates the reduced seed space, derives the standard BIP-32/44/49/84 address paths for each candidate, and checks the resulting addresses against the set of funded addresses in the UTXO set — a set that is public, downloadable and only a few hundred million entries long. Each candidate costs a handful of hash and elliptic-curve operations. On rented GPUs, a 2⁴⁰ sweep runs in minutes to hours for a few thousand dollars. Crucially the attacker never touches the device, the network or the user; the first any victim learns of it is a spend they did not authorise.

A 2⁷² space is roughly four billion times larger and is not casually brute-forceable. Whether the 72-bit tier was actually cracked, or whether the losses come overwhelmingly from the 40-bit tier, is one of the significant open questions of this incident (§8).

2. Root cause

2.1 One macro, two functions, no error

Coldcard's firmware runs on MicroPython. Two functions were available to produce random bytes with the same signature: the hardware-backed implementation Coinkite maintains in its libngu cryptographic library, which reads the STM32's true random number generator, and MicroPython's own software fallback.

Coinkite's build configuration set the macro MICROPY_HW_ENABLE_RNG to 0, intending to disable the software path entirely. The guard around that path tested whether the macro was defined (#ifndef) rather than what its value was. A macro defined as zero is still defined, so the guard passed and the software generator was compiled in. Because the two functions shared a signature, the linker bound the weak one. There was no compiler error, no warning, no runtime exception, and nothing observable in the device's behaviour.

2.2 What the fallback actually was

The fallback is MicroPython's Yasmarang pseudo-random generator. Its weakness here is not the algorithm but its seeding: it was initialised once from the chip's unique device identifier and timer register state, and collected no fresh entropy afterwards. The device ID is fixed per unit and partly structured; the timer state at boot has far less variability than it appears. The generator then produced a long, statistically well-behaved stream from a very small starting secret.

The consequence in bits:

2.3 Why five years of review did not catch it

Three properties made this defect unusually durable, and they generalise beyond Coldcard.

• It is invisible in source review. The seed-generation code reads correctly: it calls a function that is supposed to be the hardware RNG. The substitution happens in the preprocessor and the linker, for one build configuration. Reading the repository — which anyone could, the firmware is source-available — does not reveal it.
• It survives statistical testing. Yasmarang produces output that passes standard randomness test suites. Black-box testing of the device's byte stream would show nothing wrong, because the defect is in the size of the seed space, not in the distribution of the output. You cannot test your way out of a low-entropy seed by sampling its output.
• It has no user-visible symptom. A weak seed produces valid words, valid addresses, valid signatures and a backup that restores correctly. The only observable difference from a strong seed is that somebody else can also spend from it, and that only becomes visible once they do.

Coinkite's chief executive has said the attacker found the flaw with AI-assisted review of the open-source firmware, and that the company's own internal AI review had missed it. Security researchers have publicly disputed that framing. We treat both the attribution and the rebuttal as unverified claims (§8).

3. Exploitation timeline

The first sweep began at approximately 01:10 UTC on 30 July 2026 and ran for 41 minutes. Reporting published while it was still in progress recorded 594 BTC from roughly 500 addresses at the 25-minute mark; the same sweep ended at 1,082.65 BTC across 1,196 addresses. Several later accounts treat the 594 BTC and the subsequent 488 BTC as separate waves. We reproduce both framings rather than choosing between them, because the distinction materially affects wave-by-wave attribution.

Galaxy Research subsequently described more than 25 separate attack patterns across waves 1 to 3, and reported receiving over 250 victim submissions, of which only high-confidence verified cases were added to its counts. On 5 August roughly 90 per cent of the stolen bitcoin had still not moved — unusual for a theft of this size, and consistent with an actor under no pressure to launder quickly. Galaxy has reported approximately 600 addresses it believes are attacker-controlled to federal investigators and industry compliance firms, and has stated that sweep rates above one drain per block indicate the exploitation is still live.

Coinkite published its advisory on 30 July, roughly 30 hours after the first sweep began, and shipped emergency firmware on 31 July. It also halted shipments and destroyed devices in its own facilities that carried affected firmware. On 6 August it suspended its automatic customer-data deletion policy in order to preserve records for anticipated litigation, after criticism that it had emailed affected customers while stating it deleted customer data after 90 days; the company clarified that Canadian law requires eight-year record retention.

4. Reconciling the loss estimates

Headlines through the first week of August quoted $38M, $70M, $85M, $89M, $100M, $111M, $116M and $130M. These are not corrections of one another. They are different measurements, taken on different days, under different confirmation rules. Setting them side by side is the only way to read them honestly.

Four things drive the spread, and none of them is anyone getting the arithmetic wrong.

• Confirmation thresholds differ. Galaxy Research counts a loss only when a victim report or an on-chain pattern clears a high-confidence bar. TRM Labs clusters independently. The trade press aggregates both plus its own sources. Galaxy's confirmed number going down from an earlier aggregate and then up again reflects reclassification, not recovered coins.
• Address counts are not wallet counts. One victim may hold many addresses; the ~7,300 and >5,200 address figures are not comparable to each other or to a victim count, and neither maps cleanly onto BTC totals.
• The dollar figures are not comparable across dates. Bitcoin's price moved over the measurement window, so a rising USD headline does not necessarily mean more coins were taken. BTC is the only stable unit here.
• Attribution is contested. As the pattern fragmented across multiple actors, deciding which drains belong to this exploit rather than to unrelated theft became a judgement call.

Our position: the defensible statement as of 8 August 2026 is approximately 1,600 to 2,100 BTC, with 1,719 BTC confirmed. Any single headline number is a snapshot of one methodology on one date, and should be cited with both.

5. Exposure surface

Coinkite's advisory of 30 July (updated 1 August) defines the affected builds. Note that Mk2 and Mk3 carry the severe form of the defect; Mk4, Mk5 and Q carry a weaker form.

5.1 Who is not exposed

• Dice rolls. Seeds created with at least 50 fair, private dice rolls are not exposed by this bug: the user-supplied entropy was processed correctly, and 50 rolls alone contribute enough randomness. Coinkite states that 99 or more rolls yield roughly 256 bits. This is the one user-side control that empirically worked.
• Strong BIP-39 passphrase. A strong, unique passphrase creates a separate wallet that cannot be reached from the seed words alone. It is a real barrier, but it does not repair the underlying seed, and its strength is now the only thing standing between the attacker and the funds.
• Multisignature. Protects only if the quorum is not built entirely from affected devices. A 2-of-3 made from three vulnerable Coldcards is not protected.
• Imported seeds. A seed generated elsewhere and imported into a Coldcard is unaffected; the defect is in on-device generation.

5.2 What a patch cannot do

This is the point most easily missed and most expensive to miss. Updating the firmware does not repair a seed that already exists. A key derived from weak entropy is weak permanently. The fixed firmware protects the next seed you generate, and nothing else. Remediation is therefore not a software rollout — it is millions of dollars of manual, per-user fund migration, executed by people who may never see the advisory. That structural gap is why entropy incidents produce losses for years after disclosure.

6. Precedents: the same failure, five times

The Coldcard defect is not novel. It is the latest instance of a failure class with a consistent signature: secure randomness is silently replaced by something weaker, the substitution produces no visible symptom, and the damage is discovered only when funds move.

Randstorm is the closest analogue and the most instructive. In November 2023 the recovery firm Unciphered disclosed that SecureRandom() in the JSBN library — used by BitcoinJS, which powered browser wallet generation on Blockchain.info and dozens of derivative services between 2011 and 2015 — silently fell back from the browser's cryptographic generator to Math.random(), typically a 48-bit linear congruential generator seeded from the clock. Unciphered estimated around 1.4 million wallets were generated in the vulnerable window and put $1.2–2.1 billion at risk. The weakness had been publicly flagged on the bitcoin-dev mailing list as early as 2018, five years before coordinated disclosure. Those wallets are still exposed today, because the remediation problem is the same one Coldcard now faces: you cannot patch a key that has already been generated.

The difference that gives the Coldcard case its sting is the product category. Randstorm hit hot wallets improvised in browsers during Bitcoin's amateur period. Coldcard is a purpose-built, air-gapped, security-audited device sold specifically to the users who take custody most seriously. Entropy failures do not respect product categories, price points or reputations.

7. Discussion

7.1 The threat model had a hole in the shape of time zero

Hardware wallet security is conventionally argued in terms of key extraction: secure elements, PIN protection, tamper evidence, air gaps, supply-chain integrity. Every one of those defences assumes a strong key already exists. Seed generation is a single, unrepeatable, unobservable event at the start of the device's life, and it is the only point in the system where a defect cannot be mitigated after the fact. In this incident it was also the least scrutinised.

7.2 Source availability was necessary but not sufficient

Coldcard's firmware is source-available and has been reviewed for years. The defect still survived, because it does not live in the source — it lives in the relationship between a build macro, a preprocessor directive and a linker. Auditing that requires reasoning about compilation conditionals and symbol binding for the exact shipped build, which is a different discipline from reading code. The post-incident AI-assisted static analysis that reportedly surfaced 85 critical-severity findings across other wallet implementations — incorrect fallback bindings, insufficient reseeding, configuration-dependent weak paths — suggests this space has been under-examined rather than that these bugs are rare. Coordinated vendor disclosure on those findings was still in progress at the time of writing, so they should be treated as unconfirmed.

7.3 The defender's asymmetry

The attacker needed one scan of a precomputed seed space. Defenders needed every affected user to learn of the advisory, understand that updating is insufficient, generate a new seed, and move funds — before that scan. The first sweep preceded the advisory by about 30 hours, and users who were travelling, offline, or simply not following Bitcoin security channels had no chance at all. For key-generation flaws, disclosure timing is close to irrelevant to the outcome; what matters is whether the user contributed their own entropy years earlier.

7.4 What actually worked

Exactly one user-side control separated the affected from the unaffected: dice rolls. Users who added 50 or more private rolls at seed creation are not exposed, regardless of firmware version. That is an empirical result from a live incident, not a theoretical preference, and it is the strongest available argument for using user-contributed entropy whenever a device offers it.

8. Limitations and open questions

• No independent verification. We performed no chain analysis. Every total here is second-hand and attributed. Readers who need a defensible number should go to the primary tracker and cite its date.
• Which entropy tier was actually broken is unresolved. A 2⁴⁰ space is trivially searchable; 2⁷² is roughly four billion times harder and would require serious, sustained compute. No public source establishes whether the losses come overwhelmingly from Mk2/Mk3 seeds or whether the 72-bit tier was genuinely cracked. This materially changes the risk facing Mk4/Mk5/Q holders and it is, in our view, the single most important unanswered question of the incident.
• Entropy estimates are not independently reproduced. The 40-bit and 72-bit figures originate with Coinkite, with Block publishing corroborating ceilings. We are not aware of a third party publishing a reproducible methodology derived from the shipped firmware binary.
• Wave attribution is contested, as is whether the operation was one actor who later fragmented or several from early on.
• The unrealised exposure is unknown. No public estimate exists of how much bitcoin still sits on weak Coldcard seeds. The realised loss is a lower bound on the problem, not a measure of it.
• The AI claims on both sides are unverified — Coinkite's assertion that the attacker used AI to find the flaw, and the researchers' rebuttal.
• We could not locate a CVE identifier assigned to the Coldcard defect at the time of writing, which complicates tracking it in standard vulnerability databases.
• Dollar figures are date-dependent and should not be compared across the measurement window.

9. Recommendations

9.1 If you own a Coldcard

1. Assume exposure first, verify second. If the seed was generated on-device on affected firmware without 50+ dice rolls, treat the funds as at risk right now. Check the firmware version afterwards, not before acting.
2. Update, then generate a new seed, then migrate. All three steps. An updated device holding an old seed is still a compromised wallet.
3. Verify the new backup before it holds value. Confirm the backup restores, send a small test amount, confirm it, then move the rest.
4. Never restore the old seed anywhere. Not on a new device, not in software, not to "check". It is public knowledge in all but name.
5. Expect phishing. Incidents of this profile are followed by fake migration tools, fake support and fake advisories. Coinkite will never ask for your seed words.

9.2 For the wider ecosystem

1. Use user-contributed entropy wherever a device offers it. Dice rolls were the difference between loss and safety in this incident.
2. Diversify the quorum. Multisig across vendors converts one vendor's catastrophic defect into a survivable incident. Multisig within one vendor does not.
3. Audit the build, not only the source. Reproducible builds, link-map review and explicit tests that assert which RNG symbol is bound would have caught this defect in 2021.
4. Do not rely on statistical randomness tests to validate seed generation. They cannot see a small seed space behind a well-behaved PRNG.
5. Treat old wallets as live risk. If you hold coins generated in a browser between 2011 and 2015, or with Libbitcoin's bx seed, those keys are exposed today. Move them.

Frequently asked questions

Methodology and data sources

This paper is a synthesis of primary vendor disclosure and secondary on-chain reporting, compiled between 2 and 8 August 2026. Technical claims about the firmware defect derive from Coinkite's security advisory and from third-party technical write-ups of the patch; we did not compile, disassemble or test the firmware. Loss figures are reproduced as published by the organisations that produced them, with the date of measurement attached, and are never combined into a single aggregate. Where accounts conflict, both are presented (§3, §4). Claims we could not corroborate are marked as unverified (§8). Figures are current as of 8 August 2026; this document will be revised as the incident develops, and every revision is logged below.

References

1. Coinkite — Coldcard Security Advisory (30 Jul 2026, updated 1 Aug 2026) — https://blog.coinkite.com/coldcard-mk3-seed-generation-warning/
2. TRM Labs — The Largest Hardware Wallet Exploit of 2026: Inside the US$116 Million Coldcard Hack — https://www.trmlabs.com/resources/blog/the-largest-hardware-wallet-exploit-of-2026-inside-the-usd-116-million-coldcard-hack
3. The Crypto Times — Galaxy Research Confirms $111M Stolen Funds in Coldcard Exploit (8 Aug 2026) — https://www.cryptotimes.io/2026/08/08/galaxy-research-confirms-111m-stolen-funds-in-coldcard-exploit/
4. The Crypto Times — Coldcard Hack Losses Hit $100M With 1,596 BTC Stolen (4 Aug 2026) — https://www.cryptotimes.io/2026/08/04/coldcard-hack-losses-hit-100m-with-1596-btc-stolen/
5. crypto.news — Coldcard hack: how a build flag drained $116M in bitcoin — https://crypto.news/coldcard-hack-bitcoin-self-custody-entropy/
6. crypto.news — Coldcard's RNG flaw is still draining wallets, and an AI audit just found 85 more critical bugs — https://crypto.news/coldcard-rng-flaw-bitcoin-wallet-ai-audit/
7. The Hacker News — Coldcard Hardware Wallet Flaw Linked to $70 Million Bitcoin Theft in 41 Minutes — https://thehackernews.com/2026/08/coldcard-hardware-wallet-flaw-linked-to.html
8. Privacy Guides — Nearly 1,400 Bitcoin Hacked from Coldcard Wallets (3 Aug 2026) — https://www.privacyguides.org/news/2026/08/03/nearly-1400-bitcoin-hacked-from-coldcard-wallets/
9. Decrypt — Coldcard Bitcoin Exploit Explained: Entropy, How Keys Are Generated, and Why Bits Matter — https://decrypt.co/374916/coldcard-bitcoin-exploit-explained-entropy-keys-bits
10. Galaxy Research (@glxyresearch) — ongoing on-chain tracking of the exploit — https://x.com/glxyresearch
11. Unciphered — Randstorm: You Can't Patch a House of Cards (Nov 2023) — https://www.unciphered.com/disclosure-of-vulnerable-bitcoin-wallet-library-2/
12. Milk Sad — CVE-2023-39910, Libbitcoin Explorer bx seed disclosure — https://milksad.info/disclosure.html

Revision history

Disclaimer. This research is published for information and education. It is not financial, legal or security advice, and it is not a substitute for the vendor's own guidance. If you own a Coldcard, follow Coinkite's official instructions.