The COLDCARD Incident
‍

In late July 2026, Coinkite — a Canadian company that has designed and sold Bitcoin security hardware for many years — disclosed a serious flaw in the firmware of its COLDCARD hardware wallets, a widely used line of devices for long-term Bitcoin storage now spanning several generations. On affected firmware, the devices had for roughly five years generated wallet seeds with far less randomness (often referred to as entropy) than intended. In the same period as the discovery, funds were swept from a large number of wallets, whose devices had been used as intended, with no reason to suspect a traditional exfiltration of private key material.

‍

Reported losses have grown as on-chain analysts traced successive waves of movement. Galaxy Research has confirmed some 1,600 BTC stolen from thousands of addresses, with a further wave still being verified that would take the total past 2,000 BTC (around $130 million), and the figures are still moving.

‍

The root cause sat in the firmware, the software the device runs: a fault in how it was put together quietly replaced the hardware source of randomness with a predictable substitute. The discovery and exploitation of this predictability allowed attackers to independently and remotely derive users’ keys and steal their assets. Coinkite has released corrected firmware for all affected models, though the update alone does not resolve the exposure: a seed already created remains weak, with the only resolution being moving the assets. Nor is the move always quick, and it can carry hazards of its own, so it must be conducted methodically. These devices are often kept deliberately beyond arm's reach, with carefully constructed redundancy and backup arrangements that can be difficult to replicate rapidly. The situation remains fluid.

‍

What makes the incident jarring is that the attack required nothing from the device or its owner: no malware, no phishing, no stolen backup. The wallet never needed to be touched at all.

‍

This is the story of what happens when the foundation of custody fails, and what it means for Bitcoin's underwriters, builders, and holders alike.

Coins Swept Without a Touch
‍

The reports that define the incident describe wallets that were kept cold, and whose backups were never exposed, emptied all the same. The pattern at first was mass and nearly simultaneous: wallets, many of them long-dormant, swept within a very short span of one another.

‍

On the Bitcoin network, sweeping a wallet requires one thing only: valid signatures spending its funds. The network honours a valid signature no matter who produced it, so in practice, whoever can produce valid signatures from a wallet’s keys controls its funds.

‍

A wallet begins from a single number drawn at random from an enormous range, typically transcribed as a seed phrase of 12 or 24 words. Entropy is the measure of how unpredictable that draw is: it is fullest when every value in the range is equally likely, and it falls as the draw becomes predictable. The words are the master secret from which all else follows. From them, private keys are derived. From a private key, a public key, and from a public key, an address (in the single-signature case). Whoever knows the words or can reproduce them, plus the optional passphrase where one is used, can re-derive every key and every address beneath them, and a signature produced with a re-derived key is, to the network, indistinguishable from the owner's, because it is the same key.

‍

The attackers, in other words, had reproduced the seeds. How that was possible for devices designed never to surrender them, and never accessed by the attackers, comes down to how the seeds were made in the first place.

‍

What a Hardware Wallet Promises

‍

From the point of view of a typical holder, a hardware wallet needs to do three jobs well: produce a good secret, store that secret securely, and use the secret to derive private keys to sign transactions, without the secret ever leaving the device.

‍

Everything else the device offers, whether the secure chip, the PIN, the air gap, or the tamper evidence, is layered on top of the first job. Those layers protect the secret from being taken, but they cannot make a poor secret good.

‍

Nothing in this incident was broken into. The devices stored their seeds and signed transactions exactly as designed, and their isolation was never defeated. The failure was in the first job alone: the secret each affected device produced was, unknown to its holder, guessable. What separates a good secret from a guessable one is a question of randomness.

The Arithmetic of an Unguessable Key
‍

A private key is secure because it is a value drawn from a space of possibilities so unfathomably large that a brute-force search is hopeless. The mathematics beneath a Bitcoin signature conceals the key well: neither an address, nor a public key, nor a signature should give it away. But that concealment protects only a key that could not have been guessed in the first place, so the entire guarantee rests on the seed having been generated as close to truly at random as possible.

‍

Randomness of this kind is measured in bits of entropy, and the measure works by doubling: each additional bit doubles the number of candidates an attacker would have to try. A standard 12-word seed corresponds to 128 bits of entropy, generally considered the floor for a good seed. If every person on Earth checked a billion candidates every second, exhausting that space would take on the order of a hundred times the age of the universe. The longer 24 word form corresponds to 256 bits, which is not twice the search, but the doubling applied another 128 times: the entire 128-bit search, multiplied by itself. That count is on the scale of the number of atoms in the observable universe. That is the sense in which a properly generated seed cannot be guessed or tractably enumerated.

