In a 25-minute sweep that ended at 21:56 ET on Thursday night, an attacker drained roughly 594 bitcoin — worth approximately $38 million at current prices — from around 500 Bitcoin wallets, all of them secured by a Coldcard hardware wallet whose firmware had been silently bypassing its own dedicated random number generator since March 2021 according to Block's Bitcoin engineering team. The devices were marketed precisely on the strength of their hardware-isolated key generation. The firmware's own build configuration had switched it off.

The theft — confirmed independently by Block's Bitcoin engineering team and by Coinkite, the Canadian manufacturer of Coldcard — targets the exact device category that security professionals and journalists, including prior TechTimes coverage, have consistently recommended as the safe alternative to software wallets compromised by similar entropy failures. The promise was hardware randomness. What users got, in practice, was a software fallback seeded from the chip's serial number and a timer register.

AnchorWatch CEO Rob Hamilton, analyzing the sweep on-chain within hours, identified 1,324 individual bitcoin outputs moved across 500 transactions in a three-block window, with 562 BTC ultimately consolidated into a single address that has not moved as of this writing. Block engineer Clay Garrett subsequently identified an additional 695 transactions with signatures matching the verified thefts, which if confirmed would link a further 488 BTC to the same exploit — putting the potential total above 1,082 BTC, or approximately $69.5 million according to Block's engineering blog.

Firmware Bug That Bypassed Hardware Randomness, Explained

The root cause is a firmware integration error documented in detail by Block's engineering team. Coldcard's firmware correctly defines a board configuration constant — MICROPY_HW_ENABLE_RNG = 0 — to disable MicroPython's built-in hardware randomness path, because Coinkite had written its own dedicated hardware random number generator (TRNG) wrapper instead. That is standard embedded systems practice.

The failure is in libngu, the cryptographic support library that Coldcard uses for random output. Its guard condition reads #ifndef MICROPY_HW_ENABLE_RNG — which tests only whether the macro exists, not whether its value is non-zero. Because the macro is defined (even though its value is zero), libngu concludes its hardware path is active and binds to MicroPython's rng_get() function. But MicroPython itself sees the value is zero and compiles the Yasmarang software fallback instead of the STM32 hardware peripheral.

The result: every call to Coldcard's random number generator routed through Yasmarang — a non-cryptographic pseudorandom algorithm — rather than the dedicated hardware chip. Yasmarang initializes its state exactly once, from three inputs: the chip's 32-bit unique identifier, the SysTick timer (a periodic down-counter with at most 80,000 possible values), and the RTC (real-time clock) registers. On the Mk3, Block's engineering analysis notes the RTC oscillator was disabled, meaning the RTC registers likely held static or near-static values on a cold boot.

Once those inputs are fixed, the generator is fully deterministic. An attacker who can characterize the timing distributions of a device they own can dramatically narrow the search space for any other device running the same firmware. The upper bound for effective entropy under this construction is approximately 40 bits — compared to the 128-bit minimum that BIP-39, the standard underlying more than 90 percent of self-custody cryptocurrency wallets, expects when generating a 12-word recovery phrase.

A further layer compounds the failure: libngu XORs the Yasmarang output with a second Yasmarang instance initialized from public hardcoded constants. XOR of two deterministic streams with known starting states produces a deterministic output. The health check that follows — rejecting adjacent repeated values — is trivially passed by any non-degenerate PRNG. The wallet-generation step then hashes the resulting bytes with SHA256d. Cryptographic hashing cannot increase the entropy of its input: if there are at most 2^40 candidate inputs, there are at most 2^40 candidate outputs.

Which Devices Are Affected — and a Partial Fix That Isn't

Coinkite's advisory scopes the confirmed exploit to Coldcard Mk2 and Mk3 devices that generated a wallet seed using firmware v4.0.0 through v5.0.3. The vulnerability entered the codebase on March 1, 2021, when a single commit changed the seed-generation call from ckcc.rng_bytes — which correctly reached the STM32 hardware peripheral — to ngu.random.bytes, which routed through the broken libngu path. Firmware v4.0.0 shipped on March 17, 2021. Every Mk2 or Mk3 wallet created using any firmware in the v4.x or v5.x range through v5.0.3 is in the confirmed vulnerable window per Coinkite's advisory.

