The pitch for a hardware wallet is simple. Keep your private keys on a device that never touches the internet, and no attacker can reach them. Coldcard, made by Canadian firm Coinkite, is among the most respected products in that category, a Bitcoin-only, air-gapped device favoured by long-term holders who take custody seriously.
On July 30, roughly 1,200 of those wallets were emptied. None of the devices were touched.
An attacker swept 1,082.65 bitcoin, worth about $70 million, from 1,196 addresses in a 41-minute window, according to Galaxy Research. The initial figure reported was roughly 594 BTC from around 500 wallets. It nearly doubled within a day as investigators traced more addresses, and reports suggest drains are still ongoing.
Cold storage does two jobs. It keeps your key somewhere no hacker can reach, and it creates a key no computer can guess. The first job held perfectly. Every drained wallet sat offline and untouched while its seed was reconstructed on someone else’s machine. The second job had been quietly broken for five years.
A Macro That Was Defined but Set to Zero
The root cause is a firmware integration error introduced in Coldcard version 4.0.0 in March 2021, documented by Block’s Bitcoin engineering team.
Coldcard’s firmware deliberately defined a build constant, MICROPY_HW_ENABLE_RNG, and set it to zero. The intent was to disable MicroPython’s built-in randomness path, because Coinkite had written its own dedicated wrapper for the device’s hardware random number generator. That was a reasonable design choice.
The problem sat in a supporting cryptographic library called libngu, which checked only whether the macro existed, not whether its value was non-zero. Because the macro was defined at all, even as zero, the build was bound to MicroPython’s software fallback generator instead of the hardware one.
That fallback was initialised from the chip’s unique ID and timer registers, and collected no fresh entropy afterwards. Both inputs are non-secret. As a result, seeds that should have carried 128 bits of entropy carried roughly 40 bits on the Mk3 and about 72 bits on the Mk4, Mk5 and Q, according to Coinkite’s own estimates. Forty bits reduces the possible seed values to roughly four billion, a range a determined attacker can enumerate offline.
From there the attack requires no device access at all. Reproduce the candidate output streams, derive the addresses each seed would generate, and compare them against the public blockchain. Any match is a funded wallet with a known key.
Who Is Affected
Coinkite initially flagged only Mk3 devices before expanding the warning across its range. Current guidance covers Mk3 on firmware 4.0.1 to 4.1.9, Mk4 and Mk5 below 5.6.0, and Coldcard Q below 1.5.0Q. Reports indicate the company now considers every current model affected to some degree.
One group escaped entirely. Coldcard lets users supplement device randomness with their own dice rolls during setup, and seeds generated with 50 or more dice rolls carried genuine entropy the attacker could not reproduce. Those wallets survived untouched, which is a striking vindication of a feature many owners skipped as excessive caution.
The exposure also extends past wallet seeds. The same generator produced Coldcard’s paper wallet private keys, where the output becomes the key directly, along with seed-splitting masks, device cloning keys and Key Teleport transfers.
Coinkite shipped emergency firmware for every affected model on July 31, including Mk3 version 4.2.0. But the critical point, which the company has stressed repeatedly, is that updating firmware does not repair an existing seed. Restoring a compromised seed onto patched firmware, or onto any other wallet, carries the weakness forward. The only remedy is generating a new seed on fixed firmware and migrating funds to it.
Jan3 chief executive Samson Mow put it bluntly on X: if you’re using a Coldcard, any firmware version or model, migrate your funds immediately.
The Mistake the Attacker Made
There is one thread investigators are pulling on, and it is a careless one.
Block’s Clay Garrett said the operator used a paid account at a well-known blockchain data provider to query the source addresses during the sweeps. The provider’s internal logs matched the suspected workflow with what Garrett described as extraordinary specificity, down to the number, timing and sequence of requests.
An attacker who spent months reconstructing seeds offline then queried them through a commercial account that logs everything. Whether that leads anywhere depends on what identifying information the provider holds, but it is the kind of operational error that has ended similar cases before.
One caveat worth stating plainly: no public report has yet reconstructed a specific victim’s seed and matched it to a drained address. The attribution rests on the firmware analysis, the blockchain pattern and Coinkite’s own acknowledgment, which is substantial but not the same as a demonstrated end-to-end reproduction. Both Block and Coinkite described their initial analyses as preliminary, with Block publishing before full testing because exploitation was already under way.
What This Changes
The uncomfortable lesson is that self-custody advice has been incomplete. The industry has spent a decade telling people to get their coins off exchanges and onto hardware wallets, and that advice remains sound. But it implicitly treated key generation as a solved problem, something the device handles correctly by definition.
It isn’t. The quality of randomness at the moment a seed is created is a distinct security property from where the key is stored afterwards, and it is far harder for a user to verify. An owner can confirm their device is air-gapped. Almost nobody can confirm the entropy behind their seed, which is precisely why security firms warn that more wallets may still be drained: affected owners cannot reliably determine whether they were exposed. They have to assume they were.
That points to two practical takeaways. First, user-supplied entropy is not paranoia. The dice-roll option that saved a subset of Coldcard holders exists on multiple hardware wallets and costs a few minutes at setup. Second, open-source firmware is necessary but not sufficient. Coldcard’s code was public for five years, and the bug survived because it lived in the interaction between a build configuration and a library’s assumption, exactly the kind of flaw casual review misses.
Bitcoin traded above $64,000 through the initial sweep with little visible market impact, and has since drifted toward $62,900 amid broader macro pressure rather than anything specific to this incident. The $70 million is painful for those affected and negligible against a $1.26 trillion asset.
The reputational damage is the more lasting cost. Coldcard was a device people trusted specifically because it did one thing carefully. That trust now needs rebuilding, and every hardware wallet manufacturer should be auditing their entropy path this week.
FAQ
What actually happened?
An attacker drained 1,082.65 bitcoin, roughly $70 million, from 1,196 addresses in a 41-minute window on July 30, 2026. The attack exploited a firmware integration error introduced in Coldcard version 4.0.0 in March 2021, which caused devices to use a predictable software random number generator instead of the hardware one. Seeds carried roughly 40 bits of entropy on the Mk3 and about 72 bits on newer models, rather than the 128-bit standard, allowing the attacker to reconstruct private keys offline without ever accessing a device.
Which devices are affected and what should owners do?
Coinkite’s guidance covers Mk3 on firmware 4.0.1 to 4.1.9, Mk4 and Mk5 below 5.6.0, and Coldcard Q below 1.5.0Q, with reports suggesting the firm now considers all current models affected to some degree. Seeds generated with 50 or more user dice rolls carried genuine entropy and were not vulnerable. Emergency firmware shipped July 31, but updating alone does not fix an existing seed. Affected owners must generate an entirely new seed on patched firmware and migrate their funds to it.
Does this mean hardware wallets are unsafe?
Not broadly, but it exposes a gap in how self-custody is usually explained. Air-gapping worked exactly as intended here; every drained wallet remained offline. The failure was in key generation, a separate security property that users cannot easily verify. The practical response is to use user-supplied entropy such as dice rolls where a device offers it, and to recognise that open-source firmware alone does not guarantee correctness, as this bug survived five years of public code review.
Disclaimer: This article is for informational purposes only and does not constitute financial or security advice. Cryptocurrency investments carry significant risk. Always conduct your own research before making any investment decisions.
