Less than 24 hours after the 594 BTC theft, Coinkite publishes a security advisory and a technical review: seed generation on Coldcard Mk3 is compromised from firmware 4.0.1 (March 2021), with an estimated effective search space of about 40 bits. Mk4, Mk5 and Q also produced seeds with about 72 bits of entropy instead of 128.
The weak-entropy hypothesis, the most solid among those circulating in the hours after the 594 BTC theft whose dynamics we reconstructed yesterday, has found confirmation in the most significant place possible: Coinkite’s blog. On 30 July the company published a security advisory warning “out of an abundance of caution” all users who generated a seed on a Coldcard Mk3 running firmware 4.0.1 (March 2021) or any subsequent version: “funds may be at risk“.
The problem does not stop at the Mk3. Seeds generated on Mk4, Mk5 and Q before the corrective firmware releases – version 5.6.0 for Mk4 and Mk5, 1.5.0Q for Q – are also affected, with about 72 bits of entropy instead of the expected 128. Coinkite describes the impact on these models as “not as severe but still serious“. Tapsigner, Opendime and Satscard are not affected: they are different codebases.
The link to the 30 July theft
The advisory does not explicitly mention the previous night’s theft, but the timeline speaks for itself. At 18:10 UTC on 30 July NVK, CEO of Coinkite, publicly responded to the alarm stating that there was “no evidence of a flaw in Coldcard’s random number generator“. A few hours later, the company published an advisory describing exactly that: a flaw in entropy generation on the device.
The on-chain data collected by Atlas21 is consistent with the picture emerging from the advisory. The firmware in question dates back to March 2021; the UTXOs swept on 30 July date from 2021 to 2026. The victim who raised the first alarm on Reddit had bought a Coldcard in 2021 and generated the 24-word seed directly on the device, without it ever touching a computer.
A seed with 72 bits of entropy is not attackable by just any adversary: it is an enormous search space for an individual, but not out of reach for someone with sufficiently powerful LLMs and adequate computational resources. For the Mk3, however, the situation is far worse: the technical review estimates an effective search space of about 40 bits – a preliminary estimate, the company warns – a level that makes recomputing keys an industrial-scale operation. And the structure of yesterday’s theft, one transaction per address, is consistent precisely with keys recomputed one by one.
The technical review: the hardware generator cut out since 2021
The technical review promised in the advisory arrived shortly after: a deep dive reconstructing the origin of the bug. In 2021 Coinkite migrated the Coldcard’s elliptic-curve operations to libsecp256k1, the same implementation used by Bitcoin Core, introducing the embedded library libNgU. “The cryptographic choice was sound. The integration was not“: during that migration, seed generation moved from the function that queried the device’s hardware TRNG to a path that resolved the call to MicroPython’s software fallback PRNG, a pseudorandom generator present in the upstream code since May 2018.
The most bitter detail is the build-time cause: an #ifndef guard that checked whether the MICROPY_HW_ENABLE_RNG macro was defined, not whether its value was zero. Coinkite had defined it as zero, believing this excluded that code; the error check never fired and, since the two implementations shared the same signature, the build completed without flagging anything. The TRNG code written for the Coldcard was present in the firmware and reviews verified it, but no check followed the symbol-resolution chain all the way to seed generation: the hardware generator was being used “just by chance, and only for less important things“, the company admits. On the Mk3 the active PRNG was seeded primarily from device and timing state: hence the roughly 40 bits. During Mk4 development, values from the TRNGs of the two secure elements were also mixed into the PRNG, “a backup to a backup” that explains the roughly 72 bits on Mk4, Mk5 and Q.
On how the bug was discovered, Coinkite – which states it learned of it “only today” – offers a hypothesis: the Coldcard code has always been open source, “we have to assume that someone used AI to review previous versions of our firmware and stumbled upon this issue“. With a bitter note: a few weeks earlier the company had run a security review of its own code using one of the best available AI models, which found nothing. The bug is now the subject of independent analyses, including a technical report by Block and an attack-cost model for the different Coldcard generations.
The emergency hotfix is already available: version 5.6.0 for Mk4 and Mk5, 1.5.0Q for Q. No new features, just correct entropy generation, with an added build-time check that fails compilation if the path does not reach the hardware TRNG. The advisory’s fixed point remains: updating the firmware does not repair a seed that was already generated. A new seed must be generated and the funds migrated.
Who is safe: dice and passphrases
The advisory draws precise distinctions. The bug affects the entropy generated by the device, not the entropy added by the user.
Those who used the Add Dice Rolls function when creating the seed are safe, provided they entered enough rolls: 50 to 98 independent, private rolls contribute at least 128 bits of their own entropy, 99 or more roughly 256 bits. Below 50 rolls – or if you do not remember how many – Coinkite recommends following the migration procedure like everyone else.
The BIP-39 passphrase (not to be confused with the device PIN) constitutes an independent barrier, but only if strong: a short, common, reused passphrase, or one taken from a quotation, should not be considered sufficient protection. Even with a strong passphrase, the guidance is to migrate to a new seed as soon as practical.