Coinkite and Block both state that Mk4, Q, and Mk5 devices are "not affected" by the active exploit. That framing is accurate regarding the specific attack carried out Thursday night. It requires qualification, as Block's engineering analysis makes clear.

Mk4 introduced a partial fix in March 2022: at boot, it reads 32 bytes from one secure element and 8 bytes from a second, hashes the combined value, and passes the first 4 bytes — 32 bits — to a reseed() function that replaces one word of the Yasmarang state. Block's engineering analysis is explicit about what this achieves: because only four bytes reach the reseed, there are at most 2^32 securely distinguished output streams, averaging approximately 2^31 candidate trials to enumerate. The 128-bit security floor that BIP-39 assumes remains out of reach. Coinkite's own disclosure acknowledges that Mk4 and Mk5 devices on pre-patched firmware generated wallet seeds with "approximately 72 bits" of effective entropy — meaningfully better than the Mk3's 40-bit ceiling, but still roughly 56 bits below the standard.

Critically, Mk4/Q/Mk5 owners on firmware versions before the latest hotfix may hold wallets whose seed space is bounded at 2^32 possible values — a number that modern hardware can enumerate. Block's engineers describe the Mk4/Q/Mk5 situation as "a dangerous fail-open structure" and note that a catchable exception early in the boot sequence, before the reseed executes, would leave the device at its known public initial state with zero added entropy. Whether ordinary production failures hit this path "should be treated separately from the proven 32-bit successful-reseed weakness," Block writes — but it remains an unresolved question.

Coinkite also states that Tapsigner, Opendime, and Satscard products use different codebases and are not affected.

Broader Exposure: Paper Wallets, Cloning Keys, and TOTP Secrets

The same broken ngu.random path produced every value Coldcard generated for any feature that draws on the device's random number generator. Block's disclosure lists the affected functions: paper wallet private keys, seed XOR split masks, device cloning keys, USB encryption ECDH keys, Key Teleport temporary keys, Web2FA TOTP shared secrets and per-request nonces, and Secure Notes passwords.

Paper wallet exposure is particularly severe. Unlike the main BIP-39 wallet — where the RNG output is processed through multiple derivation steps before becoming a usable private key — paper wallet generation uses the RNG output directly as the secp256k1 private key, with the corresponding Bitcoin address serving as an instant validation oracle. An attacker enumerating candidate private keys can stop the moment a derived address matches a target on-chain.

Multisig arrangements composed exclusively of vulnerable devices inherit the full vulnerability. A quorum of compromised signers provides no additional security if every participating key was drawn from the same weak entropy source.

Mk3 Holders: What to Do Now

Coinkite's advisory establishes two distinct risk tiers.

If the affected wallet was used with a BIP-39 passphrase — a supplementary word or phrase entered separately from the 24-word seed — Coinkite says funds are at "minimal risk" from this vulnerability, provided the passphrase was never typed into a computer, smartphone, or website. The passphrase adds entropy that is not generated by the device's broken RNG path.

If no passphrase was used, Coinkite recommends moving funds immediately. The safest path: generate a completely new seed on a Mk4, Mk5, or any unaffected device; verify its backup and a receive address on the device screen; send a small test transaction; and only then transfer the remaining balance. Do not restore the old Mk3 seed phrase into a new wallet — the seed itself is the compromised artifact, and moving it to different software changes nothing.

For users who have only a Mk3 available: Coinkite describes an intermediate option — adding a strong, unique BIP-39 passphrase to the Mk3 before migrating — as a stopgap while sourcing a replacement device. The company also documents a dice-only seed generation path on firmware 4.1.9 that bypasses the device's RNG entirely, for holders confident enough to perform the migration manually.

Coinkite's advisory warns explicitly against rushing: "mistakes in the recovery process could cause more damage than the vulnerability itself."

How "Hardware Wallet" Security Actually Works — and Where This Breaks It

A hardware wallet's security claim rests on two distinct promises: that private keys are stored and used on a physically isolated device (so remote attackers cannot extract them over a network), and that those private keys were generated from sufficiently random entropy (so they cannot be reproduced by an attacker who never touches the device). Both promises must hold simultaneously.

