Three Keys From the Same Vendor Are Not Multisig

Three keys from the same vendor are not multisig; they are a single point of failure with three copies.

That sentence is a test, and it has only two outcomes. If you read it and nodded — congratulations, you are likely fine, and the checklist at the bottom will confirm it in a minute. If it means nothing to you, take it seriously: your bitcoin may currently depend on a single company being right forever, and in July 2026 that bet failed for hundreds of people who had chosen the best brand available. This page takes you from the sentence to the fix.

What multisig actually buys you

A 2-of-3 multisig wallet is controlled by three separate keys, and spending requires signatures from any two of them. That threshold is the whole product. It means you can lose one key (house fire, forgotten backup) and still spend with the other two. And it means an attacker who compromises one key — steals a device, finds a backup, phishes you once — still cannot move a single sat.

Read that second half again, because it hides an assumption: multisig protects you against the compromise of one key only if compromising one key tells the attacker nothing about the other two. The security of the quorum is not the sum of three keys. It is the independence of three failures.

Correlation: the failure mode nobody prices in

Now ask what your three keys actually share. If all three were generated on devices from the same manufacturer, they share more than a logo:

• One random number generator design. Every seed was born from the same generation code. A flaw there is a flaw in all three keys at once.
• One firmware lineage. The same bug ships to all your signers in the same update.
• One supply chain. The same factory, the same distributor, the same tampering opportunity.
• One vendor decision-making process. Whatever blind spot missed the bug the first time is a blind spot for your entire quorum.

A 2-of-3 wallet needs two guessable keys to become spendable by an attacker. Three independent keys make that astronomically unlikely. Three correlated keys make it one event: whatever breaks one, breaks enough.

July 2026 made this concrete

This is not a thought experiment anymore. In July 2026, a firmware flaw in Coldcard devices — a device this site had recommended for years — meant that seeds generated on affected firmware (shipped from March 2021) were drawn from a small, enumerable space instead of an astronomical one. Attackers pre-computed candidate seeds offline and swept roughly 594 BTC from around 500 wallets — every one of them single-signature — in a 25-minute window on 30 July 2026.

Every wallet swept in that window was single-signature. That is not the same as multisig being safe: any quorum whose threshold could be met with affected keys was already spendable in principle — a 2-of-3 with two vulnerable same-vendor signers has no threshold left to defend it, and all that still stands between it and an attacker is the work of discovering the wallet's descriptor, not the strength of the quorum. The people who split their quorum across manufacturers watched the same news with a different heart rate: for them, the bug touched at most one key out of three — below the threshold, exactly the failure multisig is designed to absorb.

The uncomfortable part is how reasonable that concentration looked: buying three of the device you trust most is not carelessness, it is the same decision made three times. That is the lesson that outlives the incident — you cannot delegate the obvious, not even to the best brand in the room. Reputation reduces the probability of a failure. It does nothing to reduce the correlation of your failures.

That is what makes July 2026 a true black swan for cold custody: the event sat outside every threat model not because the mathematics were exotic, but because the risk lived inside the very device people bought to eliminate risk. Black swans don't announce themselves through weak products; they arrive through the strongest one in the room, because that is where everyone's eggs already are. You don't defend against that by picking a better king — you defend against it by refusing to have one.

The fix, part one: a heterogeneous quorum

Build your 2-of-3 multisig across different manufacturers with different codebases — three signers, three vendors, three independent implementations of seed generation and signing. Now a catastrophic vendor failure — an RNG bug, a malicious update, a supply-chain compromise — touches one key. One key below a 2-of-3 threshold is an inconvenience, not a loss.

Add a strong BIP-39 passphrase as a second lock where your setup supports it. A passphrase is something the device never generated and never stored — which is precisely its value on the day a device turns out to have been wrong about something. Make it high-entropy and randomly generated, not a memorable phrase, and never type it into a phone or browser.

The fix, part two: dice — the one job you can do yourself

Everything above still leaves one delegation in place: you are trusting each device's generator at the moment your seed is born. That is the one trust point you can remove entirely, because generating randomness does not require electronics at all. It requires dice.

The arithmetic is short. A fair six-sided die yields log₂6 ≈ 2.585 bits of entropy per roll. So:

• 50 rolls ≈ 129 bits — clears the 128-bit security of a 12-word seed;
• 99+ rolls ≈ 256 bits — the full security of a 24-word seed. Ninety-nine is the point where extra rolls stop buying security an attacker could ever notice; rolling more is harmless, just slower.

The procedure is deliberately boring: a room with nothing electronic recording you, a casino-grade die, pen and paper, and a signer that accepts dice-roll entropy. Roll, write, enter. Two rules make it real instead of theater:

• Roll the full count. Fifty rolls is the floor for 128-bit security, ninety-nine for 256. Twenty rolls "to add some randomness" is a lock made of fog.
• Verify that the device actually used your rolls. Entering dice is still delegation unless you check the output. Use the verification procedure your signer documents — independently recomputing the expected seed from your rolls on a second, offline tool and comparing. A signer that offers no way to verify its dice-derived seed is telling you something about how it thinks about trust.

The checklist

• 2-of-3 multisig, three different manufacturers, three different codebases.
• Strong, random BIP-39 passphrase on top — never stored with any seed backup.
• Dice entropy for each seed: 99+ rolls per key, verified against an independent offline tool.
• Backups stored in separate locations, so geography doesn't become your new correlation.
• The wallet descriptor (all three xpubs) backed up alongside every seed — and each xpub verified on its own device at setup. Three seeds without the descriptor is not a recoverable wallet.
• Rehearse recovery before you need it: a quorum you've never restored from backup is a hypothesis, not a wallet.

Frequently Asked Questions

Isn't using three vendors three times the risk of a bad vendor?

It triples your exposure to minor vendor problems (a bad update you must wait out, a clunky UI) but divides your exposure to the catastrophic one. With a 2-of-3 threshold, any single vendor failing completely — even maliciously — leaves your funds unspendable by the attacker and recoverable by you. That trade is the entire point.

Does a strong passphrase alone fix same-vendor risk?

It helps substantially — Coinkite's early analysis of the July 2026 incident put funds behind a strong passphrase at minimal risk — but it is one layer, not a substitute. If the base seeds are weak, an attacker can enumerate them and then attack your passphrase offline at scale. Layer it on top of a heterogeneous quorum, not instead of one.

Are dice really better than a hardware wallet's built-in generator?

A healthy hardware RNG is excellent — the problem is you cannot personally audit "healthy." Dice move seed generation from something you trust to something you did. The July 2026 incident happened precisely in the gap between those two words.

I already have a same-vendor multisig. Do I need to start over?

Treat it as a migration, not an emergency teardown — unless your devices are affected by an active advisory (check the current one), in which case act now. Build the new heterogeneous quorum first, test a full recovery, then move funds. Never dismantle the old setup before the new one has received and secured the coins.

Related Resources

• The Coldcard Seed Entropy Flaw (July 2026): Who's at Risk and Exactly What to Do
• 2-of-3 Multisig Bitcoin Setup Guide
• Seed Phrase Passphrase: The 25th Word Guide
• Bitcoin Multisig: From Beginner to Expert
• Diego DeFi’s thread “La caída del rey” (Spanish) — a layperson-friendly narrative of the incident that inspired part of this page’s framing.