On July 30, roughly 500 Bitcoin addresses were drained within a short window—1,324 UTXOs in all, amounting to about 594.5 BTC. The wallets shared one troubling trait: some of their seeds may have been generated by an older firmware version of the Coldcard Mk3.
According to the technical analysis available so far, the firmware in question was supposed to draw on the device’s hardware random number generator. Because of a compilation setting and a flawed code check, it instead fell back to a deterministic, software-based source of randomness. Users believed their recovery phrases came from true hardware entropy; in reality, the pool those phrases were drawn from may have been small enough to enumerate.
As of this writing, the randomness flaw in Coldcard has been corroborated by public technical analysis. Exactly how the attacker exploited it end to end—and whether all 594.5 BTC trace back to this single issue—remains under investigation. But whatever the final attribution, the incident surfaces a point that is easy to overlook:
A private key that was never leaked is not automatically a private key that is safe. From the very moment it is created, it also has to be unpredictable enough.
The attacker never had to break Bitcoin
A Bitcoin private key isn’t secure because it lives inside some special device. It’s secure because a properly generated key sits somewhere in an astronomically large space of possibilities—one no attacker can search through with any amount of real-world computing power.
That guarantee rests entirely on randomness.
Feed a wallet high-quality cryptographic randomness, and an attacker faces a key space that is effectively unsearchable. Feed it randomness derived from a timestamp, device metadata, or a predictable software routine, and the attacker is no longer up against the full key space—only a dramatically narrowed set of candidates.
From there, the playbook is simple: reproduce the faulty randomness, generate candidate seeds in bulk, derive their wallet addresses, and match those against on-chain addresses that hold a balance. A single match exposes the corresponding private key.
At no point does the attacker touch the hardware wallet, plant malware, or trick a user into handing over a recovery phrase. They never break the elliptic-curve cryptography that Bitcoin relies on. They simply sidestep the assumption that cryptography was counting on in the first place.
This is not the first time. The Wintermute, Trust Wallet, Libbitcoin, and 120,000-BTC incidents that Safeheron has examined previously all point to the same root cause: the cryptographic algorithm never failed. What failed was the randomness used to generate the key.
What hardware wallets solve—and what they don’t
Hardware wallets remain a valuable security tool, full stop. They keep private keys off the internet, complete signing inside a dedicated device, and meaningfully reduce the risk of malware, remote intrusion, and key extraction.
But what those measures really address is a single question: once a private key exists, how do you keep someone else from taking it?
They say nothing about an earlier and equally important question: was that key truly random at the moment it was born?
The security of any hardware wallet still depends on its hardware RNG, firmware, compilation settings, cryptographic libraries, production build, and supply chain all remaining correct—simultaneously. When a single device generates and stores a complete private key, all of those links together form one concentrated root of trust. A serious defect in any one of them can compromise the entire key.
So “offline” and “secure” are not the same thing. Going offline shrinks the attack surface, but it cannot repair a key that was predictable from the instant it was created.
For institutions, the real question isn’t “where is the key?”
An individual can dramatically improve how they safeguard their keys simply by buying a hardware wallet. For an institution managing large pools of assets, picking a more secure device isn’t enough. The question that actually matters is different:
If any single element fails—one device, one firmware build, one source of randomness, one cloud account, one administrator—is that enough for an attacker to seize the assets?
If the answer is yes, then no matter how reliable that single point looks today, it still sets the ceiling on the security of the entire system.
Institutional-grade security shouldn’t be built on the assumption that some component will never fail. It should be built, at the architectural level, so that no single failure is ever enough to take control of the assets.
Safeheron: no single point ever holds the complete key
The value of MPC is not that it frees a system from needing secure randomness. Every cryptographic system, MPC included, depends on a correct protocol implementation and a high-quality source of randomness. What MPC genuinely changes is this: the complete private key is never generated, stored, or used by any one party on its own.
Safeheron uses a 3/3 MPC architecture. Party A sits on the client side. Party B and Party C run in separate cloud accounts, cloud environments, and networks, each administered independently by different people, each with its own disaster-recovery personnel and recovery mechanism. The three parties jointly produce key shards through a distributed key generation protocol; each party holds only its own shard, and the complete private key never materializes during generation, storage, or signing. The client-side shard exists only on the client’s device—Safeheron cannot obtain it, and cannot sign on the assets without the client.
The same principle applies to randomness. The final key is never determined by any single party’s entropy alone. Each participant contributes its own secure source of entropy; as long as the protocol is correct and at least one party’s contribution is genuinely unpredictable, no single party can predict or manipulate the final key. Safeheron’s MPC participants combine a system-level entropy pool with a TEE hardware entropy source, further reducing reliance on any one source of randomness.
On top of that, TEEs protect the cloud-side key shards and critical execution logic, while independent cloud accounts, independent networks, and separation of administrative duties further isolate control. Safeheron’s core MPC and TEE algorithms are open-sourced, so the key cryptographic implementations can be publicly inspected and verified.
The architecture doesn’t assume every component will always behave. It is designed, as far as possible, to ensure one thing: even if a device, a node, a cloud account, or an administrator’s privileges are compromised, that alone is not enough to reconstruct the complete key or move the assets.
Closing thought
The lesson of the Coldcard incident isn’t that hardware wallets have lost their value—it’s that a hardware wallet is not the finish line for security.
Key security depends both on whether a private key is properly protected after it’s created and on whether it was truly unpredictable when it was created. For institutions, there’s a further consideration: whether control of the complete key and the assets is concentrated in any single point of failure.
A genuinely resilient security architecture isn’t a search for one device that will never fail. It’s a design in which no single device or component can, by failing, decide where the assets end up. Hardware wallets reduce the odds of key exposure; MPC goes further, splitting apart the complete key, the control over it, and the root of trust itself.
To learn how Safeheron builds institutional-grade self-custody for digital assets with MPC and TEEs, get in touch to request a product demo or trial.
Looking for a secure way to manage digital assets?
Talk to our experts and find the right solution for your business.
Request a DemoLooking for a secure way to manage digital assets?
Talk to our experts and find the right solution for your business.