The first promise remains intact: an attacker could not extract private keys from a Coldcard device over USB or Wi-Fi. What this vulnerability demonstrates is that the second promise was silently broken at the moment of wallet creation. The private keys stored on the device were never truly private — they were reproducible by anyone who could characterize the timing distributions of the Yasmarang PRNG running on the STM32 chip.

Bitcoin Core developer instagibbs independently reproduced the vulnerability on a fresh Mk3 device and confirmed the affected code path. Security researcher James O'Beirne warned that any user holding a single-key Coldcard Mk3 wallet generated between 2021 and 2023 without a passphrase, dice rolls, or multisig should treat their funds as at immediate risk.

The firmwares that contained the vulnerability were publicly available as open-source code for five years. Coinkite stated it had been unaware of the bug until the day of the sweep — prompting community observers to speculate that advanced code-review tools may have helped external parties identify the vulnerability before the manufacturer did.

Kevin Loaec, co-founder of Wizardsardine — which builds multisig Bitcoin custody tools — was among the first practitioners to publicly raise the alarm before official advisories circulated.

Bitcoin Price and Market Impact

Bitcoin was trading at approximately $64,315 as of early Friday morning ET, with little visible market reaction to the theft. The drained 562 BTC consolidated in a single on-chain address has not moved as of the time of this article's publication.

Frequently Asked Questions

Is my Coldcard hardware wallet affected by this firmware bug?

The confirmed exploit specifically targeted Coldcard Mk2 and Mk3 devices that generated a wallet seed using firmware versions 4.0.0 through 5.0.3 — a window spanning March 2021 through the final Mk3 firmware release. If your Mk3 wallet was created in that firmware range without a BIP-39 passphrase, Coinkite advises treating your funds as at immediate risk and recommends migrating to a new seed on an unaffected device. Mk4, Q, and Mk5 devices were not exploited in Thursday night's sweep — but Block's engineering analysis found that those devices also fall short of the 128-bit entropy standard because their secure-element reseed delivers at most 32 bits to the underlying generator. Coinkite's advisory states Mk4, Q, and Mk5 are "not affected based on early analysis," while Block describes the Mk4/Q/Mk5 construction as carrying a "dangerous fail-open structure" that warrants separate evaluation.

Why did a "hardware wallet" generate predictable keys if it has a dedicated hardware chip?

The device does contain a dedicated hardware random number generator — a True Random Number Generator (TRNG) on the STM32 microcontroller. The firmware correctly disabled MicroPython's built-in hardware RNG path because Coinkite wrote its own wrapper around the TRNG. The failure was in a cryptographic support library called libngu, which checked whether the relevant build macro existed rather than whether it was enabled. Because the macro was defined as zero (not undefined), libngu concluded hardware randomness was available and bound to MicroPython's random function — which, seeing the value zero, compiled a software fallback called Yasmarang instead. The hardware chip was physically present and operational. The firmware routing error simply never asked it for a number.

How can I check whether my specific Coldcard is among the affected devices?

Exposure depends on the firmware version running on the device at the moment a wallet seed was first generated — not the current firmware version, and not when the hardware was purchased. Upgrading firmware does not retroactively change or repair an existing seed. Check the firmware version that was installed when you set up the wallet. Firmware version numbers appear in the device's Settings menu; historical versions are documented at coldcard.com/downloads/all. If the version at time of wallet creation was in the 4.0.0–5.0.3 range on a Mk2 or Mk3 device, consult Coinkite's advisory at blog.coinkite.com for model-specific migration steps. If you used a BIP-39 passphrase that was never typed into any computer or online tool, Coinkite says your funds are at minimal risk from this specific vulnerability.

What does this incident mean for the broader "not your keys, not your coins" self-custody principle?

The principle remains sound in what it protects against: exchange failures, custodian bankruptcy, and asset freezes. It says nothing about whether the code that generated your keys was cryptographically sound. This incident demonstrates that self-custody security has two independent requirements — controlling your keys, and ensuring those keys were generated with genuine randomness — and that hardware wallet marketing has historically been stronger on the first than the second. A private key generated from predictable entropy is not secure regardless of how physically isolated the device holding it is. This is the third major documented failure of this class — following the 2023 Milk Sad PRNG incident and the 2026 Ill Bloom mobile wallet vulnerability — and each time the failure occurred at a point the user had no way to verify: the moment of wallet creation.