Between 01:10 and 01:56 UTC on July 30, 2026, an unknown attacker swept roughly 594 bitcoin from around 500 single-signature wallets. The coins, worth approximately $38 million at the time, were drained in under half an hour. The majority of the stolen funds were subsequently consolidated into a single address holding 562 BTC, which as of this writing has not moved.
The root cause was a firmware bug in Coinkite's Coldcard hardware wallets that had been sitting in plain sight in open-source code since March 2021. The flaw dramatically weakened the randomness used to generate seed phrases, turning what should have been an astronomically large search space into something an attacker could brute-force offline.
This is not a remote hack of the devices themselves. It is a failure in how the wallets generated their cryptographic seeds.
What the On-Chain Data Shows
The attack was methodical and fast. Rob Hamilton, CEO of AnchorWatch, tracked 1,324 spent outputs moving across 500 transactions within a three-block window. Every drained wallet was single-signature. Each held more than 0.15 BTC. Many had been dormant for years, with coins dating back to 2021.
The transactions used a consistent high fee rate, often 30 sat/vB, and left no change outputs. This pattern strongly suggests an automated tool spending precomputed keys rather than owners moving their own funds.
The initial 594 BTC figure may understate the damage. Block security engineer Clay Garrett identified an additional 695 transactions matching the same on-chain fingerprint. Those transactions moved another 488 BTC. If all are linked, the total approaches 1,082 BTC across more than 1,000 addresses in a roughly 41-minute window.
The Technical Flaw
Coldcard devices are designed to generate high-entropy BIP-39 seed phrases using a true hardware random number generator built into the STM32 microcontroller. In March 2021, during a migration of elliptic-curve operations to Bitcoin Core's libsecp256k1 library, a build-configuration error occurred.
According to Block's technical analysis, the production board configuration defined a macro called MICROPY_HW_ENABLE_RNG as zero because Coldcard intended to use a separate hardware RNG path. But the supporting library, libngu, tested only whether that macro was defined, not whether it was enabled. The result: seed generation fell back to MicroPython's non-cryptographic software pseudorandom number generator, seeded primarily from non-secret chip data like the device's unique identifier, timer registers, and system state.
For Mk3 devices running firmware 4.0.1 through the final supported release (5.0.3), effective entropy dropped to roughly 40 bits. At that level, the search space becomes computationally feasible for a determined attacker who can model the device state. Once a candidate private key is validated against a known public key or address, the funds can be swept.
Mk4, Mk5, and Q devices fared somewhat better due to partial secure-element mixing, but seeds generated before the July 31 emergency firmware still carried only about 72 bits of entropy. That remains far below the expected 128 bits.
Which Devices Are Affected
Highest risk: Seeds generated on Coldcard Mk3 running firmware 4.0.1 or later through 5.0.3.
Also affected: Seeds generated on Mk4, Mk5, or Q before the emergency fixed firmware (5.6.0+ for Mk4/Mk5; 1.5.0Q+ for Q). The impact is less severe but still serious.
Not affected by this specific bug: Seeds generated before the vulnerable firmware window; seeds that incorporated at least 50 independent dice rolls; seeds protected by a strong, unique BIP-39 passphrase; TAPSIGNER, OPENDIME, and SATSCARD (different codebases); and multisig setups that include at least one non-vulnerable key.
A critical point: exposure depends on the firmware version at the moment the seed was generated, not the current firmware or the date the device was purchased. Restoring a weak seed onto a newer device does not strengthen it. Updating firmware does not repair an already-generated weak seed. The vulnerability is baked into the seed itself.
Timeline of Events
- March 2021: Vulnerable code path introduced in firmware 4.0.0.
- March 2022: A 32-bit reseed API and Mk4 boot reseeding are added, partially mitigating the issue on newer hardware.
- 2021–July 2026: Bug remains undetected in production firmware and open-source reviews.
- Early hours of July 30, 2026: Large coordinated sweeps begin.
- Later on July 30: Victims and researchers notice; community discussion intensifies; Coinkite issues initial Mk3 advisory.
- July 31, 2026: Block publishes detailed technical analysis; Coinkite releases deeper technical backgrounder and emergency fixed firmware; on-chain mapping expands the known scope.
Coinkite's Response
Coinkite issued an official security advisory urging affected users to treat their seeds as potentially compromised and migrate carefully. The company released fixed firmware: 4.2.0+ for Mk3; 5.6.0+ for Mk4 and Mk5; 1.5.0Q+ for Q.
These updates enforce proper use of the hardware TRNG and add build-time checks. Coinkite CEO Rodolfo Novak, known in the industry as NVK, said on X that the company was "all hands on deck doing a deep dive on everything."
The company has emphasized calm, careful migration rather than panicked moves that could introduce new risks such as wrong addresses or lost backups.
Coinkite also noted something uncomfortable: the bug existed in open-source code for over five years. The company says it has to assume "someone used AI to review previous versions of our firmware" to uncover the flaw. Coinkite itself ran a leading AI model over the code weeks earlier and it did not flag the problem.
What Affected Users Should Do
First, determine if your seed is affected. Was it generated on a Coldcard Mk3 (or later model) during the vulnerable firmware window without sufficient dice rolls or a strong passphrase?
If yes, or if uncertain:
- Update to the latest fixed firmware.
- Generate an entirely new seed on the updated device.
- Back it up carefully, preferably offline on metal.
- Verify the wallet fingerprint and a receive address on the device screen.
- Send a small test transaction to the new wallet first. Confirm receipt.
- Only then move the bulk of the funds.
- Keep the old backup until the new setup is fully verified and funds are confirmed.
For extra protection, consider a strong, unique BIP-39 passphrase on the new seed, stored separately from the seed backup. Multisig is strongly recommended for significant amounts going forward.
Do not rush. Entering seed words into untrusted software, websites, or networked devices creates new attack surfaces. Verify every address on the hardware screen.
If you used 50 or more independent private dice rolls during seed generation, or if you used a strong passphrase, your risk from this specific bug is substantially lower. Coinkite's guidance indicates BIP-39 passphrased wallets face minimal risk from this particular flaw, though migration may still be prudent.
Broader Implications
This incident is a stark reminder that even highly regarded, air-gapped, open-source hardware wallets can contain subtle, long-lived flaws. The "don't trust, verify" ethos faces practical limits when complex interactions between libraries, build systems, and hardware are involved.
The possible role of AI in discovering the bug while failing to help the vendor has fueled discussion about the dual-use nature of advanced models in security research. Attackers may have found a way to weaponize code analysis tools that defenders have not yet learned to use effectively.
As of July 31, 2026, the main wave of known drains appears concentrated in the early window on July 30. But the underlying weakness remains exploitable for any seed still holding funds that was generated during the vulnerable period. Attackers or opportunistic actors with knowledge of the flaw can continue targeting addresses whose public keys or xpubs have been exposed.
The bitcoin price showed limited immediate reaction. Community trust in hardware wallets and the processes used to audit them has taken a hit. Discussions around better entropy practices, mandatory dice or multi-source randomness, improved formal verification, and the limits of open-source "many eyes" are ongoing.
The bottom line: if you generated a Coldcard seed in the vulnerable period without strong additional entropy or a passphrase, treat it as compromised and migrate carefully to a new seed generated on fixed firmware. Act with urgency but without panic. Verify everything on-device.
The exploit has already cost tens of millions of dollars. The remaining risk is real for anyone still holding funds on affected seeds.
