One Key, One Vendor, One Failure: Multisig After the Coldcard Incident

The attack did not stop

Last week we examined what the Coldcard incident shows about the gap between reviewable and verified: a weak-entropy flaw sat in open-source firmware for five years before an attacker regenerated hundreds of wallets in minutes. That article ended at the disclosure. The story did not.

In the days that followed, the sweeps continued. By 3 August, CoinDesk reported losses approaching 114 million dollars (roughly 1,816 BTC across more than 5,200 addresses), with a fourth wave still running as it was written. Alex Thorn, head of research at Galaxy, warned publicly that the attack was ongoing and urged anyone holding bitcoin on single-signature addresses generated by an affected Coldcard to move it immediately. His assessment, which events so far support, is that remaining affected single-signature addresses are a matter of time: the keyspace has been reduced to something enumerable, and multiple parties are now enumerating it.

The wrong lesson: switch vendors

The tempting response is to treat this as a product failure. Coldcard shipped the flaw, so buy a different device, and the problem is someone else's. That reasoning repeats the exact mistake the incident exposed.

The previous article's conclusion was that availability for review is not verification, and that this holds for every vendor, not one. Comparable weak-entropy failures have already appeared in Libbitcoin's tooling and in Trust Wallet's extension, each public, each unnoticed for years. Coinkite's own advisory describes a defect that produced no visible symptom on a device that otherwise worked perfectly. Nothing guarantees that the firmware in any single alternative device is free of an equivalent silent flaw. Replacing one device with another does not remove the single point of trust; it relocates it.

The durable answer is structural: stop depending on any one device, one seed, or one manufacturer at all.

Diversity, made concrete: a 2-of-3 multisig

Bitcoin supports this natively. A multisignature wallet locks funds to a script that requires signatures from a threshold of independent keys, commonly two of three. The practical setup, achievable today by a careful individual:

• Take three hardware wallets from three different manufacturers: for example a Ledger, a Trezor, and a Coldcard. The specific brands matter less than the diversity; these are examples, not endorsements.
• Generate a separate seed on each device, independently, so no seed is derived from or entered into another.
• Combine the three public keys into a 2-of-3 multisig wallet using coordinator software such as Sparrow.

From then on, moving the funds requires signatures from at least two of the three devices. Sparrow's own best-practices guidance recommends exactly this shape for meaningful cold storage: at least 2-of-3, with hardware from different vendors, precisely so that a vulnerability in one vendor cannot compromise the whole setup.

Run the Coldcard incident through that structure. A holder whose three keys include a vulnerable Coldcard remains protected: even an attacker who fully reconstructs that device's seed from its weak entropy holds one signature of the two required. The flaw that emptied thousands of single-signature wallets yields, here, nothing.

Be clear about the cost. This is friction: more devices, more steps, slower spending, more to manage. That friction is the price of a security posture that no single vendor's mistake can undo, and unlike custodial or specialist alternatives, it is accessible to anyone willing to accept it.

What multisig does not fix

A 2-of-3 does not make anyone invulnerable, and describing it that way would repeat the overclaiming this series exists to counter. Devices still fail, seeds still get lost, and there are now three of each to manage. The structure only delivers its guarantee if the operational details hold:

• The three seeds must be genuinely distinct and independently generated. Restoring one seed onto the other devices quietly rebuilds the single point of failure inside multisig packaging.
• Devices and seed backups must not all live in the same place. Three keys in one drawer is one key with extra steps.
• Back up the wallet configuration, meaning the output descriptor that Sparrow produces. A descriptor records how the wallet is constructed: which keys, which threshold, which derivation paths. It cannot spend funds and it is not a key, but without it, reconstructing the wallet from surviving seeds can be genuinely difficult. It does reveal your addresses, so store it with care, just not with the fear reserved for seeds.
• Before committing meaningful value, send a small amount, then rehearse recovery: restore the wallet from backups and confirm you can actually sign. An untested recovery path is a hypothesis, not a backup.

Owning your own Bitcoin node remains, as argued before, essential to real sovereignty: you verify your own transactions instead of trusting someone else's view of the chain. But this step comes first. Sovereignty built on a single point of failure is sovereignty on loan.

Thresholds are an evidence pattern

Step back from wallets and the design principle is general: never let one party, one device, or one process be the sole root of trust for something that matters, and arrange the structure so that a single failure is survivable rather than fatal.

That principle governs evidence systems as much as custody. A provenance record signed by one producer is one attestation: valuable, but only as strong as that single signer's process, as the Coldcard incident demonstrated for single keys. Evidence becomes robust the same way funds do: through independence. A commitment a recipient can verify themselves, without trusting the producer's infrastructure; an anchor on a public chain no single party controls; assessments and attestations from parties independent of the one making the claim. Each is a threshold structure in spirit. The claim stands because multiple independent things would all have to fail together for it to be wrong.

The Coldcard attack is still a live lesson in what happens when trust concentrates in one place and the one place fails. The remedy, for keys and for evidence alike, is not a better single point of trust. It is not having one.