The Seed That Wasn’t Secret
Across the accounts of the Coldcard crisis, the details vary but the scene remains much the same. A hardware wallet is sitting where its owner left it. The recovery words have not been photographed, uploaded or entered into a website. The bitcoin has remained untouched for years. Then a watch-only wallet refreshes and the balance begins to disappear.
For some, it was retirement money. For others, savings intended to give their children a better start. There was no fraud department capable of freezing the account and no bank able to reverse the transaction. By the time the owner understood what was happening, somebody else possessed the same authority over the bitcoin – and the blockchain had accepted their signature.
That is what separates this incident from the familiar exchange collapse or phishing attack. These were people who had deliberately removed their bitcoin from third-party custody. Many had chosen a specialist, Bitcoin-only device because they believed it reduced the number of institutions and systems they were required to trust.
The Coldcard was offline. The seed was not.
A secret drawn from too small a universe
At the foundation of a Bitcoin wallet is a very large number. It is secure because it should be drawn from a range so vast that guessing it is practically impossible. A hardware wallet therefore has one foundational responsibility when creating a new wallet: gather enough genuine, unpredictable randomness. Coldcard had one job and they failed to do it.
Bitcoin’s security relies on selecting truly random, enormous private keys. Properly generated, the keyspace is like finding one atom across 2 billion galaxies – impossible for classical computers to search. Affected Coldcard firmware instead used a tiny, predictable pool the size of a large virus, which a standard computer can exhaust in hours.
According to investigations by Block’s Bitcoin engineering and security teams, affected Coldcard firmware did not reliably do that. The intended hardware random-number generator existed, but the route used to generate wallet seeds resolved instead to a deterministic software fallback inside MicroPython. On affected Mk2 and Mk3 firmware, Block found no cryptographically secure entropy entering that path. Later models added secure-element material, although Block concluded that only four bytes reached the reseeding operation. Block cautioned that its report was published before full empirical exploit testing had been completed.
The result was not an obviously damaged seed. The words looked normal. The wallet produced valid addresses, received bitcoin and signed transactions. But the secret had been selected from a space that was far smaller – and potentially far more reproducible – than the owner had been led to expect.
Coinkite estimates an effective search space of about 40 bits for affected Mk2 and Mk3 wallets and about 72 bits for later devices under its current assumptions. Block’s analysis is more severe under certain fixed-state conditions. The exact practical cost of recovering any individual wallet remains dependent on device information, timing and execution history, but both accounts agree that the system fell well short of its intended security target.
The vulnerable route entered the source during a March 2021 migration. Coinkite says firmware 4.0.1 was the first publicly distributed Mk2/Mk3 release affected. Corrected firmware is now available, but updating cannot strengthen a seed already generated under the faulty implementation. A new seed must be created and the funds moved. Importing the old words into another wallet merely carries the same weakness to a different device.
Independent dice entropy or a strong, unique BIP-39 passphrase may have changed the exposure. Coinkite now says 50 fair, private dice rolls are sufficient to address this particular failure. But that is an additional precaution, not a reasonable baseline expectation for an ordinary hardware-wallet customer.
By 4 August, Galaxy Research said it had identified 1,596 BTC stolen from roughly 7,300 addresses across three confirmed waves and 14 smaller incidents. A suspected but unconfirmed fourth wave could lift the total beyond 2,000 BTC. Addresses are not the same as victims, and the figures remain estimates assembled from transaction patterns and reports supplied by affected users.
The system that kept working
The most disturbing part of the failure is that almost everything visible continued to behave as expected.
The firmware compiled. The device displayed seed words. The addresses worked. The hardware generator was present elsewhere in the codebase. Reviewers could locate it. Users could verify receive addresses and sign air-gapped transactions. Nothing on the screen announced that wallet generation had followed the wrong path.
This is a recurring danger in complex technical systems: expertise becomes concentrated on components and immediate functions while the behaviour of the completed system escapes examination.
The narrow question was whether the device produced a functioning wallet. It did.
The necessary question was whether anyone else could reproduce the secret it had produced.
The device did not fail by stopping. It failed by continuing.
Coinkite’s own technical backgrounder contains an unusually direct admission. In a first-person passage, the author says that most Coldcard randomness was coming from a pseudorandom generator inside a MicroPython submodule that they “didn’t know was actually in the source code base”. The carefully designed hardware generator, the author adds, was being used only “by chance” and for less important functions.
The admission is narrower than it first appears, but no less serious. It does not mean the author was unaware that MicroPython had been incorporated into the product. It means they did not understand that the dependency contained an active fallback generator capable of satisfying the same call expected to reach Coldcard’s hardware RNG.
The build therefore completed successfully. The wrong implementation looked sufficiently like the right one to the surrounding system.
For a device whose central purpose was to create and protect secrets, the source of its randomness had become partly accidental.
It would be inaccurate to say Coldcard had never been examined. On 4 August – after the thefts had begun and questions about its review practices were mounting—Coinkite published a new consolidated history of external research, coordinated disclosures, internal findings and professional reviews affecting the device. The company called it a “definitive record” for researchers, journalists and security teams.
The chronology records genuine security work. But the fact that this definitive public account was assembled only after a catastrophic failure is itself part of the story. Security practice is not the same thing as public disclosure, but for a company selling tools intended to minimise trust, the distinction matters. Before the crisis, customers and outside researchers had no single record showing what had been reviewed, how deeply it had been reviewed and where uncertainty remained.
A paid 2022 review examined Mk4 random-number generation and led to secure-element entropy being added. Coinkite now acknowledges that earlier review established that the intended hardware implementation was present in the firmware binary, but did not confirm which implementation seed generation actually reached across the relevant submodules.
The right code was visible. The complete path was not verified.
That distinction goes to the heart of what the word audited communicates. Was a component inspected, or was the shipped product followed from the user selecting “New Wallet” to the physical origin of its randomness? Was the source examined in pieces, or was the completed system tested according to the security promise on which the customer relied?
A separate account carries particular weight. Bitcoin developer James O’Beirne says that while reviewing the Coldcard firmware in May 2025, he struggled to confirm where its randomness originated, questioned the lightly used LibNgU abstraction and recommended removing it. According to O’Beirne, the concern was met with an assurance that, had anything been wrong, it would already have been discovered.
The complete correspondence and any internal response have not yet been made public in the material reviewed. The account must therefore remain attributed. It is nevertheless specific, contemporaneous and concerned with the same boundary that later failed.
The chronology does not require embellishment.
It does not establish a deliberate backdoor, an inside job or Coinkite’s participation in the theft. It does raise a harder question than whether one developer made one mistake: how many layers of confidence accumulated around a security property nobody had successfully demonstrated?
When every explanation moves
The investigation has unfolded publicly and under pressure. Estimates increased. The affected range developed as analysis continued. Different attackers appeared to use different transaction patterns. Emergency migrations, defensive movements and suspected thefts were not always easy to distinguish from blockchain data alone.
At the same time, darker theories spread: pseudonymous developers, deleted posts, historical jokes about “retirement attacks” and politically convenient timing. Some of the questions are reasonable. None becomes an answer merely because the official account remains incomplete.
Documentary filmmaker Adam Curtis once described a state of constant narrative shape-shifting in which people gradually lose confidence that they can distinguish what is real from what is staged. An evolving security investigation is not evidence of organised psychological manipulation. But the subjective effect can resemble it: facts, allegations, emergency advice, brand defence, competitor marketing and conspiracy arrive in a single stream until exhaustion replaces judgement.
That sense of exhaustion is important.
In a very different political setting, Soviet defector Yuri Bezmenov used demoralisation to describe a condition in which an abundance of information no longer enables people to reach sensible conclusions in their own defence. Borrowed cautiously, the concept captures something now visible among Bitcoiners: the fear that careful action has no meaningful relationship to the outcome.
They learned self-custody. They bought the respected device. They kept it offline. They protected the backup. Then the money moved anyway.
Galaxy’s Alex Thorn has repeatedly argued that victims should not be shamed. Many did not publish or casually expose their recovery words. A product entrusted with generating them had failed to perform its defining function.
The demoralising conclusion is that verification is impossible, self-custody is theatre and surrendering everything to an exchange or investment fund was the sensible choice all along.
That reaction is understandable. It is not inevitable.
Self-custody did not cease to exist because one implementation failed. Nor should the event be softened into a cheerful story about an industry becoming stronger through adversity. Real people paid for this lesson, and many may never recover what was taken.
The proper response is to refuse both denial and despair: to establish what happened, preserve the boundary between evidence and speculation, demand a complete account of the reviews and warnings, and recognise that reducing trust is not the same as abolishing it.
A device can protect a key. It cannot promise invulnerability.
The work now is to see clearly, act carefully, and reject the belief that because certainty was never possible, responsibility no longer matters.
If you require any help understanding or improving your Bitcoin self-custody setup, please do not hesitate to contact support@hardblock.com.au
Keep your keys, with a safety net, using GuardBlock. If going fully solo feels daunting after this, there’s a middle path. You still hold your own key and stay in control, but we co-sign alongside you, so no single device, seed, or mistake can put your Bitcoin at risk the way single-signature can. Recovery and inheritance are built in too.
Further Reading: