On July 30, an attacker systematically drained 1,196 Bitcoin addresses in just 41 minutes, absconding with 1,082.65 BTC valued at approximately $70.2 million. The sweep was not the result of a compromised exchange or a phishing campaign, but a fundamental hardware flaw in Coldcard, the Bitcoin-only hardware wallet manufactured by Canadian firm Coinkite. Galaxy Research mapped the coordinated attack and traced its origin to a firmware integration error dating back to March 2021, a flaw that silently routed seed generation to a deterministic software pseudorandom number generator (PRNG) instead of the STM32 hardware random number generator (RNG). The incident represents one of the most devastating single-exploit events in the history of self-custodied cryptocurrency storage, raising urgent questions about the trust placed in physical security devices and the complexity of their underlying code.
The One-in-41-Minute Heist: How a Firmware Flaw Unraveled Coldcard Security
The attack unfolded with surgical precision. Between 12:47 and 1:28 PM UTC on July 30, the attacker moved funds from over a thousand distinct addresses, each one created using a Coldcard hardware wallet. The speed and scale of the operation strongly suggested that the perpetrator was not guessing seeds one-by-one, but rather systematically regenerating candidate seeds offline and cross-referencing them against the public blockchain. The vulnerability that enabled this is deeply technical, but its essence is straightforward: for a specific period of firmware releases, Coldcard devices were not generating truly random seeds. They were generating predictable ones.
Block, the financial technology company formerly known as Square, traced the fault to Coldcard’s production configuration file. In that configuration, the macro MICROPY_HW_ENABLE_RNG was set to zero because Coinkite provides its own custom hardware RNG wrapper. The critical error, however, lay in how the libngu library evaluated this macro. Instead of checking whether the macro was enabled with a value of one, the library checked only whether the macro existed at all. This subtle programming oversight caused the build system to fall back to MicroPython’s Yasmarang PRNG, a software-based random number generator that is entirely deterministic. Once this fallback was triggered, the seed generation process became a matter of computation, not chance.
How MicroPython’s Yasmarang Fallback Became a Cryptographic Trap
The Yasmarang PRNG, once invoked, was initialized using only the chip’s unique ID (UID) and timer registers. Crucially, after this initialization, the system collected no fresh entropy. This means that any attacker who could determine or sufficiently constrain three variables — the device UID, the timer state at the moment of boot, and the history of prior RNG calls — could reproduce the exact output stream of random numbers. Block’s analysis confirmed that this reproduction could be performed entirely offline, without any physical access to the victim’s Coldcard device. The attacker would simply generate candidate seeds, derive their corresponding Bitcoin addresses, and compare those addresses against the public blockchain. A match would reveal a vulnerable wallet.
This was not a theoretical exploit. The July 30 attack is the practical, devastating proof that the computational cost of this brute-force approach was well within reach for a motivated actor. The attacker did not need to steal the devices; they needed only to know, or reverse-engineer, the UID range and timing parameters of vulnerable units. The scale of the sweep suggests that the attacker had access to or had compiled a substantial database of UID information, likely from firmware update logs, device registration databases, or even serial number patterns visible in shipping manifests.
Affected Models and Firmware Versions: A Staggering Exposure Window
The vulnerability spans nearly every Coldcard model and multiple firmware release tracks. Critically, the exposure depends entirely on the firmware version that was running on the device at the moment the seed was created, not the version currently installed. This distinction is essential for understanding the scope of the damage.
- Mk2 and Mk3: Coinkite officially lists Mk3 firmware versions 4.0.1 through 4.1.9 as vulnerable, with the issue fixed in version 4.2.0. However, Block’s analysis places both the Mk2 and Mk3 devices running any firmware from 4.0.0 through 4.1.9 on the vulnerable path.
- Mk4 and Mk5: Any firmware version before 5.6.0 is affected.
- Q: Any firmware version before 1.5.0Q is affected.
- Edge builds: For Mk4 and Mk5, any edge build before 6.6.0X is vulnerable. For the Q, any edge build before 6.6.0QX is vulnerable.
This profile means that seeds created over nearly a five-year period — from March 2021 to July 2026 — are potentially exposed. The total number of devices sold during this window is not public, but given Coldcard’s reputation as the gold standard for Bitcoin self-custody, the user base is substantial and includes high-value holders, security-conscious individuals, and institutional custodians.
Why Updating Firmware Does Not Fix an Already Exposed Seed
Coinkite shipped emergency firmware for every affected model and release track on July 31, 2026. This firmware patches the RNG selection logic, ensuring that future seed generation will use the hardware RNG as intended. However, the company has been explicit on a critical point: installing the updated firmware does not repair an existing seed that was generated using the flawed PRNG. The deterministic output of the Yasmarang fallback is immutable; the seed, once created, is forever tied to the predictable state that produced it. Coinkite’s official guidance is straightforward: owners who created their seed on vulnerable firmware must generate a new seed using the patched firmware and then move all their coins to the newly generated wallets.
The company further warns that restoring the old seed to updated firmware, or to any other software or hardware wallet, merely carries the weakness forward. The vulnerability is not in the device hardware, but in the mathematical entropy of the seed itself. Any wallet that imports that seed will be equally susceptible to address derivation by an attacker who knows the original UID and timing parameters.
How Entropy Became a Statistical Liability: 40 Bits vs. 128 Bits
To understand the magnitude of this failure, one must grasp the cryptographic stakes involved in seed entropy. A standard 12-word BIP-39 seed is generated from 128 bits of entropy. This number is astronomically large — far beyond the current and foreseeable computational capacity of any attacker to brute-force. The flawed Coldcard firmware, by contrast, reduced the effective entropy to a dramatically lower level.
Coinkite itself estimates that the effective entropy of seeds generated on the vulnerable Mk3 is roughly 40 bits. For the Mk4, Mk5, and Q, the estimate rises to approximately 72 bits. Block, in its technical analysis, did not provide a single practical figure. Instead, it set conditional ceilings for the candidate pool size — below 240.7 and 273.3 — and explicitly warned that these numerical values should not be interpreted as equivalent to 240-bit or 273-bit cryptographic security. Block also declined to publish any brute-force benchmark, leaving the practical cost of an attack as an exercise for the motivated reader.
The disparity between even 72 bits and 128 bits is enormous. A 72-bit key space, while not trivial, is within the realm of possibility for a well-resourced attacker using specialized hardware like FPGAs or ASICs. Combined with the fact that the UID and timer state are partially constraining variables, the actual candidate pool for any given device may have been far smaller than the theoretical maximum. The July 30 attack suggests that the attacker not only had sufficient compute power, but also had refined the candidate generation process to a point where sweeping 1,196 addresses in 41 minutes was both feasible and profitable.
A Featured Snippet Answer: What Determines the Practical Cost of This Attack?
Block states that the practical cost of recreating candidate seeds depends on four factors: the availability of UID information, the precision of boot timing data, the history of prior RNG calls on the device, and the computational cost of address derivation. The later-model Coldcards implement a reseed mechanism that increases the number of candidates, but this does not restore true cryptographic security. An attacker with a large cluster of GPUs or custom hardware can iterate through candidate pools more efficiently than the raw bit count might suggest.
The Role of the Device UID and Timer in Reconstructing Seeds
The deterministic nature of the Yasmarang fallback is the core of the exploit. When the PRNG initializes, it uses the device’s unique identifier, a 96-bit number typically stored in the STM32 microcontroller’s factory-programmed memory. This UID is not necessarily secret. It can be read from the device via USB commands, and in some operational contexts, it may be transmitted or logged during firmware updates or diagnostics. The timer state at boot provides additional bits of variation, but this timing is also potentially observable if the attacker can estimate or infer the device’s startup sequence.
The prior RNG-call history is the most variable component. Every time the device’s firmware or the MicroPython runtime requests a random number, it advances the Yasmarang state. If an attacker knows when and how many times the PRNG was called before the seed generation operation, they can advance their own simulation to match the exact state. This means that devices that were used extensively — for PIN generation, session keys, or other cryptographic operations — before creating their wallet seed may have a more complex call history, but the underlying determinism remains.
Multisig, Passphrases, and Dice Rolls: What Actually Protects Users?
In the wake of the disclosure, many Coldcard users are asking whether existing security practices offer any protection. The answer is nuanced and depends on the specific configuration.
Does a BIP-39 Passphrase Protect Against This Exploit?
A strong, unique BIP-39 passphrase creates a separate wallet that the seed words alone cannot access. This means that even if an attacker derives the 12 or 24-word seed, they would still need the passphrase to access the funds in that passphrase-protected wallet. However, the underlying seed remains compromised. Coinkite explicitly recommends replacing the seed entirely, even for users with a passphrase, because the seed itself is the root of the key hierarchy.
Are Multisig Wallets Safe?
Multisig configurations provide protection only when the quorum is not built entirely from affected devices. If a 2-of-3 multisig uses two Coldcard devices that both generated their seeds during the vulnerable firmware window, the attacker who can derive both seeds can reconstruct the quorum. If at least one signer in the quorum uses a device or software wallet that is unaffected — such as a Trezor, Ledger, or a software wallet with verified entropy — then the multisig structure may offer meaningful protection against this specific exploit.
Can Dice Rolls Save a Vulnerable Seed?
Coinkite states that a seed generated using at least 50 fair, independent, private dice rolls is not at risk from this bug alone. The reason is that dice-rolled seeds are typically generated using the user’s own entropy input, not the device’s PRNG. However, the company warns that if the number of rolls is uncertain, or if the privacy of the rolls cannot be guaranteed, users should migrate. This caveat reflects the difficulty of proving that a manual entropy source fully replaced the flawed firmware RNG.
Are Other Hardware Wallets Affected?
No. TAPSIGNER, OPENDIME, and SATSCARD use different codebases and are entirely unaffected by this specific vulnerability. The flaw is isolated to Coldcard devices running the vulnerable firmware versions. This distinction is important for users who may be consolidating or moving funds across different hardware wallet brands.
The Attacker’s Signature: A Distinct Transaction Pattern
Galaxy Research, which mapped the 1,196-address sweep, identified a specific transaction behavior that characterizes the attack. The attacker used a fee rate of 30 sat/vB and each transaction exhibited a “no-change” signature, meaning that the entire balance of the input address was spent in a single output. Galaxy noted that it found no other Bitcoin transactions in the 30 days prior to July 30 that matched this exact fee and change pattern. This does not mean that the attacker was identifiable, only that the operational fingerprint was distinctive.
Galaxy issued a critical warning about this pattern: it identifies the operator of the sweep, but it does not by itself prove theft. The company explicitly stated that a sweep using this signature “looks the same as if a coin owner chose to move coins.” This ambiguity complicates the forensic effort. It is possible that the attacker is a sophisticated entity that has executed similar operations in the past using different fee strategies, or that the operator is a single individual who deliberately varied their methods to avoid detection. As of the time of writing, no public report has successfully reconstructed a victim’s seed and matched it to a drained address, and no individual or group has claimed responsibility.
Industry Context: A Second Weak-PRNG Disaster in One Month
The Coldcard disclosure comes on the heels of another major weak-PRNG exploit. In early July, Coinspect published research on a vulnerability it named “Ill Bloom,” which identified a separate weak-PRNG flaw in older software wallets. That flaw was tied to more than $5 million drained from addresses across Bitcoin, Ethereum, Tron, Rootstock, and Polygon since May 2026. While the Coldcard incident is far larger in value and concentrated in a single asset, both exploits share a common theme: the failure of ostensibly secure systems to generate true cryptographic randomness.
The Ill Bloom research demonstrated that weak PRNGs are not a relic of early cryptocurrency software. They continue to appear in production-grade systems due to integration errors, misconfigured build flags, and inadequate testing of entropy sources. The Coldcard vulnerability is a textbook example of a configuration error that persisted for years because the fallback code path was never exercised during quality assurance. The system worked perfectly — until it didn’t.
The financial consequences are stark. In 41 minutes, the Coldcard attacker extracted more value than many mid-sized DeFi protocols hold in total value locked. The speed of the sweep suggests that the attacker had prepared the candidate generation infrastructure in advance, waiting for the right moment to execute. The methodical nature of the operation, combined with the absence of any ransom or extortion demand, strongly implies that the funds are being laundered through mixers, cross-chain bridges, or over-the-counter brokers. Recovery, in all likelihood, is impossible.
What Coldcard Users Must Do Now: A Practical Migration Guide
For any user who created their Coldcard seed during the vulnerable firmware window, the path forward is clear but laborious. The first step is to verify the firmware version that was installed at the time of seed creation. This may require checking device purchase dates, firmware update logs, or the device’s own storage if the firmware version was recorded. If there is any uncertainty, the safest assumption is that the seed is compromised.
The second step is to generate a new seed on a Coldcard device running the patched firmware. Coinkite recommends using the device’s hardware RNG, which is now correctly selected by the firmware. For users who want additional assurance, the Coldcard supports dice-roll seed generation, which completely bypasses the device RNG. A minimum of 50 fair rolls is suggested, with the caveat that the rolls must be performed in private and with physical randomness.
The third step is to move all funds from the old seed to the new seed. This involves creating a new wallet from the new seed, obtaining the receiving addresses, and then broadcasting transactions from the old wallet to those addresses. Because the old wallet addresses are potentially compromised, this migration should be performed as quickly as possible after the new seed is generated. Coinkite’s emergency firmware and guidance are available on its official blog.
For institutional custodians and high-net-worth individuals who may have dozens or hundreds of Coldcard devices, the migration process is a significant operational undertaking. It requires generating new seeds, securely transferring the new seed material to backup locations, and systematically moving funds from legacy addresses. The cost in time, fees, and logistical complexity is substantial, but the alternative is continued exposure to a deterministic exploit that has already demonstrated its effectiveness at scale.
The Coldcard hardware flaw and the $70 million heist it enabled will be studied for years as a case study in the fragility of trust in hardware security modules. The device itself was not stolen, its physical security was not bypassed, and its cryptographic primitives were not broken. The attacker exploited a single line of code that asked the wrong question about a build-time macro. That error, compounded by years of unexercised fallback code, turned the most trusted Bitcoin hardware wallet into a source of predictable seeds. The lesson for the industry is uncomfortable but unavoidable: hardware wallets are only as secure as the entropy they use to generate keys, and entropy is only as trustworthy as the software that sources it.