‍

The same doubling works in reverse. Every bit of randomness that fails to reach the seed halves the search, and the fall is steep: lose 88 of those 128 bits and the count of possibilities drops from a thirty-nine-digit number to about a trillion, which is well within reach of modern computing. Values drawn from a space that small can simply be enumerated, every possibility tried in turn.

‍

Good randomness, in turn, must come from somewhere. A computer following instructions produces nothing unpredictable: run the same program twice and it does the same thing twice. Devices that need true randomness therefore include a dedicated hardware component that harvests physical noise, which cannot be reproduced or predicted. The COLDCARD includes such a component, and its seeds were designed to be drawn from it.

The Fault
‍

The fault affected COLDCARDs running particular firmware versions. Coinkite’s advisory sets out precisely which models and versions were in scope. Its other product lines, which run separate code, were not affected. The affected versions span roughly five years of devices, across several generations of the product.

‍

On those versions, the seed was not drawn from the hardware randomness component at all. The firmware is assembled from many parts, and among them sat two possible sources of randomness: the device’s dedicated hardware, and an ordinary software generator that comes bundled with the platform the firmware is built on — adequate for casual purposes, and never meant to produce unguessable secrets. The intent was always the hardware. But from a change made in 2021, part of a broader reorganisation of the wallet code, the way the firmware was put together left the seed-making code silently connected to the software generator instead. That generator’s starting point is derived from values an attacker can constrain or guess: a fixed identifier baked into the device’s chip, and the readings of internal clocks at the moment of generation. From those few inputs, everything it produces follows deterministically.

‍

The fault went unseen for five years because nothing was positioned to see it. The substitution itself was never checked for: nothing verified, when the firmware was built, which source the seed-making code had actually been connected to. What the firmware did check, each time it made a seed, was the behaviour of whatever generator it had — halting if the generator repeated itself, as a dead one does, or if the bytes that came back were plainly degenerate. Those checks were aimed at a generator that had failed, and the substitute had not failed: it ran normally, its output varied and looked ordinary, and it passed. Output is, in any case, the wrong place to catch this class of weakness — a predictable stream of numbers looks no different from a random one. The tests judged what the numbers looked like, but the problem was where they came from.

‍

The firmware is open source, and the fault has since been examined and confirmed by independent reviews.

‍

Coinkite has released corrected firmware for all affected models. Among its changes, the build now verifies that seeds draw from the hardware source. A firmware update, however, cannot repair a seed that already exists: a seed generated on an affected version remains weak regardless of what firmware the device runs today. For such seeds the only remedy is to move the assets.

‍

How Weak Were the Seeds?

‍

How weak the seeds were differs by model. The earliest affected models were the worst: analysis of the fault place the number of seeds they could actually produce low enough that the entire set can be searched with ordinary computing hardware. The later models drew on additional sources of randomness and did better. Coinkite has published its own estimate of their strength, and other analyses put the practically relevant figure lower still. On any of the published figures, the later models remain far short of their design strength, with spaces large enough to make a search expensive but not large enough to make it hopeless.

‍

Two things kept a wallet from being imminently attackable. A seed protected by a strong, unique passphrase was not exposed in the same way, because the passphrase adds randomness obscuring the underlying fault. And a seed whose generation was supplemented with a sufficient number of documented dice rolls carried real randomness from outside the device.

‍

The attack itself is a patient enumeration, run entirely against public data. An attacker derives each candidate seed, computes the addresses it would control, and checks those addresses against the public record of the chain, which costs little and alerts no one. On a match, the attacker holds the seed and every key and address beneath it. The work can be spread across many machines, from ordinary computers to hardware that can perform the search substantially faster, and it only needs doing once: the candidate seeds and the addresses they control, once computed, can be kept and checked against the chain indefinitely. The shape of the sweeps, with many wallets emptied nearly at once, is consistent with a search of this kind having been completed in advance.

‍

At no point does the search involve the device itself, its backup, or any network the device was ever connected to. That is why wallets that had never been connected to anything could be emptied: the weakness was carried in the keys, and the keys could be found from public information alone.

‍

For holders, the consequences are direct. The security of the physical device has no bearing on the risk, and funds resting on a seed generated by affected firmware remain at risk until they are moved elsewhere. Multi-signature arrangements, in which several devices must sign, can also be exposed where enough of the signing devices are affected, since the strength of the arrangement rests on the strength of its member keys.

How It Has Played Out
‍

On July 30^th, 2026, Coinkite went public with an admission of the flaw, issuing a security advisory accompanied by analysis from independent researchers. Large-scale sweeps of vulnerable wallets were taking place in the same period.

‍

Early reports described hundreds of BTC leaving hundreds of wallets within a single short window. Estimates rose over the following days as on-chain analysts traced further waves: within days, reported totals ran above a thousand BTC spread across thousands of addresses, and hundreds of suspected attacker addresses had been identified. The figures continue to move, and any total quoted today is provisional.

‍

Who is behind the sweeps has not been established. What has become clear is that more than one attacker is now at work: on-chain analysts describe the later waves as multiple actors exploiting the same weakness. Once a weakness of this kind is public, whatever remains of the vulnerable space is searched, and anything reachable will in time be reached.

‍

Questions about AI have accompanied the incident from the start, and they are easier to pose than to settle. It is natural to wonder whether the flaw was found with the help of AI review of the published firmware, and whether generative AI played any part in the thefts themselves. Neither has been established, in either direction. The flaw was not spectacularly deeply hidden, and a careful reader of the published firmware, tracing how it was put together, could plausibly have found it unaided. This was not in the realm of stringing together difficult-to-trace interactions across many layers of code, but a single connection that came to rest on the wrong source. Still, it lay in the step on which everything else rested, one that a great deal of value was implicitly trusting and that stood to reward any attacker who examined it closely. It went undiscovered in the open for roughly five years all the same. Beyond finding the fault, however, it needed to be actively exploited. Even when the enumeration itself is tractable, establishing what to enumerate means reconstructing the substitute generator, pinning down the space of values feeding it, and building machinery to derive and test candidates in bulk. Widely available AI assistance may well have been material to both the discovery and the exploitation, and we await findings on the question.

Soter’s View
‍

We understand the impact of this event on those affected. The losses are real and, for many, deeply painful. Much of what was taken belonged to individual holders or families, people for whom it may have been their life savings, or a significant portion of them. They did what they believed was right, followed security practices, and quietly saved in bitcoin. They were affected just the same, by a silent error.

‍

A single shared fault, present across many otherwise unrelated holders, produced simultaneous and correlated losses. For underwriters of custody risks, that pattern is systemic by nature, and the kind of aggregate exposure that must be watched carefully.

‍

Where Soter underwrites, we have made certain design choices; crime and loss insurance policies are denominated in bitcoin, so a loss is measured and made good in the unit of the asset itself, and we have focussed on institutional clients. Even for institutional clients, an incident of this kind sharpens the mind of every underwriter in the market, because a single arrangement concentrates exposure to exactly this class of fault, and so does a portfolio of them. The deeper lesson sits upstream of any individual policy. Hardware manufacturers, software developers, and insurers share an interest in the integrity of the secrets at the base of custody. When that integrity fails quietly, the consequences fall first on holders and then on the wider ecosystem that supports them. Strengthening how randomness is produced, verified, and disclosed should be treated as a shared responsibility.

‍

We see a role for insurance in that shared responsibility. A manufacturer that can evidence the integrity of its key generation, from the hardware source of randomness to the build that reaches the device, is making a promise an insurer can stand behind. Cover structured at that level could reach individual holders through the device itself, rather than asking each holder to be underwritten. We are exploring this with hardware manufacturers. Any credible product here must confront the very correlation this incident demonstrates, a single fault present in every device at once, and that is an underwriting problem to solve before it is a product to sell.  

Conclusion
‍

The security of a wallet rests on the quality of the secret it generates. In this incident, every protection layered above that secret worked as designed, and none of it mattered, because the secret itself could be guessed. The attack ran against public data, on the attackers’ own hardware, at their own pace, and the first sign any holder had was the movement of their own funds.

‍

The lesson extends beyond one vendor and one firmware fault. The generation of a secret is the least visible part of custody, and the part on which everything else depends on. This is what that foundation failing quietly looks like, not an alarm, but an absence discovered years later on the public record of the chain.  

‍

For holders, if you used an affected COLDCARD firmware version to generate a seed, treat that seed as compromised and move the assets. For builders and underwriters, the integrity of key generation is a shared foundation. Strengthening it is the only durable way to reduce the frequency and severity of events like this one.