Protecting seed words during incident response
Exposure assessment and ordinary support do not require seed words. Deliberate entry into an independently verified offline signer or recovery tool is a separate operation.
No code. Written to be actionable.
Do not send or type recovery words into a remote website, form, support chat, email or message. A vendor, investigator or insurer does not need them to determine whether this generator affected you. Seed entry is appropriate only when you deliberately restore or sign with an independently verified signer or offline recovery tool under your control.
What exposure assessment requires
Classifying the generation path uses provenance and configuration facts, not recovery material. The relevant questions are:
- Original generation source. Importing words into another device later says nothing about where they were first generated.
- Model and firmware at generation. A date can identify a likely release era, but the installed version at generation is the stronger fact.
- Dice workflow and roll count. Pure-dice generation and dice mixed into a device-generated seed use different paths. The roll sequence is itself secret key material: on affected firmware the device also displayed a running SHA-256 digest during entry, and the final value shown became the seed. Never share a roll record or a photograph of that screen.
- Passphrase construction and disclosure. This changes the remaining offline search, not the original mnemonic's generation history.
- Wallet policy and information exposure. For threshold wallets, count affected keys on each path and determine what script, descriptor and public-key information is available.
The first three items establish whether the affected generator was involved and what independent dice input may exist. The last two shape the wallet's risk and migration plan. None requires seed words, a passphrase, private keys or an extended private key.
The triage on the front page asks these category questions, and its component does not transmit or persist the answers. If generation provenance or firmware is unknown, use the conservative branch and check device records before treating the seed as outside the affected range.
A specific address can be checked against a published transaction set without revealing seed words. An extended public key allows a much broader view of wallet structure, balances and history. It does not ordinarily grant spending authority by itself, but it is sensitive non-secret data. Prefer self-run tooling and disclose only the narrowest public information needed.
Unsafe requests to recognise
As of 2 August 2026, this archive holds one documented impersonation artefact from this incident: a Telegram account presenting itself as COLDCARD WALLET, published by Jameson Lopp and recorded in full on the scams page. It has not documented a COLDCARD-themed phishing site, fake checker or fake firmware build. The source registry is not exhaustive, so that absence is not evidence that no such artefact exists. The examples below are preventive request patterns rather than a catalogue of confirmed cases.
| The pitch | How it is framed | What gives it away |
|---|---|---|
| Vulnerability checker | "Enter your recovery phrase to check whether your seed was generated with weak entropy." | Generation-path classification uses provenance, model, firmware and dice facts. Submitting the words would expose the unpassphrased keys and, where target wallet data is known, enable offline testing of passphrase candidates. |
| Emergency migration tool | "We will sweep your funds to a new secure wallet automatically. Paste your words to begin." | A remote service that receives the words can derive the unpassphrased keys and, where target wallet data is known, test passphrases offline. A transaction-submission service needs a signed transaction, not the material used to sign it. |
| Vendor support | A DM or email offering to help you recover, then asking for words "to verify ownership". | Ordinary support and incident-exposure assessment do not require seed words. Confirm the contact channel independently before sharing even non-secret account information. |
| Fake firmware | A "patched" build offered from somewhere other than the official download page. | Confirm the release through an independently verified vendor channel and check its signature or hash using the vendor's documented process. Firmware installation does not require submitting seed words to a website. |
| Compensation or claim form | "Affected users are eligible for reimbursement. Verify your wallet to claim." | A claim may request identity or public transaction evidence. Seed words, private keys and extended private keys are not evidence of incident exposure. They expose key material and, when enough signing material is supplied to meet the wallet policy, grant spending authority. |
When offline seed entry is appropriate
Wallet recovery can require entering a mnemonic into a signer or recovery application. That operation is distinct from sending it to a remote party when all of the following are true:
- The signer or recovery tool was selected deliberately, not through an unsolicited message or incident-response link.
- Its hardware, software and release provenance were checked independently before the words were entered.
- The recovery environment is under your control, appropriately isolated, and free of remote-access or screen-sharing software.
- Wallet fingerprints, receive addresses and any migration transaction are verified on a trusted display.
Offline operation alone does not establish that a tool is authentic or safe. Entering a seed into a general-purpose computer also expands the set of systems that may retain or expose it. Giving a professional recovery provider the seed delegates sensitive key material and, where target wallet data is known, enables offline passphrase testing. Giving that provider enough signing material to meet the wallet policy delegates spending authority. Neither is an ordinary support interaction.
If recovery material was disclosed remotely
If seed words were submitted to an untrusted site, person or remotely controlled system, treat them as potentially known to another party. This is a conservative risk assumption, not proof that the recipient has used them. The appropriate response depends on the wallet policy and on whether a passphrase or other secret was also disclosed.
- Stop further disclosure and record what was exposed. Close the interaction, isolate any device on which untrusted software was installed, and note whether the mnemonic, passphrase, descriptor or other wallet data was provided.
- Prepare an independently generated destination. Use the model-specific fixed release whose provenance and compatibility you have checked, or another independently assessed generator. Verify the new backup, wallet fingerprint and receive address before moving value.
- Use a wallet-specific migration plan. A single-signature wallet with no undisclosed passphrase has no remaining independent secret; the ordered steps for that case are on moving funds from an affected seed. For P2WSH and other threshold policies, read the script-disclosure guidance before broadcasting, because the first spend can change what an observer learns.
- Assess passphrase exposure separately. If the passphrase was also disclosed, it provides no independent protection. If only the mnemonic was disclosed, passphrase candidates can be tested offline and the remaining margin depends on how the passphrase was generated.
- Rotate every affected use and backup. Inventory wallets and retained backups derived from the disclosed seed. Do not reuse the old seed or a passphrase that was disclosed with it.
- Preserve evidence and report the incident. Keep the URL, transaction identifiers and correspondence without reopening the unsafe interaction. Report through independently verified service, vendor and law enforcement channels as appropriate.
What this site's triage processes
The triage has no fields for seed words, passphrases, private keys or extended private keys. Its script makes no network request and does not write answers to browser storage; it keeps the current answer path in page memory. The same decision path is written out on Your risk for readers who prefer not to use the interactive component.