Coldcard Generated Bitcoin Seeds From a Software PRNG for Five Years: Block's 30 July 2026 Report, and Why Migration Deadlines Do Not Check Entropy
In January 1996 two Berkeley graduate students, Ian Goldberg and David Wagner, read the Netscape browser closely enough to work out how it seeded the generator behind its secure sessions. The answer was the time of day and a pair of process identifiers. The cipher was sound and the key length was respectable, and neither mattered, because the space of keys the browser could actually produce was small enough to search. Their write-up ran in Dr. Dobb's Journal under the title Randomness and the Netscape Browser, and it became the standard teaching case for a simple point: a key is only as unpredictable as the noise it came from.
Thirty years later the same failure ran for five years inside a device sold specifically to hold private keys. On 30 July 2026 Block's Bitcoin engineering and security team published Predictable RNG Fallback and 32-Bit Reseed in COLDCARD Firmware, written with independent researchers after users began reporting drained wallets. By the time the sweeps stopped in early August, blockchain analytics firms were counting losses above USD 100 million. Bitcoin's consensus rules were untouched. No quantum computer was involved. The outgoing transactions carried valid signatures, which is what an attacker who had reconstructed the derived keys would produce. Attribution has not been closed: Block's analysis stops short of full empirical confirmation, and no public reconstruction has yet tied a named victim's seed to a specific drained address.
Practical takeaway. Cryptographic migration programmes count algorithms, key lengths and certificates. The Coldcard failure sat one layer below all three, in the build configuration that decided whether a hardware noise source was running at all. A correctly performed algorithm inventory would have described those devices accurately and would still have missed it.
What Changed on 1 March 2021: a Macro Set to Zero, and a Check That Only Asked Whether It Existed
Coinkite ships its own wrapper around the STM32's hardware random number generator, so the
production configuration set MicroPython's MICROPY_HW_ENABLE_RNG macro to zero. That is
an ordinary thing to do. The macro was still defined; its value simply said "off". The supporting
library, libngu, then asked the wrong question. Block's analysis reports that it
"incorrectly checks whether that macro is defined rather than whether it is enabled", using
#ifndef, which cannot distinguish a macro set to zero from a macro that is genuinely
switched on.
The build therefore linked MicroPython's Yasmarang generator in place of the hardware source.
Yasmarang is a fast general-purpose generator with no cryptographic claim attached to it, and here it
was initialised from the chip's unique identifier exclusive-ORed with a SysTick counter value, plus
two real-time-clock registers. Those inputs are cheap to guess. Block traces the change to commit
b18723dd on 1 March 2021, shipped in firmware v4.0.0 on 17 March 2021. Nothing on the
device reported a downgrade, because from the firmware's point of view nothing had gone wrong.
This is a failure at the seam between two disciplines that rarely audit each other. Build systems treat a defined macro as a switch that exists; cryptographic code needs to know whether a physical noise source is actually feeding it. Neither side is careless. The C preprocessor has no type for "entropy available", and no compiler warning fires when a security property quietly changes category.
How the Coins Left: 1,082.65 BTC in Forty-One Minutes on 30 July 2026
The first sweep was fast. Galaxy Research mapped an attacker draining 1,196 Bitcoin addresses in forty-one minutes on 30 July, taking 1,082.65 BTC, worth around USD 70.2 million at the time, as The Hacker News reported that week. Further waves followed. TRM Labs' analysis of 5 August, The Largest Hardware Wallet Exploit of 2026, put the running total at roughly 1,816 BTC and about USD 116 million across more than 5,200 addresses. Galaxy's own later count, reported by BeInCrypto from Galaxy data through 13 August, reached 1,778.58 BTC swept from 8,680 addresses across three major waves and more than thirty additional attacker footprints, with no confirmed sweeps after 6 August.
The totals move because three things move at once: the number of waves counted, the number of addresses attributed, and the Bitcoin price used to convert. Headlines from 1, 5 and 13 August carry figures between USD 70 million and USD 130 million with no contradiction between them. The shape of the loss stays fixed. These were self-custody holders — individuals and small treasuries who had chosen a dedicated offline device precisely to avoid counterparty risk, and who got exactly the product they paid for in every respect except the one that mattered.
Where Coinkite's 1 August Advisory and Block's Report Do Not Agree About Severity
Coinkite's security advisory, updated 1 August 2026 at 14:35 EDT, sets out the affected ranges: Mk2 and Mk3 on versions 4.0.1 through 4.1.9, Mk4 and Mk5 before 5.6.0 standard or 6.6.0X Edge, and the Q before 1.5.0Q standard or 6.6.0QX Edge. On severity it says affected Mk4, Mk5 and Q seeds carry "about 72 bits of entropy rather than the expected 128 bits".
Block's numbers are worse, and both come with conditions the report states plainly. For Mk2 and Mk3
devices on the v4 line it puts the enumeration space at 2^0 — deterministic — for an attacker who
knows the device's unique identifier, the timer state at initialisation and the history of calls
made to the generator. For the Mk4, Mk5 and Q it reports roughly 2^31 average enumeration after a
successful reseed, on the same assumption of a known fallback state and call history. Block offers
no end-to-end benchmark for either. The mechanism underneath is exact either way. The reseed
implementation takes a SHA256d digest of secure-element material and unpacks four bytes of it:
n, = ustruct.unpack('I', n[0:4]). It does not accept the full digest, and it does not
initialise a cryptographic DRBG. Thirty-two bits of seed material cannot yield more than
thirty-two bits of unpredictability, whatever is done downstream.
Seventy-two bits and a space near 2^31 describe different problems, even with Block's conditions attached to the second. Seventy-two bits is out of reach for an opportunist and expensive for a state. A space near 2^31 sits inside ordinary computing reach. The distance between them is a difference in what an attack costs, and not a difference in what an owner has to do: under either figure an affected seed is already compromised and has to be replaced, which is the subject of the next section. The gap became visible because an outside team read the firmware alongside the advisory.
Why Updating the Firmware Cannot Repair a Seed That Already Exists
Coinkite published fixes across every affected track: 4.2.0 for the Mk2 and Mk3, 5.6.0 for the standard Mk4 and Mk5, 1.5.0Q for the standard Q, and 6.6.0X and 6.6.0QX for the Edge builds. The advisory then states the limit plainly: "Updating the firmware does not change or repair an existing seed." An owner has to generate a fresh seed on a patched device, verify the new backup and a receiving address, and move the funds. Restoring the original seed phrase onto a different manufacturer's wallet achieves nothing either, because the weakness is in the twelve or twenty-four words themselves.
That irreversibility is the property worth carrying out of this case. An algorithm can be swapped. A certificate can be reissued. A key that was drawn from a guessable pool was never secret, and no later correction reaches backwards to the moment it was drawn. It is the same arithmetic that governs data already sitting in an archive under classical encryption, which we set out against the BSI and FINMA calendars last week: in both cases the exposure was created in the past and the remedy only applies going forward.
What FIPS 203, 204 and 205 Measure, and Where Entropy Actually Sits
NIST published FIPS 203, 204 and 205 on 13 August 2024, and the federal migration schedule is organised around them. The Office of Management and Budget issued memorandum M-26-15, Execution of the Migration to Post-Quantum Cryptography, signed by Director Russell T. Vought on 24 June 2026. Each agency must submit a migration plan to OMB and the Office of the National Cyber Director "no later than 120 days from the date of this memorandum", which falls on 22 October 2026. Appendix B fixes the nine items that plan must contain at a minimum, among them a risk-based system prioritisation strategy, milestones for the three migration phases, a crypto-agile architecture plan, and "the methodologies and automated tools used for the cryptographic inventory". National security systems sit outside the memorandum under separate authority.
ECDSA appears in that memorandum where a reader would expect, on the list of classical algorithms to be replaced by a FIPS 203 or FIPS 204 scheme. A Coldcard inventoried on 29 July 2026 would have been described accurately and unfavourably: ECDSA and Schnorr over secp256k1, BIP-39 key derivation, quantum-vulnerable, scheduled for replacement. The inventory would have been correct about every algorithm and silent about the seeds those algorithms were using. The word "entropy" does not appear anywhere in M-26-15, and neither does SP 800-90B.
Entropy is governed somewhere else entirely. NIST SP 800-90B, published in January 2018, covers the entropy sources behind random bit generation, and the Entropy Source Validation stream inside the Cryptographic Module Validation Program tests submitted raw noise, restart samples and conditioned output before a module can reach FIPS 140-3. Hardware vendors selling into regulated markets pay for that testing. SEALSQ announced on 28 May 2026 that its QS7001 post-quantum secure element had passed SP 800-90B entropy source validation on the way to FIPS 140-3 and Common Criteria EAL5+. On 3 September 2026 the same company announced wolfSSL support for its QVault TPM, which SEALSQ says is on track to be the first shipping TPM 2.0 part implementing the post-quantum algorithms introduced in the Trusted Computing Group's v1.85 specification. wolfSSL's own page describes the part as public pre-production, so the first-shipping claim is still a roadmap position. The silicon has to prove its noise source to reach FIPS 140-3. The deployment plans that will buy that silicon are asked to prove nothing of the kind.
How Quentir Reads It
Two months of this file now point the same way. In August a claimed lattice attack on ML-KEM-class schemes was posted, contested and closed by an information-theoretic result, which we read closely on 2 September; the algorithms held under adversarial review conducted in public. In the same window a hardware wallet lost more than a hundred million dollars because a preprocessor directive asked whether a switch existed instead of whether it was on. The standards are in better condition than the systems that implement them, and the supervisory calendars are pointed almost entirely at the first of those two.
There is a second-order consequence that reaches beyond cryptography. Manufacturers of industrial and medical equipment are being told to inventory their cryptographic estate before 2030, and they will produce inventories that list algorithm names per device. A vendor whose random number generator silently degraded in a build three product generations ago can file an inventory that is accurate about algorithms and says nothing about seed quality. A post-quantum migration will usually generate fresh, scheme-specific keys, so it does not inherit the old seed automatically. The defect survives in two ways instead: where an existing seed or master key is carried across, and where the new keys are drawn through the same unverified entropy path that produced the old ones. The Coldcard case demonstrates the second failure at a scale large enough to be counted on a public ledger.
For institutions the practical distinction is between the two regimes described above: FIPS 203, 204 and 205 govern what a system computes, while SP 800-90B and its validation stream govern what a system draws from. Quentir's All-access membership exists for exactly this kind of file — the Coldcard reconstruction, the BSI and FINMA calendars, the lattice-attack read and everything else this post links to sit inside one subscription rather than being reassembled from scratch each time the story moves. A free reading list of our public analysis is open to anyone who wants to start there.
The question this case leaves is narrower than the migration debate and much easier to answer. Every plan filed with OMB by 22 October will describe the methodology an agency used to inventory its cryptography. None of the nine items Appendix B requires asks when the noise source behind that cryptography was last measured, or against what standard. Goldberg and Wagner asked that question about a browser in 1996. It has not become less useful.
Published intelligence, built to inform your own decisions. Published: 3 September 2026.
Sources: Block Bitcoin Engineering and Security, "Predictable RNG Fallback and 32-Bit Reseed in COLDCARD Firmware", 30 July 2026. Coinkite, COLDCARD security advisory, updated 1 August 2026, 14:35 EDT. TRM Labs, "The Largest Hardware Wallet Exploit of 2026: Inside the USD 116 Million Coldcard Hack", 5 August 2026. The Hacker News, "Coldcard Hardware Wallet Flaw Linked to $70 Million Bitcoin Theft in 41 Minutes", August 2026, reporting Galaxy Research. BeInCrypto, "Coldcard Losses Pass $115 Million, Galaxy Research Data Shows", on Galaxy Research data through 13 August 2026. Ian Goldberg and David Wagner, "Randomness and the Netscape Browser", Dr. Dobb's Journal, January 1996. NIST, FIPS 203, FIPS 204 and FIPS 205, 13 August 2024; NIST SP 800-90B, January 2018; Entropy Source Validation, Cryptographic Module Validation Program. Office of Management and Budget, Memorandum M-26-15, "Execution of the Migration to Post-Quantum Cryptography", 24 June 2026, including Appendix B; summarised by HSToday, "OMB Issues Federal Roadmap for Post-Quantum Cryptography Migration". SEALSQ, QS7001 SP 800-90B entropy source validation, 28 May 2026, and SEALSQ, "SEALSQ Announces wolfTPM Support for its Post-Quantum TPM Technology", 3 September 2026; the public pre-production status is stated on wolfSSL's wolfTPM QVault page. Public pages checked 3 September 2026.
Published intelligence, built to inform your own decisions. Published: September 3, 2026.