Coldcard Hack Losses Nearly $100 Million as Root Cause Reveals a Wider Flaw

MakeCryippreferred on

Confirmed losses from the Coldcard hardware-wallet exploit have passed $100 million, with Galaxy Research reporting 1,596 BTC stolen from roughly 7,300 addresses across three confirmed waves and a potential fourth wave that could push the total higher. Independent on-chain tracking from coldcard.rip also recorded thousands of affected addresses and more than 1,400 BTC swept during the early attack window. Block’s engineering team traced the incident to a firmware macro bug dating back to March 2021 that silently redirected seed generation away from the device’s hardware random-number generator. Coinkite’s initial advisory focused on the Mk3, but later analysis showed the issue affected newer models as well, including Mk4, Mk5, and Q devices, although confirmed theft wave has yet targeted those models.

But the loss total climbing is only half of what changed since this story broke. The more consequential shift is in scope: Coinkite’s first advisory named only the Mk3. A technical analysis from Block’s Bitcoin Engineering and Security team showed the problem reached further than that first notice suggested.

That distinction matters for anyone still deciding whether to treat their own device as exposed. It also raises a question the public reporting on this incident hasn’t directly addressed: four waves in, why has the attacker only ever drained Mk2/Mk3 wallets, leaving the newer, still-weakened Mk4, Mk5, and Q devices alone?

First covered this incident when it broke on July 30, read our initial breaking-news coverage.

Four Waves, $100 Million: How the Losses Piled Up

The first wave hit in the early hours of July 30, 2026. Chainalysis traced the pattern directly: the attacker went after the largest balances first, pulling roughly $30 million within the opening ten minutes. Within 25 minutes, close to 594 BTC, about $38 million at the time, had moved out of roughly 500 single-signature wallets.

Galaxy Research’s own transaction-fingerprinting work, tracing the same addresses independently, put the confirmed figure higher: 1,196 addresses and 1,082.65 BTC (about $70.2 million) swept in a 41-minute window, identified by matching hardcoded transaction fees and batching patterns across the drained addresses, not simply by observing that balances had dropped.

A second wave, identified August 1, pushed the running total to 1,158.66 BTC across 2,673 addresses. Galaxy Research flagged that every coin taken in the first two waves had been deposited after March 17, 2021, the exact date the vulnerable firmware first shipped, tying the theft mechanically to the firmware flaw rather than to any individual user’s mistake.

A third wave, spotted August 2, brought the confirmed total to 1,367.05 BTC across 4,585 addresses, with Galaxy explicit that this wave’s transaction pattern didn’t share a fingerprint with the first two and shouldn’t be assumed to be the same operator.

By August 3, Alex Thorn, Galaxy Research’s head of research, identified a fourth wave in progress: a sweep rate of roughly 13.8 transfers per block against a pre-incident baseline of 0.3, a nearly 45-times spike. Unlike the first three, Galaxy has deliberately kept this wave out of its confirmed headline number. No victim has yet come forward to confirm inclusion, and the firm holds only “medium-high confidence” that it’s substantially the work of one attacker. That wave, if confirmed, adds roughly 449 BTC from about 709 addresses, pushing the potential total to 2,055 BTC, or $130 million.

Thorn has since said the investigation now points to numerous different attackers exploiting the same flaw independently, rather than one operator across all four waves. As of August 4, he estimated at least 15 different attackers, and said Galaxy continues to receive victim reports that help identify new attacks and label additional attacker addresses.

Inside the Bug: A Macro Check That Silently Failed

The mechanism, once traced, is small enough to fit in one line of configuration. Coldcard’s production firmware defines a setting called MICROPY_HW_ENABLE_RNG as zero, a deliberate choice, since Coinkite built its own separate hardware random-number-generator wrapper rather than relying on MicroPython’s built-in path. The failure sits one layer down: the supporting cryptographic library, libngu, checks only whether that macro is defined, not whether its value is non-zero. Because the macro was defined, even as zero, libngu concluded a software fallback was needed and silently routed seed generation to MicroPython’s Yasmarang pseudorandom generator instead of the STM32 chip’s actual hardware RNG.

Yasmarang seeds itself from the chip’s unique identifier and internal timer state at boot, then never collects new entropy again; every output afterward is a deterministic function of that starting point. Neither value is secret: the UID is a factory-set identifier, and Block’s own analysis notes that only its first 32 bits actually participate in the fallback, meaning even a globally unique 96-bit UID doesn’t translate into 96 bits of real randomness. An attacker who can narrow down the UID and approximate boot timing can reproduce the candidate seed stream entirely offline, then check candidates against public blockchain data to confirm a match, with no physical access to the device required.

The flaw traces to a single code change on March 1, 2021; the first affected firmware, version 4.0.0, shipped March 17, 2021. It sat in Coldcard’s open-source codebase for roughly five years before this incident surfaced it. Coinkite’s own estimate puts effective entropy at about 40 bits for Mk2/Mk3 devices on the affected firmware range, and about 72 bits for Mk4, Mk5, and Q devices on their own pre-patch firmware, both well short of the 128 bits a standard 12-word BIP-39 seed is meant to carry. A separate on-chain tracker following the sweep independently puts the practical ceiling slightly differently: 73.3 bits at best, effectively zero at worst.

Coinkite’s Response: What the Fix Does and Doesn’t Do

