COLDCARD vulnerability what happened, and what to do
Informational only, and this site never asks for your recovery words. details

Informational only. This is independent analysis and an evidence-backed explainer, not financial, security or legal advice, and not a substitute for professional advice about your own situation. It is not affiliated with, endorsed by, or speaking for Coinkite, Block, or any other party named here. Published estimates are attributed, and differing scenarios are kept separate with their assumptions. Act on your own judgement. Editorial standards and corrections.

Do not disclose recovery material to a website, form, message or support account. This site never asks for it. Deliberate recovery on independently verified offline equipment is a separate operation. Seed-word safety.

Plain language Updated 1 Aug 2026

Moving funds from an affected seed

For a single-signature wallet built from affected words, the mnemonic is the only secret protecting the balance. The order of these steps is what keeps a migration from creating a second problem.

No code. Written to be actionable.

Who this page is for

This page addresses single-signature wallets whose words were generated on the affected path, with no independently generated secret standing between the mnemonic and the coins. If the wallet is multisig, the first spend can publish a script that was previously hidden, which is a different and earlier problem: see migrating a threshold wallet before signing anything. If the generation path has not been classified yet, start with assessing your exposure.

A BIP39 passphrase changes the size of the remaining problem but not its shape. Once the mnemonic is recoverable, the passphrase carries the whole burden alone and candidates can be tested offline, so the passphrase page is the place to decide how much time that buys. The steps below are the same either way.

There is no hidden script to protect here A single-signature spend publishes nothing the search needed. Candidate seeds are tested by deriving standard-path addresses and checking them against the chain, so the addresses were already reachable before the transaction existed. The submission-route material on the multisig page exists to delay a script reveal; that reveal is not part of this case, and ordinary public relay with a competitive fee is the normal route.

The procedure, in order

  1. Generate a replacement seed on a device you can trust. Use fixed firmware, or a different, independently assessed signing device. The replacement words must be generated fresh. Do not re-derive them from the affected words, do not reuse any part of them, and do not treat a passphrase added to the affected mnemonic as a new seed. Installing the hotfix does not repair words that already exist: it changes what the device generates next. How to check your device's firmware version covers establishing what is actually running before you generate anything. If you would rather not depend on the device's generator at all, the pure-dice path starts from the roll string and bypasses it, subject to the roll minimums set out on the dice page.
  2. Verify the new backup and the master fingerprint before anything is sent. Record the new words, then check the record back against the device rather than assuming the transcription is correct. Confirm that the master fingerprint the device reports is the fingerprint your wallet software shows for the account you are about to use. A backup that has not been read back, and a wallet whose fingerprint has not been matched, are not yet a destination.
  3. Verify a receive address on the trusted device's own display. Read the address from the new device and compare it against the address the sending software shows. Compromised sending software can substitute a destination address; checking the signer's own display tests for that specific failure before funds are sent.
  4. Send a small test amount first, and confirm it. Send an amount you can afford to lose, wait for it to confirm, and check that it appears in the new wallet under the fingerprint you verified. Choose the confirmation and wallet-check threshold before starting. The old outputs remain exposed during any delay between meeting that threshold and sending the remainder.
  5. Sweep the remainder. Move the remaining outputs to the new wallet. Where you can, broadcast through a path that has not handled the affected seed's private keys, for example your own node or a wallet that holds only public data: if the affected words were ever typed into a recovery tool or a general-purpose computer, that environment should not also be the one that learns about the replacement wallet. Sign with replaceability enabled where your software supports it, so an underestimated fee can be bumped rather than leaving the transaction unconfirmed.
  6. Wait for confirmations, then inventory before retiring anything. Confirm that the sweep is buried, not merely relayed. Before the old seed is treated as finished, work out what else was derived from it: BIP85 children, seed XOR shares, device-generated paper wallets, encrypted backups and any second wallet built on the same words all inherit its generation history. What else is affected lists the call sites and states what each one does and does not settle.
  7. Retire the old backup so it cannot be mistaken for live. Once nothing of value derives from the old words, mark or destroy the backup according to how you store it. A retired backup left indistinguishable from a current one is how funds get restored back into an affected wallet months later. Never reuse the affected words for anything, including a low-value or decoy wallet: the search runs over candidate seeds rather than over particular wallets, so a small balance on those words is found by the same work.

Fees, and what waiting actually costs

A migration is an ordinary transaction and pays an ordinary fee. Waiting for a lower-fee period may reduce that cost, but it leaves the affected output in place. The first observed wave spent outputs from 500 source addresses inside four consecutive blocks, 960,188 to 960,191. That observation does not establish a deadline or a universal fee-versus-delay choice for another wallet. The balance, current fee, confidence in the exposure assessment and uncertainty in the published search models are separate inputs to the choice.

If the fee is a large fraction of a balance, moving it may cost more than the amount moved. The held evidence does not establish how any operator selects targets. Fee economics and exposure therefore need to be assessed separately for each wallet built on the affected words.

Nothing in this procedure requires disclosing recovery material No website, support account, insurer or migration service needs your seed words, passphrase or extended private keys to help you move funds. A transaction-submission service needs a signed transaction, not the material used to sign it. Protecting seed words during incident response covers the request patterns to recognise and what to do if recovery material has already been disclosed. As of 1 August 2026 this archive has documented no COLDCARD-themed phishing artefact from this incident, which is a statement about the archive rather than an assurance that none exists.

If you cannot complete the move now

Preparing and verifying the destination creates no on-chain transaction and can be completed before the fee decision. Moving only some outputs reduces exposure only for those outputs and can have fee and privacy consequences. Classification remains a separate prerequisite: an unresolved firmware or provenance question is not the same as a negative answer, and the risk overview sets out which facts settle it without touching recovery material.

Evidence and calculations are scoped beside the claims they support. Device-state attack-cost scenarios are compared in what an attack costs, with each source's assumptions written out. Where sources disagree, their scenarios are kept separate. If something here is wrong, say so.