Coldcard-related Bitcoin theft has climbed to an estimated 1,367.05 BTC – around $88.6 million – after analysts identified a third distinct wave of attacks exploiting a long‑standing firmware vulnerability.
Galaxy Research updated its on-chain analysis on August 1, revising its earlier estimate of 1,082.65 BTC stolen from 1,196 addresses. The new figure encompasses 4,585 affected Bitcoin addresses spread across three coordinated sweeps. Galaxy stressed that this is an “observed” lower-bound estimate: additional compromised wallets may still be unidentified, and not every address has been definitively tied to a Coldcard-generated seed.
Three attack waves, one expanding tally
The first wave of thefts unfolded in a tight 41‑minute window early on July 30. Between 01:10:20 and 01:51:26 UTC, attackers emptied 1,196 Bitcoin addresses, capturing roughly 1,082.65 BTC. These transactions occurred in blocks 960,183 through 960,191 – about 30 hours before hardware wallet maker Coinkite publicly disclosed the issue.
A second wave followed on July 31, siphoning another 76.16 BTC from 1,478 addresses. A later review of chain data revealed a third wave in which 207.7294 BTC was drained from an additional 1,912 addresses. Combined, the three waves total 1,367.05 BTC across 4,585 known addresses, dramatically eclipsing the initial loss estimate of roughly $70.2 million.
Changing transaction patterns complicate detection
The first wave stood out due to its uniform transaction characteristics. Attackers consistently used a 30 sat/vByte fee rate and crafted transactions without change outputs – a combination that allowed analysts to cluster and trace the stolen coins relatively easily.
Galaxy warned that this kind of pattern-based attribution has limits. The later waves already diverged from the original blueprint, and future thefts might intentionally vary fees, outputs, and transaction structures to make detection and grouping of related movements much harder.
According to Galaxy, the first two waves share several technical similarities: they appear to route funds to overlapping collector addresses, use the same address types, and show comparable derivation-path behavior. The timing – roughly 27 hours apart – also hints at a single operator controlling both sweeps, though on-chain data alone cannot decisively identify who is behind them.
Third wave suggests a modified strategy
The third wave behaved noticeably differently. Rather than consolidating funds into common collection points, the attacker moved coins from each victim into separate pay‑to‑witness‑script‑hash (P2WSH) destinations. Several victim addresses were bundled into each sweep transaction, but the outputs dispersed to individual P2WSH scripts.
This wave also appears to have focused exclusively on the default derivation path for the affected wallets, in contrast with earlier behavior. Galaxy considers each wave to represent a single, internally consistent operational pattern, yet it stopped short of asserting that the same entity controlled all three campaigns. Narratives describing “one hacker” are therefore, at this stage, interpretive rather than confirmed.
The firm referred to the third cluster as “what we suspect are hacks of Coldcard-generated addresses,” reflecting both the strong circumstantial link to the firmware flaw and the inherent uncertainty in attributing addresses to specific wallet devices based solely on on-chain evidence.
How the firmware flaw weakened Coldcard seeds
At the center of the incident is a multi-year problem in Coldcard’s seed-generation process. Coinkite has explained that a series of firmware integration mistakes prevented the device’s hardware random-number generator from contributing properly to the creation of wallet seeds.
Instead, after a code change in March 2021, a MicroPython-based software fallback delivered predictable randomness in certain conditions. An independent technical review by Block’s engineers described the same failure path, concluding that active exploitation was underway in the wild.
The impact varied across device generations:
– Mk2 and Mk3 models
Coinkite estimates that affected seeds from these devices had only about 40 bits of effective search space – dramatically lower than the intended security level. In practice, this means a sufficiently resourced attacker could feasibly brute-force such seeds, especially once the weakness became publicly known.
– Mk4, Q and Mk5 models
These later devices added entropy from a secure element, improving security. Even so, Coinkite believes the effective entropy for vulnerable seeds was roughly 72 bits instead of the target 128 bits. While much harder to brute-force than 40 bits, 72 bits still falls short of the standard expectations for hardware wallets designed to secure large holdings over many years.
These entropy values remain technical estimates and may be refined as further analysis and testing continue.
Which firmware versions are affected
Coinkite’s investigation currently identifies the following at‑risk ranges:
– Coldcard Mk2 and Mk3: firmware versions 4.0.1 through 4.1.9
– Coldcard Mk4 and Mk5: seeds created before standard firmware version 5.6.0
– Coldcard Q: seeds created before firmware version 1.5.0Q
The company has also issued separate fixed firmware for Edge variants. Importantly, the vulnerability concerns the generation of *new* seeds under these versions, not the signing of transactions or display of addresses.
Firmware updates are not enough for existing seeds
Coinkite has released hotfixes for all affected models and publicly accepted “full accountability” for the bug. However, there is a fundamental limitation: once a seed phrase has been generated with insufficient entropy, no software update can retroactively strengthen it.
Updating the firmware ensures that any *future* seeds created on the device use proper randomness. It does not upgrade the security of a recovery phrase that is already in use. A vulnerable seed remains vulnerable unless it is replaced with a new, securely generated one.
Official guidance: migrate to a fresh seed
Coldcard’s advisory tells users to treat this as a seed-migration issue, not just a firmware-update task. The recommended process is:
1. Install the patched firmware on the device.
2. Generate a completely new seed under the fixed version.
3. Create and verify a backup of the new seed (for example, by carefully writing down the recovery words and confirming them).
4. Verify a receiving address derived from the new wallet, ensuring it matches expectations.
5. Send a small test transaction to the new wallet first and wait for confirmation.
6. Once confirmed, move the remaining balance from the old, potentially weak seed to the new one.
7. Keep the old backup temporarily until you are absolutely confident the migration succeeded and all funds arrived safely.
Only after verification and final reconciliation of balances is it safe to destroy the old backup.
Role of dice rolls and passphrases
Coinkite notes that seeds created with at least 50 independent, fair, and private dice rolls are, by design, not dependent on the flawed firmware RNG. In such cases, the human-generated randomness dominates, and the specific device bug is not considered sufficient on its own to compromise the seed.
A strong, unique BIP‑39 passphrase (sometimes called the 25th word) adds another layer of defense. Even if an attacker can guess or brute-force the underlying 24-word seed, they must also break the passphrase to access funds.
However, the company still urges migration, because:
– Many users did not roll dice at all or did fewer than 50 rolls.
– Passphrases are often weak, reused, or guessable (for example, common phrases, personal data, or dictionary words).
– Once an implementation flaw becomes widely known, the incentive for attackers to systematically target affected seeds increases.
Short, reused, or predictable passphrases cannot be relied upon to compensate for reduced seed entropy.
Why the exploit is so serious
A key reason this incident is so damaging is the nature of seed entropy. A properly generated 128‑bit or 256‑bit seed makes brute-force attacks computationally infeasible with any realistic hardware. When that entropy drops – from 128 bits down to 72 bits or even 40 bits – the attack surface changes from “effectively impossible” to “theoretical” or even “practically exploitable” for a determined adversary.
Once attackers understand the precise way entropy was weakened, they can:
– Narrow the search space dramatically.
– Focus attacks on specific derivation paths and address types used by the wallet.
– Use on-chain heuristics to find likely targets, such as addresses attributable to certain wallet models or behavior patterns.
This is why the known sweeps include carefully clustered addresses and repeated transaction patterns: the attacker is almost certainly using tailored software capable of testing candidate seeds at scale, then immediately draining any discovered wallets.
Lessons for hardware wallet users
The Coldcard incident underlines several broader security lessons:
– Trust but verify seed generation: When possible, use external randomness (like adequate dice rolls) in addition to the hardware RNG. This reduces reliance on any single component.
– Keep firmware updated proactively: Delayed updates can turn a latent bug into a realized loss once exploitation begins.
– Use a strong passphrase: A high-entropy, unique BIP‑39 passphrase can help mitigate some classes of compromise, though it is not a complete fix for a weak seed.
– Avoid single points of failure: If you secure very large balances, consider multi-signature setups across devices from different vendors, so that no single implementation flaw can expose all funds.
– Monitor on-chain activity: Watching for unexpected outgoing transactions and maintaining awareness of wallet-related security advisories can offer early warning.
What affected users should do now
For users who suspect they may be impacted:
– Confirm your device model and firmware history against the affected ranges.
– Assume any seed created under vulnerable firmware is at risk, unless you are absolutely certain it was generated with sufficient external randomness.
– Prioritize migration if the wallet holds significant value. The cost and effort of moving funds are small compared to the risk of complete loss.
– Harden your new setup by:
– Using the latest firmware.
– Incorporating enough dice rolls or another verifiable entropy source.
– Choosing a long, random passphrase stored securely offline.
Long-term implications for the hardware wallet industry
This case is likely to influence best practices across the entire ecosystem. Wallet manufacturers may:
– Increase transparency around how randomness is generated and tested.
– Strengthen their firmware build pipelines and review processes to catch integration errors earlier.
– Provide better user-facing tools for combining external entropy with device-generated randomness.
– Offer clearer, more proactive communication channels for disclosing security issues.
For users, the episode is a reminder that “self-custody” also means shouldering a degree of technical responsibility. High-value storage demands not only robust tools but also regular verification, informed setup decisions, and a willingness to migrate when underlying assumptions about security change.
Even as further analysis refines the precise number of coins and addresses involved, the Coldcard flaw and the three observed attack waves stand as a stark demonstration: when entropy fails at the seed level, the entire security model of a wallet can collapse – and the blockchain faithfully records the consequences.