Coinkite’s first advisory, published the evening of July 30, named only the Mk3. By the next morning, the company had shipped fixed firmware, version 4.2.0 for Mk2/Mk3, 5.6.0 for Mk4/Mk5, and 1.5.0Q for the Q, covering every affected model line. The company has been direct about what that fix actually accomplishes: it stops new, vulnerable seeds from being generated going forward. It does nothing for a seed that already exists. Anyone whose recovery phrase was generated on affected firmware needs to create an entirely new seed on patched hardware and move funds to it; reinstalling the update alone leaves existing holdings exactly as exposed as before.

Coinkite also confirmed it destroyed its remaining Coldcard inventory manufactured with the vulnerable firmware and halted shipments once the issue was confirmed, and stated plainly that Satscard, Opendime, and Tapsigner, its other hardware products, run different code and aren’t affected.

CEO Rodolfo Novak apologized publicly on July 31, saying the company took full accountability for the firmware error and that its own review process had failed to catch it before this incident forced the issue. Novak raised the possibility that the flaw was found by someone using AI tools to review Coldcard’s long-public firmware history, calling it part of “the new AI paradigm” developers now have to reckon with, though Coinkite itself has not established how the flaw was actually found. The claim carries a wrinkle: Coinkite says it ran one of the more capable AI models over its own codebase weeks before the theft, and that review didn’t catch the bug either.

562 Bitcoin, Still Sitting Untouched

Not all of the stolen Bitcoin has moved on from the attacker’s own wallets. Checking the consolidation address tied to the first wave directly against Bitcoin’s public ledger shows 562 of the roughly 594 BTC swept in that opening sweep still sitting untouched, with no further movement recorded since.

Galaxy Research reported a similar pattern across the second wave, describing the bulk of those funds as unusually static for a theft this size, a pattern the firm suggested may reflect either active reconnaissance-avoidance or a lack of a laundering path the attacker trusts at this scale. Galaxy has also said it referred roughly 600 suspected attacker-controlled addresses to federal investigators, compliance firms, and cybersecurity investigators, with no public confirmation yet of any resulting action.

Binance founder Changpeng Zhao has been tracking the sweep publicly as it unfolded, and his own commentary traces the same arc the on-chain data shows. His initial reaction to the first $38 million alert on Aug 1.

What This Means Beyond Coldcard

That comparison is worth sitting with. A software wallet provider with a broken RNG could make victims whole because it controlled the platform victims’ funds sat on. A hardware wallet maker, by design, cannot. Coinkite has been explicit that it has no way to reach users on air-gapped devices, and no way to repair a seed that already exists. The self-custody model that makes Coldcard resistant to exchange-style seizure is the same model that makes this kind of failure unfixable after the fact for anyone who doesn’t personally act. Zhao made a related point after the total climbed past $71 million:

“Hardware wallets should not be written off just because of one bug. I like OneKey wallets (disclaimer, we are an investor). Nothing is risk free. Managing risk is important.”
— @cz_binance, August 2, 2026

The danger isn’t fully behind Mk4, Mk5, and Q owners just because their wallets weren’t the ones hit across four waves so far. Every wave observed, including the still-unconfirmed fourth, has drawn exclusively from the weaker Mk2/Mk3 search space described above, per Galaxy’s own tracing of the affected firmware boundary, not from the newer models, which remain weakened but harder to crack. That distinction matters: it’s a difference in how easy the target is, not a difference in whether it’s exploitable at all. Nothing in the public technical record indicates the newer models’ search space is actually out of reach for the same reconstruction method Block described, only that the attacker has had cheaper, easier wallets to drain first, and hasn’t needed to move on yet. Treating four clean waves as proof the newer models are safe mistakes an attacker’s current priorities for a security guarantee that was never actually established.

The Two Numbers Still Unresolved: Wave 4’s Status and Coinkite’s Pending Review

Coinkite has said a formal technical post-mortem is still pending, and its own advisory continues to describe the current guidance as early analysis. Galaxy Research, meanwhile, is still deciding whether the fourth wave belongs in its confirmed count. Until both questions settle, the ones that matter most for anyone still holding funds on affected hardware are the same ones raised by the numbers themselves: whether the newer models’ search space stays untouched because it’s actually harder to reach, or simply because the attacker hasn’t needed to try it yet.

Frequently Asked Questions

Is my Coldcard affected?
It depends on the firmware version installed when your seed was first generated, not your current firmware version or purchase date. Mk2/Mk3 seeds generated on firmware 4.0.1 through 5.0.3, and Mk4/Mk5/Q seeds generated before the respective patched versions (5.6.0, 5.6.0, and 1.5.0Q), are in the affected range per Coinkite’s advisory.

Does updating my firmware fix an existing wallet?
No. Coinkite has been explicit that a firmware update only prevents new seeds from being generated insecurely; it cannot repair a seed that already exists.

What should I do if I’m affected?
Coinkite’s guidance is to generate a completely new seed on patched firmware and move funds to it, verifying every new receive address and sending a small test transaction before moving the remainder. A strong, unique BIP-39 passphrase or at least 50 to 99 independent dice rolls during seed creation substantially reduces exposure.

Am I safe if I use a multisig setup?
Largely, if not every key in your signing quorum was generated on affected Coldcard firmware. A single compromised key in a multisig arrangement still can’t move funds alone, but a quorum made up entirely of affected Coldcard-generated seeds loses that protection.