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

Attack-time estimator

Combine source-labelled device models with uniform passphrase or dice assumptions, then change the candidate rate to see how the result moves.

No code. Written to be actionable.

This estimator turns the site's static attack-cost tables into an interactive sensitivity model. It keeps each published device scenario separate, because Block, Coinkite, LLFOURN and otaliptus make different assumptions about UID, timer, RTC and attacker knowledge. Selecting a model does not endorse it or establish that it applies to a particular device.

Classify the firmware path first These scenarios apply only after the mnemonic has been classified as generated through affected firmware. Pre-regression Mk2/Mk3 mnemonics and mnemonics generated after the model-specific hotfix are outside this calculator. Start with Your risk if that provenance is not established.
Do not enter wallet-specific data Choose a word-list size, character alphabet, roll count or ideal bit estimate. Never enter seed words, a passphrase, dice-roll sequence, address, xpub, descriptor or private key. The calculator does not need them.

Interactive sensitivity model

Build an attack scenario

Select descriptions of how secrets were generated. Do not enter wallet-specific data. The estimator script does not transmit inputs or write them to browser storage; current selections remain in page memory.

1. What does the attacker still need to search?

This mode estimates the work to find a mnemonic from the selected device and dice model.

2. Describe mnemonic generation
3. Set a candidate-check rate

This is a sensitivity input, not a measured benchmark. One check means testing a complete candidate against the target wallet data. Device-state and PBKDF2 passphrase checks may have very different real rates.

Illustrative result

Choose a published device scenario to calculate the search time.

How to read the result

  • Half-space is a sensitivity convention. The estimator uses half the enumerated space, with a minimum of one check. This assumes a uniformly positioned target and no better search ordering; it is only a large-space approximation.
  • The rate is not a hardware claim. A candidate check must reach the available address, public key or xpub target. Raw device-state enumeration and BIP39 PBKDF2 plus wallet derivation may run at very different rates.
  • Combined mode is conditional. Device and passphrase bits add only when both independent factors must be searched together. If other wallet data lets the attacker identify the mnemonic separately, use passphrase-only mode for that case.
  • Mixed dice is output-capped. Fair, independent and secret rolls can add a separate term to a device candidate space, but a 12-word mnemonic carries at most 128 bits of entropy and a 24-word mnemonic at most 256 bits.
  • Pure dice replaces the device model. The result is bounded by the smaller of roll entropy and mnemonic output size. It assumes accurate entry and no disclosure of the roll sequence.
  • BIP39 output has a 512-bit ceiling. Passphrase-only and combined results cannot exceed the number of distinct BIP39 seed outputs. A particular wallet-data target can impose a lower effective collision boundary.
What is not modelled Multisig depends on threshold, script or descriptor exposure and whether individual co-signer targets can be tested separately. Human-chosen passphrases depend on attacker-specific information. Neither can be reduced to a defensible universal bit slider, so use the multisig analysis and passphrase assumptions instead.

A long displayed time is not a recommendation to delay. Published scenarios remain unverified for an individual wallet, compute rates can change and a passphrase or mixed-dice term does not repair the original mnemonic. Use the model to understand sensitivity, then follow the migration guidance for decisions about funds.

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.