COLDCARD firmware routed wallet seed generation through a deterministic software random-number generator instead of the hardware generator its code was meant to use. Seeds created on affected releases can expose the Bitcoin they control even after the device installs fixed firmware. Galaxy Research estimates that three sweep waves it suspects involved COLDCARD-generated addresses drained 1,367.05 BTC, about $88.6 million, across 4,585 addresses.
Owners of Mk2 or Mk3 devices that generated a seed on firmware 4.0.1 through 4.1.9 are in scope. So are seeds made on Mk4 or Mk5 before standard firmware 5.6.0 or Edge 6.6.0X, and on Q before standard 1.5.0Q or Edge 6.6.0QX. Coinkite has released fixes for every affected track, but its advisory is explicit: an update corrects new seed generation and cannot repair an old seed.
A zero-valued feature flag selected the wrong generator
The failure sits at the boundary between three codebases. Block’s technical analysis says COLDCARD’s production board configuration defines MICROPY_HW_ENABLE_RNG as zero because the firmware supplies a separate hardware-RNG wrapper. The libngu library checks whether that macro exists, not whether its value enables the feature.
That check lets the build succeed and binds ngu.random to MicroPython’s rng_get(). With the macro set to zero, MicroPython compiles a Yasmarang software fallback. It initializes that generator from the microcontroller’s fixed identifier and timer registers. Those values can vary, but they are device metadata and timing state rather than cryptographic entropy.
The output can look random while remaining reproducible once an attacker sufficiently constrains the device identifier, timing and earlier RNG calls. A wallet address or extended public key then acts as a test: derive a candidate seed offline, calculate its public address and compare it with the blockchain. A match yields the private keys needed to spend the funds.
Figure details
The diagram begins with a production setting where MICROPY_HW_ENABLE_RNG equals zero. Libngu checks only whether the macro is defined, so the build follows a path to MicroPython rng_get rather than COLDCARD's separate hardware RNG wrapper. MicroPython then uses the deterministic Yasmarang fallback seeded from the MCU identifier and timer state. The resulting 32-byte value is hashed into wallet seed material. The figure distinguishes this confirmed code path from the practical attack inputs that Block says still require hardware validation.
Later devices added entropy through a 32-bit opening
The consequences differ by model. Block says Mk2 and Mk3 v4 add no cryptographic secret to this path. For a fixed device identifier, timing state and call history, generation is deterministic.
Mk4, Mk5 and Q devices do read secure-element data during boot. Their code hashes that input and passes only the first four bytes to ngu.random.reseed(). The reseed function replaces one 32-bit Yasmarang state word. Block therefore describes at most 2^32 securely distinguished output streams after the fallback state and call history are fixed.
Coinkite’s advisory summarizes the newer devices differently, saying their affected seeds retain about 72 bits of entropy rather than the expected 128 bits. Block warns that correlated timing inputs should not be treated as independent cryptographic bits. Those are not equivalent assessments. Until Coinkite publishes its promised formal review and the paths receive broader empirical testing, the safe conclusion is narrower: the affected seeds do not meet their intended security boundary and the vendor says to migrate them.
Galaxy Research says it mapped the flow of funds using the transaction pattern Block identified. Its public thread calls the addresses suspected COLDCARD-generated addresses and does not independently prove that every one of the 4,585 addresses was produced on affected firmware. The $88.6 million figure remains Galaxy’s estimate of the observed sweeps. Block says active exploitation is under way, but also says it has not completed full empirical testing and does not claim that every remote attacker can immediately recover every seed.
The fix changes generation, not the secret already in use
Fixed releases are 4.2.0 or later for Mk2 and Mk3, 5.6.0 or later for standard Mk4 and Mk5, 1.5.0Q or later for standard Q, and 6.6.0X or 6.6.0QX for the corresponding Edge tracks. Edge and standard are separate tracks; an earlier Edge 6.x release is not fixed merely because its number is higher than a standard release.
Coinkite says seeds supplemented during creation with at least 50 fair, independent and private dice rolls are not at risk from this RNG issue alone. A strong, unique BIP-39 passphrase adds another independent barrier, but the vendor still recommends migration. The COLDCARD PIN is not that passphrase. TAPSIGNER, OPENDIME and SATSCARD are outside scope because they use different codebases.
Owners should identify the seed’s birth version before moving funds
Start with the seed, not the device’s current screen. Record the model, release track and firmware version that was installed when each funded seed was generated. A later update does not prove that an existing wallet is safe. Include exported seeds that now live on another wallet, because moving a seed between devices does not change its original entropy.
For an affected or uncertain seed, verify the existing written backup and wallet fingerprint before changing anything. Install the fixed release for the exact model and track, generate a new seed, record and verify its backup, and confirm a receive address on the hardware wallet’s own display. Send a small test transaction and confirm it arrived before moving the remaining balance. Keep the old backup until the full migration is confirmed.
Close the exposure only when every funded address derived from an affected seed has been inventoried, its balance and pending transactions have been reconciled, and funds have reached addresses derived from a newly generated seed on fixed firmware. If the generation version, dice-roll history or passphrase strength is uncertain, treat that uncertainty as unresolved rather than as evidence of safety.