One dice roll lost $38M. MPC rolls three.
Early on July 31 (UTC), roughly 594 BTC, about $38 million, was swept out of ~500 single-signature Bitcoin wallets. The whole operation took 25 minutes. Many of the drained coins had not moved since 2021.
The wallets were generated on Coldcard hardware devices. Coinkite has published a security advisory: seeds created on a Mk3 running firmware 4.0.1 through 5.0.3 (released from March 2021 onward) may be compromised by a flaw in how the device generated randomness. The investigation into the theft itself is ongoing. If a Mk3 seed guards your coins, stop reading and follow Coinkite's advisory.
Credit where due: Coldcard's open-source firmware and air-gapped design pushed the whole industry forward, and Coinkite published its advisory fast. None of that is in question. The architecture is. A hardware wallet, however well built, concentrates all security into one secret, created by one chip, in one moment. What follows is about that design choice, not about one vendor.
A seed phrase is one dice roll
A seed phrase feels like a physical object. Twelve or twenty-four words, written on paper or steel, locked in a drawer. Solid.
It isn't an object. It's the output of a single random draw, performed once, by one chip, running one piece of firmware, at one moment in time.
Everything the wallet will ever protect traces back to that one draw:
entropy = rng(128 or 256 bits) 12 or 24 words
master_key = derive(entropy)
every_address_ever_used = derive(master_key)
If that draw is truly random, brute force is hopeless. Even at the smaller size, 2^128 is not a number attackers deal with.
But if the randomness is weak, everything downstream inherits the weakness. The word count doesn't save anyone: a 24-word seed drawn from a broken RNG is a full-length phrase carrying only a fraction of the randomness it claims. According to the disclosure by Block's security team, that's what happened here: a firmware error caused affected devices to fall back to predictable inputs, values like chip metadata and clock registers, instead of proper hardware randomness. Inputs an attacker can enumerate.
The brutal property of entropy bugs: they fail silently and retroactively. The wallet works. Addresses look normal. Coins arrive. For five years nothing visible is wrong. Then someone works out the flaw, searches the reduced keyspace offline against the public blockchain, and every vulnerable wallet ever created becomes spendable at once. The victims were not attacked. They were found.
Nor is this a Coldcard-shaped problem. In 2023, the "Milk Sad" bug in Libbitcoin Explorer capped seed entropy at 32 bits (a weak Mersenne Twister PRNG) and wallets were drained the same way. Different vendor, different code, same failure class: one RNG event as the root of all security.
The only structural fix is multi-auth
A better RNG doesn't solve this. It narrows the odds of one failure mode while the architecture stays the same: a single secret, minted in a single moment, silently authorizing everything forever. Single points of failure don't announce themselves. They wait.
The structural fix is multi-auth: no single secret, no single device, no single moment. Funds move only when multiple independent parties approve.
Bitcoin has had a version of this for over a decade: multisig. And multisig works. This sweep hit single-signature wallets. But after all those years, multisig remains a power-user tool, because in practice it asks too much:
- Uneven chain support. Native on Bitcoin, contract-based or missing elsewhere. Every chain means a separate setup, separate tooling, separate failure modes.
- The policy leaks. Spend from a classic multisig and the script reveals your quorum on-chain, for anyone profiling targets.
- Recovery is unforgiving. Lose the wallet configuration that describes the setup and funds can be locked even with every key intact.
- Every signer is its own device, its own seed phrase, its own operational burden. Most people quit before finishing the setup.
Multi-auth is correct. Multisig is multi-auth with too much friction to protect most people. That gap is exactly what MPC closes.
How DKG replaces the dice roll
Same dice analogy, different setup. Instead of one person rolling once, three people in three different rooms each roll their own dice, and the secret is the sum of all three rolls. If even one of those dice is fair, the sum is unpredictable. A loaded die in room one helps nobody unless the dice in rooms two and three are loaded too.
That is DKG, distributed key generation: how MPC (multi-party computation) wallets create keys.
Simplified to the bone:
device_A: a = rng_A() share stays on A
device_B: b = rng_B() share stays on B
device_C: c = rng_C() share stays on C
key = a + b + c (mod n)
but the key is never actually computed.
signing happens through the protocol,
each device contributing its share.
Three properties fall out, and each maps directly onto this week:
1. An entropy failure must hit every device at once. A phone, a laptop, a tablet: different chips, different operating systems, different RNG implementations. One firmware bug in one of them no longer determines the key. With a seed phrase, one weak RNG is fatal. With DKG, the combined secret is at least as strong as the best randomness source in the group.
The obvious objection: the wallet app is the same code on every device, so wouldn't a weak RNG in the app break every share the same way? It wouldn't, because the app doesn't roll the dice. Each share's randomness is drawn from the operating system's own generator on that device: Apple's on the phone, Microsoft's on the laptop, Google's on the tablet. Independent implementations, independently maintained, each feeding the protocol locally. The one genuinely correlated risk is a randomness bug inside the shared MPC library itself. That risk is real, and it's handled below.
2. There is no seed phrase to leak, because there is no seed. The full private key never exists on any device, at any moment, including during generation. Nothing to write down, nothing to photograph, nothing for a single compromised device to exfiltrate.
3. It's multi-auth without the multisig tax. The output is one standard signature, valid on any chain. No special scripts, no on-chain fingerprint revealing the quorum, one setup covering an entire portfolio. The security model of multisig with the footprint of a normal wallet.
Offline scanning, the attack class that emptied 500 wallets in 25 minutes, stops working entirely. A weak seed can be brute-forced from public chain data alone, from anywhere, years later. Breaking a threshold wallet means compromising multiple independent devices belonging to one specific victim, while they're live. That is a targeted operation, not a keyspace scan. It doesn't scale.
Where DKG can fail
MPC is not pixie dust, and pretending otherwise repeats the exact mistake that led here.
The math of threshold cryptography is solid. Implementations are where risk lives, same as everywhere else in security. In 2023, researchers at Verichains published TSSHOCK: key-extraction attacks on multiple implementations of the GG18/GG20 threshold-ECDSA protocols, where a single malicious party could recover the full private key after one or two signing ceremonies. Audited libraries were affected.
The realistic failure modes of a DKG wallet:
- Protocol implementation bugs. Missing commitment checks, malformed zero-knowledge proofs, biased nonces. TSSHOCK-class issues. This is the real attack surface.
- Correlated devices. Run every share on identical hardware with identical firmware and a common failure mode is quietly rebuilt. Heterogeneous devices are the point.
- A threshold of compromised devices. 2-of-3 means an attacker holding two devices wins. A much higher bar than one seed on one chip. Not an infinite one.
Every item on that list has a known answer, and the list is what Vultisig was engineered against:
- Protocol choice. Vultisig runs DKLS23, implemented by Silence Laboratories. The protocol is built on oblivious transfer and contains no Paillier encryption, which means the zero-knowledge proof machinery TSSHOCK broke in GG18/GG20 implementations simply doesn't exist in it. Less machinery, less to get wrong.
- Audited implementation. The DKLS23 library went through a Trail of Bits security review; the report is public in the library's repository. The proof machinery is smaller and it's been adversarially checked.
- Heterogeneous shares by default. Vault shares live on your actual devices, across iOS, Android, macOS and Windows. Different vendors, different RNG stacks, no common chip to fail.
- Open code. Every Vultisig app is open source on GitHub. The same standard this article demands of everyone else.
The shape is different, though. Each of these failure modes requires an active attack on a live protocol or on multiple specific devices. None allows an attacker to replay a five-year-old firmware bug against the public ledger and sweep 500 strangers at once. Weak-RNG failures are wholesale. Threshold failures are retail. That asymmetry is the whole argument.
What earns trust here is what earned it for Bitcoin: open source, published protocols, third-party audits, verification over promises. Judge any MPC wallet, Vultisig included, by that standard.
Where this is going
Self-custody is entering a more demanding era. AI agents are starting to hold and move value, automation is reaching treasuries, and the cost of a silent single point of failure compounds every year. A secret rolled once, by one chip, in 2021, is a strange foundation for that world.
The lesson from this week is not "hardware wallets bad." It is narrower and more useful: no single device should ever be the sole source of the randomness your money depends on. Multiple devices, independent entropy, a threshold to sign, open code anyone can verify. Multi-auth, made practical.
Sources: