Notice: Informational analysis; does not constitute financial or operational security advice. Data consulted on August 4, 2026. Figures for stolen funds are sourced from Galaxy Research via specialized press and remain open: the attack was ongoing at the time of publication. Technical details of the flaw are sourced from the report published by the manufacturer. Computational cost estimates in this article are internal calculations based on stated assumptions, not measurements. CleanSky does not receive commissions or referral payments from Coinkite or any wallet manufacturer.
A build configuration error introduced in March 2021 left seeds generated by Coldcard wallets with 40 bits of effective entropy on Mk2 and Mk3 models, and approximately 72 bits on Mk4, Mk5, and Q models, instead of the intended 128. On July 30, 2026, the same day the flaw was made public, someone swept 1,083 Bitcoin from 1,196 addresses in 41 minutes. Five days later, Galaxy Research counts up to 2,055 Bitcoin under suspicion —about $130 million—, more than 7,700 affected addresses, and at least fifteen independent attackers working in parallel. The corrected firmware was released on July 31 and does not recover a single satoshi. This article breaks down the math separating 40 bits from 72, explains why the patch cannot help those already exposed, and points to the specific reason why five years of open and audited firmware failed to detect anything.
What exactly failed in the Coldcard firmware?
The secure element —the isolated chip that guards the keys— includes a hardware random number generator (RNG), a circuit that extracts unpredictable bits from physical noise. MicroPython, the interpreter on which the firmware runs, also includes a software-based pseudo-random generator. When integrating a new cryptographic library in March 2021, the developer set the MICROPY_HW_ENABLE_RNG macro to zero, expecting to disable both implementations. The compilation condition checking it —the guard— was written as #ifndef —"if the macro is not defined"— instead of checking if its value was non-zero. The macro was defined, it was zero, and the guard allowed the software substitute to compile anyway. From that moment on, seed generation requested randomness from the physical chip and was silently served by a deterministic algorithm. The substitute had existed in MicroPython since May 2018 without fault —it is a legitimate component for boards without cryptographic hardware; what changed in 2021 was that it entered the seed path of a device that did have that hardware and was sold specifically for having it.
The technical term is entropy: the measure of how many different starting points the process can have, expressed in bits. One hundred twenty-eight bits describe about 3.4 × 1038 possible starting points. Forty bits describe 1.1 × 1012. On paper, 40 versus 128 looks like a factor of three; in search spaces, they are separated by a factor of 288, a twenty-seven-digit figure. This detail explains the silence of five years and four months: a pseudo-random generator with 40 bits of internal state passes every existing statistical test for randomness. Its output is indistinguishable from that of a physical chip for any test of uniformity, correlation, or compressibility. The only thing small is the set of starting seeds. The audited cryptographic code was correct and the algorithm had no defects. The binary compiled since March 2021 simply never called it.
Why are 40-bit seeds being emptied while 72-bit seeds are not?
The two levels of entropy represent two computational cost problems separated by a factor of about four billion, nearly ten orders of magnitude. Testing a candidate costs significantly more than a hash. The attacker traverses the possible states of the generator, and for each one, must derive the seed, pass it through the key stretching function defined by the BIP-39 standard —PBKDF2 with HMAC-SHA-512 and 2,048 iterations, i.e., about 4,096 SHA-512 compressions—, derive the BIP-32 key tree, generate the first addresses, and check them against the set of addresses with balances. The expensive, non-parallelizable operation within each candidate is the stretching: it exists precisely to make this type of search costly.
Using a current high-end graphics card, capable of approximately 3 billion SHA-512 compressions per second, yields about 730,000 candidates per second per card. The math looks like this.
| Entropy Level | Models | Candidates to Traverse | One GPU | Fleet of 500 GPUs |
|---|---|---|---|---|
| 40 bits | Mk2, Mk3 | 1.1 × 1012 | ~17 days | less than 1 hour |
| 72 bits | Mk4, Mk5, Q | 4.7 × 1021 | ~204 million years | ~408,000 years |
| 128 bits (intended) | all, after patch | 3.4 × 1038 | beyond any physical scale | beyond any physical scale |
The 40 bits explain the 41-minute sweep: the expensive part of the work —traversing the space and building the derived key table— is done once, offline, and can take days or weeks; the subsequent spending from the addresses is immediate. The 72 bits of the Mk4, Mk5, and Q, under the same assumptions, remain beyond the reach of any actor conceivable today, including a nation-state: not even a million dedicated graphics cards would bring the figure down from the scale of a century.
This calculation assumes that the 72 residual bits are independent and uniform —originating from the entropy that the device's two secure elements, SE1 and SE2, add on their own— and that no side-channel data reduces the search space. If side-channel data were to narrow down the seed creation date, the effective space would drop, and the math would change completely. There is no public evidence of this occurring, but it is the only door through which the second level would enter the range of action.
This puts into context the most cited statement since July 31. Alex Thorn, Head of Research at Galaxy, maintains that every single-signature address (non-multisig) created after the March 2021 flaw will eventually be emptied, and that it is only a matter of time. Arithmetic supports this statement without reservation for the 40-bit level. For the 72-bit level, it is not supported by known technology unless the independence assumption is broken. This distinction determines whether an owner must act today or can plan an orderly migration this week.
How much has been stolen from Coldcards and why does every outlet give a different figure?
Between July 31 and August 4, five main figures have circulated, ranging from $38 million to $130 million. They do not contradict each other: they capture different moments of an open counter and, furthermore, mix two variables in a single headline.
| Date | Source | Bitcoin | Dollars | Declared Perimeter |
|---|---|---|---|---|
| Jul 31, 2026 | CoinDesk | — | 38 million | First count after disclosure |
| Aug 1, 2026 | CoinDesk / Galaxy | 1,083 | 70.2 million | First wave: 1,196 addresses in 41 minutes |
| Aug 2, 2026 | CoinDesk / Galaxy | 1,367 | ~89 million | Three waves, 4,585 addresses |
| Aug 3, 2026 | Fortune | — | 116 million | No address breakdown |
| Aug 4, 2026 | Galaxy Research | 1,596 confirmed / 2,055 under suspicion | ~100 / ~130 million | ≈7,300 confirmed addresses (>7,700 including those under suspicion), ≥15 attackers |
The gap between confirmed and suspected amounts —459 Bitcoin, more than a quarter of the confirmed total— is an attribution problem. Attributing a sweep to this flaw requires proving that the emptied address belongs to the cohort of weak seeds, which is done using on-chain clustering heuristics. When the emptying is massive, simultaneous, and follows the wave pattern, attribution is solid. When it is an isolated movement from an old address, it fits just as well with an owner moving their funds as a precaution after reading the news. The counter for addresses under suspicion includes, by definition, both victims and people securing their funds.
Dollar headlines also move independently: the implicit conversions in published figures range from about $65,100 per Bitcoin on August 2 to about $62,700 on August 4. Part of the headline variation is explained without a single additional satoshi being stolen, and part of the actual theft is masked by the price drop. To measure the real damage, one must read the series in Bitcoin: 1,083, 1,367, and 1,596 confirmed.
Why does updating the firmware not recover a single Bitcoin?
The manufacturer, Coinkite, says it bluntly in its July 31 notice: updating the firmware does not change or repair an existing seed. This sentence is the core of the case. In conventional software, a patch closes the window. The flaw lives in the code, the code is replaced, and the problem disappears for everyone at once, without the user needing to understand anything. A flaw in key generation breaks that model: what is compromised is not the program, but a number the program produced years ago that has since lived beyond its reach. It is engraved on a steel plate inside a safe or distributed in shares of a recovery scheme. The patch does not reach that object. It only reaches the device, and only for seeds created from now on.
Underneath lies an irony that contradicts the sales pitch of the entire category. The property for which a hardware wallet is purchased is that the key never touches a network: it is generated inside and stays inside. That same property prevents it from being corrected. A cloud service that discovers a key generation flaw rotates everyone's keys overnight, without asking. A wallet manufacturer has no channel to a device stored in a drawer: its only way to contact the owner is through the press. The isolation paid for as a defense is what turns remediation into a manual, slow, and necessarily incomplete process.
It is the extreme form of the gap between detection and patching: the patch exists, it is free, it was released the day after disclosure, and it does nothing to reduce the exposure of the installed base. The promise of self-custody was always the full responsibility of the owner. This episode teaches the other half of that deal: the responsibility to fix it as well.
What does this case add to the known risks of self-custody?
The list of self-custody limits has been written over years, and on this blog, we have built it piece by piece: holding the keys does not prevent signing a malicious authorization —the user who lost about $282 million from cold storage proved this in the analysis of token approvals—, nor does it cover funds deposited in a compromised bridge, as in the $577 million theft from Drift and Kelp, nor does it reach the centralized infrastructure supporting protocols advertised as decentralized. All these limits share a structure: the user acts, and the flaw enters through the door they opened. Hence, standard advice is always behavioral —don't sign what you don't understand, don't type the seed, don't photograph it.
This case does not have that structure. The victims signed nothing, did not expose the seed, did not enter it into any website, and did not remove it from the device. They did exactly what self-custody doctrine prescribes, and the key was born compromised, five years before anyone knew. No amount of user discipline would have changed the outcome, because the failure occurred upstream, in the manufacturer's build chain, before the device even left the factory.
With one exception that closes the circle, and it is the only part in the user's hands. The only practice that saved funds is the one usually described as excessive: providing fifty dice rolls during seed creation. Those who did so retain their 128 bits, because that entropy was provided by them and not the defective generator. It is the only stage of the process where the user does not inherit the manufacturer's supply chain. The rest of the fleet —those who trusted the generator, which is exactly what the device promises— today depends on how many bits they were dealt based on their model.
Who is sweeping the Coldcards and why does that prolong the danger?
The initial coordinated sweep has fragmented: Galaxy identified three waves without being able to determine if the same author was behind them and, as of August 4, counts at least fifteen independent actors. Thorn describes it as an open scrum of autonomous actors and copycats.
The shape of the waves speaks for itself. The first took ,1083 Bitcoin from 1,196 addresses: nearly one Bitcoin per address. The third took 208 Bitcoin from 1,912 addresses: one-tenth as much per address. Large balances were exhausted in the first minutes, and what remains is the long tail. Once the search space has been traversed, the marginal cost of emptying one more address is practically zero. The expensive investment is already amortized, and the list of derived keys is a reusable asset. This explains why copycats are joining rather than the phenomenon fading, and it is consistent with the list circulating.
Anyone with a large balance on a 40-bit seed had no chance: it was taken before the public notice existed. Anyone with a small balance still has time, but they are also the least likely to have heard the news and the most likely to have had the device in a drawer for years precisely because they were told that was the safe thing to do. As long as unmigrated addresses remain and the amortized list stays in the hands of fifteen or more actors, each day adds new thefts.
Did an artificial intelligence find the flaw?
Rumors are circulating strongly, and it is worth separating what was said from what was published. What is on record is a statement from Coldcard co-founder NVK, warning that LLM-assisted code review today finds latent flaws at a speed that surpasses the most veteran specialists. It is a warning about the state of the craft, formulated as a diagnosis of the present and directed at other developers. Several media outlets have turned it into a headline attributing this specific attack to an AI. No technical evidence has been published to support that attribution, and without public forensic analysis, the claim is unverifiable: to date, no firm has publicly attributed a crypto exploit to an AI agent.
The question remains worth asking for a reason of sequence. The flaw sat for five years and four months in open-source firmware, reviewed by a community that audits every line of cryptography with a magnifying glass, and no one published anything. The first documented actor to find it was the one who used it: the sweep began at 01:10 UTC on July 30, in blocks 960,183 to 960,191, and the manufacturer's first public notice arrived at 22:50 UTC that same day, nearly twenty-one hours later. This chronology —discovery and exploitation ahead of disclosure, after half a decade of silence— is what fuels the speculation, with or without proof.
What should a Coldcard owner do today?
The condition determining exposure is the firmware version with which the seed was generated, not the one currently on the device.
| Model | Affected Seeds | Corrected Version | Situation According to Math |
|---|---|---|---|
| Mk2, Mk3 (Standard) | Firmware 4.0.1 to 4.1.9 inclusive | 4.2.0 | 40 bits: sweep in progress, immediate migration |
| Mk4, Mk5 (Standard) | Generated before 5.6.0 | 5.6.0 or later | 72 bits: out of reach today, planned migration |
| Mk4, Mk5 (Edge) | Generated before 6.6.0X | 6.6.0X | 72 bits: out of reach today, planned migration |
| Q (Standard) | Generated before 1.5.0Q | 1.5.0Q or later | 72 bits: out of reach today, planned migration |
| Q (Edge) | Generated before 6.6.0QX | 6.6.0QX | 72 bits: out of reach today, planned migration |
The procedure indicated by the manufacturer consists of two non-interchangeable steps:
- Update the firmware to the corrected version for the model.
- Generate a completely new seed and move the funds to it.
Skipping the second step leaves the money exactly where it was. Two specific cases are exempt from the problem. First, those who provided at least fifty rolls with an unrigged die, independent and never recorded during seed creation: the manufacturer estimates that between fifty and ninety-eight rolls return the full 128 bits, because that entropy was provided by the user and not the defective generator. Second, those who protect funds with a strong and unique BIP-39 passphrase, with the express warning that a short, common, patterned phrase, or one taken from a quote or reused, is insufficient, and that migration is still advisable. Seeds imported from another device or created after the patch are also unaffected.
A common-sense warning about what comes next: episodes like this generate a second wave of "migration assistance" tools, exposure checkers, and supposed recovery services that ask for the seed phrase. No legitimate migration procedure requires entering an existing seed into a website or a desktop application. Checking if an address is affected does not require the key; any service requesting the seed should be treated as a theft attempt.
What does this case leave for the rest of the industry?
The usual response —audit more— would not have helped: the audited code was correct and the output of the wrong generator would have passed any statistical test, because the only thing a deterministic algorithm cannot produce is more starting points than fit in its internal state. The surface being audited and the one being executed became separated, as in the Gnosis Pay fix that never reached the deployed contract.
What would have worked is a check that almost no one performs: verifying, on the binary that leaves the factory, that the call to the source of randomness actually ends up in the chip being sold. It is a matter of linking and reproducible builds, not cryptography. A runtime assertion that fails if the hardware generator symbol is not present costs a few lines and would have turned a five-year flaw into a device that fails to boot on day one. The cost of not doing so is already at $130 million and rising.
Related articles: The gap between detection and patching in crypto hacks. The silent fix of Gnosis Pay and Zodiac. Quantum computing and the lifespan of keys. Contactless payments and self-custody. Track your positions and stablecoins on-chain at CleanSky — no yield promises, just your data.