How multisig protected thousands of bitcoin during the Coldcard incident

What it is

Unchained's analysis of why multisig wallets resisted the July 30, 2026 Coinkite Coldcard RNG advisory, breaking down four distinct protective mechanisms beyond simple key redundancy.

How it works

The page lays out a layered defense, each layer independent of the others:

1. Quorum requirement: a 2-of-3 setup needs two private keys to spend; if an attacker recovers only one compromised Coldcard key, they're still short.
2. Missing public key: spending from a multisig address requires knowing all public keys in that address (not just the threshold private keys). Even with two compromised private keys, the attacker still needs the third key's public key, which may not be derivable from anything exposed by the RNG bug.
3. Public keys aren't actually public: they're only exposed via the wallet's configuration/descriptor file (if leaked) or by broadcasting a spending transaction, which reveals all of that address's public keys.
4. Combinatorial cost: even if an attacker holds a full list of compromised key pairs (e.g., all-Coldcard 2-of-3 wallets), they must correctly match 2-3 keys together to a specific address — a search problem that scales against them if the candidate pool is large.

flowchart TD
    A[Attacker has compromised private key] --> B{How many keys compromised?}
    B -->|0 or 1 of 3| C[Cannot meet quorum - safe]
    B -->|2 or 3 of 3| D{Address ever spent from?}
    D -->|No, never spent| E{Config file leaked?}
    E -->|No| F[Final pubkey unknown - safe]
    E -->|Yes| G[All pubkeys known - vulnerable]
    D -->|Yes, broadcast to mempool| G
    D -->|Yes, broadcast direct to miner| H[Pubkeys hidden until confirmation]

Preconditions / Affected

The RBF-style exposure window applies specifically to multisig addresses where: (a) 2 or 3 of the signing keys were generated by an affected Coldcard, and (b) the address has been spent from (revealing all its public keys on-chain) or its wallet descriptor/config file has leaked. Address reuse after a spend compounds the risk since the exposed public keys remain tied to that address.

What to do

The page states two concrete mitigations Unchained took: broadcasting transactions directly to a trusted miner instead of the public mempool (closing the pending-transaction exposure window), and defaulting to full-address sweeps with change sent to a fresh, unused address rather than reusing spent-from addresses. It also recommends keeping wallet descriptor/configuration files private, since those alone reveal all public keys for a wallet.

Caveats

The page doesn't specify how Unchained validates whether a transaction destined for a trusted miner avoids re-exposure risk entirely, nor does it give a time bound on the mempool exposure window. It also doesn't quantify the "orders of magnitude" claim for the combinatorial key-matching difficulty — this is stated qualitatively only.