Coldcard Security Advisory

What it is

This is Unchained's client-facing FAQ supplement to the Coldcard entropy advisory (Mk3/Mk4/Mk5/Q models) covered in the existing summary. Its value is entirely in the decision-tree detail for Unchained vault holders — the summary covers the vulnerability and the basic RBF attack scenario, but not the specific guidance for each client situation.

Preconditions / Affected

• Only relevant to Unchained's standard 2-of-3 vaults (2 client keys + 1 Unchained key); the Unchained-controlled key is independently generated and unaffected.
• A seed later imported into a Coldcard from another device is NOT affected; only seeds originally generated on a Coldcard are compromised, regardless of where they're stored now.
• The RBF replacement-cycling exposure specifically requires an address that has both received and previously been spent from (reused in the "spend-then-receive" sense) — multiple deposits to an address with no prior spend do NOT create this exposure.

What to do

Guidance branches by how many of the two client keys were Coldcard-generated:

• 1 of 2 client keys affected: Funds are safe (attacker can't reach 2-of-3 threshold). Replace the single Coldcard key when convenient; no urgency.
• 2 of 2 client keys affected: Create an entirely new vault with two independently generated, non-Coldcard keys and sweep the full balance, rather than replacing keys one at a time — this avoids two sequential replacement workflows and the window where the attacker retains threshold control.
• Partial replacement already done (one of two Coldcard keys replaced): The RBF attack is no longer possible once the first replacement transaction confirms, since the attacker loses the 2-of-3 threshold. The remaining Coldcard key should still be replaced.
• Checking for reused-address exposure: If you've never spent from the vault, or you always generate a fresh address via the Deposit button, you have no reused addresses and thus no RBF exposure. Otherwise contact Unchained Support for a vault review.
• Shared keys via Connections: Coordinate replacement with all partner vault owners first, pause new deposits, and expect each funded vault to need its own sweep transaction.
• Replacing hardware: Simply moving an existing Coldcard-generated key to a new device does not fix anything — a brand-new key must be generated on new hardware. Alternatively, Coldcard's firmware update plus key regeneration is an option, but Unchained states it has not reviewed that firmware fix for sufficiency.
• IRA vaults: Key replacements/transfers within the same IRA are not taxable distributions; transfers out of the IRA are reported as taxable withdrawals.
• Trading-desk sales are still on-chain broadcasts and remain exposed to the same RBF risk — using the desk doesn't sidestep it.

flowchart TD
    A[How many client keys<br/>Coldcard-generated?] -->|1 of 2| B[Funds safe now<br/>Replace when convenient]
    A -->|2 of 2| C{Already replaced one?}
    C -->|No| D[Build new vault,<br/>sweep full balance]
    C -->|Yes, confirmed| E[RBF attack no longer possible<br/>Replace remaining key]

Caveats

Unchained explicitly disclaims having reviewed Coldcard's firmware-fix-plus-regeneration path for sufficiency — it only reviewed the key-replacement remediation it recommends. The FAQ also notes Unchained believes few clients actually hold the 2-Coldcard-plus-reused-address combination needed for the RBF scenario.