The Coldcard theft that began on July 30 was not a conventional hardware wallet breach. The attacker did not need a victim’s device, PIN, seed backup or physical access. According to CoinDesk’s reporting on Galaxy Research’s analysis, the decisive failure was earlier in the wallet’s life: a flawed firmware configuration reportedly reduced seed generation to a predictable process. That turned the industry’s central promise, that private keys are computationally impossible to guess, into a much narrower question of whether an attacker could enumerate the possible seeds cheaply enough.
For years, hardware wallets have been sold on an intuitive security model. Private keys remain inside a dedicated device. Transactions are reviewed on a screen. Malware on a laptop may be able to propose a payment, but it should not be able to sign one without the owner’s approval.
That model still matters. Isolated signing hardware protects against a long list of real threats, including clipboard replacement, browser malware, remote-access tools and compromised desktop wallets. But the Coldcard incident exposed a boundary that is easier to overlook because it sits before the first transaction, before the first address and often before a user ever sees a recovery phrase.
A hardware wallet cannot protect a secret that was never secret.
CoinDesk reported that 1,082.65 BTC was swept from 1,196 wallets between 01:10 and 01:51 UTC on July 30, 2026. Its later coverage described further waves of activity. The initial incident matters not only because of the money involved, but because of its method. The attacker reportedly recreated candidate wallet keys offline, derived the addresses those keys would control, compared them with Bitcoin’s public ledger and swept funds from matches.
No device had to be touched.
This is the real security boundary of a self-custody wallet: not merely whether the device can hold and sign with a key in isolation, but whether its original key material came from enough genuine unpredictability that nobody else can recreate it.
A wallet begins with randomness, not with a screen
The phrase “seed phrase” can make wallet generation look more human than it is. A new wallet typically displays 12 or 24 familiar words, which users carefully copy onto paper or steel. But those words are a readable encoding of cryptographic data.
In the common BIP-39 design, a wallet first gathers entropy, meaning unpredictable random bits. That entropy may be 128 bits for a 12 word mnemonic or 256 bits for a 24 word mnemonic. The device adds a checksum and maps the resulting bit string into a standardized word list. The words are not the source of security. They are the backup format for the source of security.
The distinction is essential.
A 12 word phrase looks enormous because it is drawn from a list of 2,048 words. But its meaningful strength comes from the 128 random bits behind it. If those 128 bits are truly unpredictable, there are 2^128 possible values. That is a number so vast that testing each possibility is beyond practical computation.
If the process that produces those bits is predictable, the word count changes nothing. A 24 word phrase derived from poor inputs is not saved by having twice as many words. It only gives a weak secret a more impressive looking container.
The July 30 sweeps made that abstraction concrete. CoinDesk reported that a firmware setting caused affected Coldcard software to bypass its dedicated hardware randomness generator. A supporting library reportedly checked whether the relevant setting existed, rather than whether it was enabled. The wallet then fell back to a software randomizer seeded with a device serial number and clock state.
That is the point at which an impossible search can become a bounded one.
A serial number is not entropy. It is an identifier. It may be unique enough for inventory, support and manufacturing, but it is not intended to be unknowable. Clock values are also not entropy. They reflect time and device state. An attacker may constrain them through production periods, firmware release dates, observed setup behavior, measurements from comparable devices or simple assumptions about how people initialize a new wallet.
Together, these inputs can create variation. Variation is not the same as unpredictability.
The difference between a secure element and a random-number generator
Hardware wallet marketing often compresses several distinct security components into one reassuring idea: secure hardware.
That shorthand can mislead buyers. A secure element, a hardware random-number generator and a signing processor may all be part of a robust product, but they solve different problems.
A secure element is a specialized chip or protected environment designed to resist extraction and tampering. It can help isolate sensitive values, enforce access controls and make physical attacks harder. If an attacker steals the device, a secure element can raise the cost of recovering the private key.
A hardware random-number generator, often called an HRNG or TRNG, has a different job. It observes a physical process with unpredictable properties, then turns that observation into random data. It is intended to supply entropy when a wallet creates a new seed.
A deterministic random-number generator expands an initial secret state into a longer stream of values. This is often cryptographically sound when its initial seed is strong. It is not a substitute for entropy if its initial state came from predictable inputs.
A large-looking keyspace is simply an output range. It may contain billions, trillions or more possible values. That is not sufficient on its own. The security question is whether an attacker can identify, reproduce or enumerate the subset that the actual system could have produced.
Consider a lottery machine. A fair drawing may have millions of possible combinations. But if the machine always selects its numbers from the calendar date and a ticket serial number, the theoretical number of lottery combinations is irrelevant. The attacker does not have to search the full space. They search the much smaller space used by the flawed machine.
That is the core lesson of the reported Coldcard flaw. Isolated storage protects keys after they exist. Entropy ensures an attacker cannot generate the same keys independently.
How a weak seed becomes a spendable Bitcoin key
Once a wallet has created a mnemonic, its later key generation is deliberately deterministic. That is a feature, not a weakness.
BIP-39 takes the mnemonic and optional passphrase through a key-stretching process to create a 512 bit seed. A wallet then uses BIP-32 hierarchical deterministic derivation to turn that seed into a master private key and chain code. From there, it can derive an enormous family of child keys.
This is why one backup can restore an entire wallet. It is also why one flawed seed can expose every address generated from it.
A typical Bitcoin wallet does not use only one private key. It may create a new receiving address for every payment, separate change addresses for spending, accounts for different purposes and addresses that follow different script formats. Each of these emerges from the same original seed through public derivation rules.
A path might be expressed in a form such as m/84'/0'/0'/0/7. The components tell wallet software which branch of the key tree to use. The exact path matters because it determines the address a user sees. The process itself is standardized and reproducible.
The attacker in this case did not have to defeat BIP-32. They could use it exactly as wallet software does.
This is a useful correction to the common idea that a Bitcoin address hides a private key so thoroughly that the key cannot be found. That is broadly true when keys are produced with sufficient entropy. A secure private key is effectively a random number selected from an unimaginably large set.
But an address cannot reveal whether its key originated in a secure process. The blockchain records that an address received bitcoin. It does not record whether the wallet that generated the controlling key used a good random source, a broken fallback or a factory identifier.
The chain is public. The weak seed generation process, once understood, can also be public. The attacker’s task is to reproduce the generation process, not to crack the mathematics of Bitcoin.
The attacker’s offline search
The word “brute force” often suggests an attacker trying every possible Bitcoin private key. That would be futile. Bitcoin’s private key space is far too large for such a search.
The reported Coldcard case was different. The attacker was not scanning all possible keys. They were enumerating the much smaller set of seeds that affected firmware might have produced.
CoinDesk’s August 1 report said researchers estimated that later affected models could have had roughly four billion possible seed states. Four billion is a vast number for a person and a poor security margin for a well-resourced computer operation. It is also a finite engineering project.
An attacker can create candidate inputs based on plausible serial-number and clock combinations. For each candidate, they can run the same seed generation logic, derive likely BIP-32 branches and produce Bitcoin addresses. They can then compare those addresses with public address histories or unspent transaction output data.
A match is powerful evidence. If a candidate seed generates an address known to hold bitcoin, the attacker can derive the corresponding private key and create a valid transaction spending the funds.
The attack does not require a request to the wallet. It does not trigger a warning on the device. It does not need the owner to connect it to a computer. It may proceed while the Coldcard is powered down, stored in a safe or lost in a drawer.
This explains why the incident challenges the conventional meaning of “cold storage.” Cold storage reduces exposure to network threats. It does not solve a key generation failure that happened at setup.
The workflow also explains the address patterns cited by CoinDesk. The first wave included wallets across several Bitcoin address formats, including native SegWit and older formats. That pattern is consistent with systematic searching across derivation paths and wallet types. An operator looking for one individual victim would have little reason to search broad address families. An operator enumerating an exposed seed range would.
Why four billion can be economically small
A roughly four-billion-state search was tractable because the work could be divided across machines: each candidate produced a deterministic address, which an attacker could check against public blockchain data without ever contacting a victim.
Four billion possibilities sounds secure because it exceeds the number of people on Earth. Yet cryptographic security is not measured against human intuition. It is measured against the speed, cost and parallelism available to an attacker.
An ordinary laptop may not be the relevant benchmark. Candidate generation can be distributed across cloud machines, specialized compute, rented servers or a fleet of systems. The work is parallelizable. One machine can test one portion of the possible state space while another tests a different portion. Address derivation is predictable. Blockchain data can be downloaded, indexed and searched locally.
The economics get better as the attacker finds larger balances.
The attacker partitions the candidate seed range across workers, derives the resulting addresses locally and compares them against indexed UTXOs. Candidates associated with spendable outputs are prioritized by balance, allowing the operator to focus recovery efforts on the most valuable apparent matches.
The chart makes another point. The first reported wave was concentrated in larger balances. Subsequent reported sweeps hit more addresses for less bitcoin per address. That is what a search process can look like after its most profitable matches have been identified. Once the obvious high value targets have been swept, the operator can choose whether smaller balances still justify the marginal compute, transaction fees and operational risk.
This is why “only four billion” should not be read as a fixed answer to whether an attacker will act. The relevant question is whether the expected value of a search exceeds the total cost. If public addresses show a vulnerable population holding substantial funds, that calculation can be attractive even if each candidate requires several derivation paths and address checks.
A fallback is only safe when its seed is safe
Fallback logic is normally a mark of engineering maturity. Systems need to handle unavailable components, unexpected failures and degraded conditions. A wallet may need to respond if its randomness source fails a health test, returns too little data or cannot be initialized.
But cryptographic fallback behavior has a special rule: it cannot silently substitute predictability for randomness.
If a hardware random source is unavailable, the safe response may be to stop wallet creation, display a clear error and require the user to retry after an update or service action. A less disruptive alternative is to combine multiple independent entropy sources so that the failure of one does not destroy security.
For example, a robust design may gather entropy from a dedicated hardware random source, processor jitter, user supplied dice rolls or another independent mechanism. It can combine these values through a cryptographic hash. If at least one source supplies unknown, high quality entropy, the combined result can remain unpredictable.
That design still needs careful implementation. Sources must be tested for failure. The system must avoid accepting all-zero outputs, repeated blocks or obvious device faults. Engineers should be able to review exactly what happens when a source is unavailable. A configuration flag that merely exists should never be treated as evidence that the underlying protection is active.
The issue reported by CoinDesk was not that deterministic software is inherently bad. Most secure systems use deterministic generators after receiving good seed material. The failure was that reportedly predictable metadata became the root input for a process that users and developers expected to be cryptographically random.
A wallet manufacturer should regard seed creation as a security critical ceremony, not a background function.
What robust wallet design should include
The first requirement is independent entropy sources. A dedicated hardware random-number generator is valuable, but the strongest practical approach is often to mix it with one or more additional sources. The product should define precisely how it combines them and should document the failure behavior.
The second is continuous entropy health testing. The device should detect obvious problems such as repeated output, stuck bits or unavailable hardware. Health tests cannot prove that a source is unpredictable, but they can detect classes of failure that should block seed generation.
The third is fail closed behavior. When the wallet cannot establish adequate entropy, it should refuse to generate a new seed. A clear error is inconvenient. A silently predictable wallet is catastrophic.
The fourth is reproducible builds and firmware provenance. Security researchers and sophisticated users should be able to verify that published source code produces the firmware image distributed to devices. Signed firmware alone proves that a vendor signed an update. It does not, by itself, prove that the code users can inspect is the code the device runs.
The fifth is configuration testing that evaluates behavior, not declarations. A test should not merely ask whether USE_HARDWARE_RNG exists. It should confirm that a generated seed actually incorporated output from the intended source. This may require test instrumentation, simulated hardware faults and code review around every fallback branch.
The sixth is independent audit and adversarial testing. Wallet vendors should ask testers to assume that a hardware component is disabled, a build flag is wrong or manufacturing metadata is exposed. The question is not only whether the device resists physical extraction. It is whether every path to key creation preserves sufficient uncertainty.
The user controls that still matter
For wallet owners, the incident should not produce the wrong conclusion that hardware wallets are pointless. The better conclusion is more demanding: a secure setup must combine trustworthy seed generation, isolated signing and disciplined operations.
A user creating a new wallet should consider whether the device permits entropy from verifiable physical inputs, such as dice rolls. Dice do not make every setup automatically safe, because the user must roll, record and enter the values correctly. But they can provide an independent source that does not depend on opaque firmware behavior.
Users should also understand the role of a BIP-39 passphrase. A passphrase can create a separate wallet namespace on top of the mnemonic. It can be a meaningful extra layer if it is unique, sufficiently strong and backed up with the same care as the words. It is not a repair for an already exposed seed when the attacker may have discovered funds and can monitor them. It also creates a new failure mode: a forgotten passphrase can permanently strand the owner’s assets.
Multisignature designs can reduce dependence on any one wallet seed. CoinDesk’s early reporting said the observed pattern was consistent with exposure of single-key seeds rather than multisignature setups. That does not make every multisignature arrangement safe. The devices, seeds, coordinators and backup procedures still matter. But requiring independent keys from separate sources can prevent one defective seed generator from becoming a complete loss.
The practical principle is simple: avoid putting every security assumption in one product, one firmware build or one secret.
Migration is not an update, it is a new root of trust
When a wallet maker identifies a seed generation defect, updating the firmware is necessary but not enough. Firmware updates can stop future weak seeds from being created. They cannot add entropy retroactively to a seed that was already generated predictably.
CoinDesk reported that Coinkite released emergency firmware and urged potentially affected users to move funds to fresh addresses. That advice reflects the correct model. The owner must create a new wallet using a corrected and trusted generation process, verify the new backup and transfer funds to addresses derived from that new seed.
The order matters.
First, owners need to identify whether their wallet was initialized on potentially affected firmware. If the answer is unclear, the conservative approach is to treat the seed as exposed. Second, they should obtain and verify the vendor’s remediation guidance through authenticated channels. Third, they should create a completely new wallet, not merely a new receiving address from the old seed. Fourth, they should verify a small test recovery before transferring significant holdings. Finally, they should move all funds, including change, account balances and assets stored on less commonly used derivation paths.
A new address from the same old mnemonic is not a migration. It is a new label on the same compromised root.
The same standard applies to organizational custody. A company cannot treat migration as a routine software patch delegated to one administrator. It should have a documented playbook, dual control over new key generation, independent verification of destination addresses, transaction limits, monitoring and a way to prove that old signing material has been retired.
For businesses building wallet products, the incident is also a product design warning. Recovery instructions must be prepared before an emergency. Users need clear model and firmware identification, precise setup histories to review, simple steps for creating a fresh seed and support channels that cannot be easily impersonated by scammers.
The boundary that hardware wallets must now prove
The Coldcard theft does not erase the value of secure elements, air gapped signing or transaction review screens. Those controls defend against different, persistent threats. A wallet that exposes a private key to a browser extension is still weaker than one that keeps signing operations in dedicated hardware.
But isolated signing hardware is only half the security claim.
The other half is that the wallet’s root secret was generated from genuine entropy, with implementation paths that preserve that property under fault conditions. A secure element can guard a seed. It cannot make a predictable seed unpredictable after the fact. A beautiful interface can display 24 words. It cannot tell a user whether those words came from 256 bits of uncertainty or a repeatable sequence rooted in device metadata.
The industry should therefore judge wallet security claims in two layers.
First, can the product protect a key after it has been created? That is the familiar hardware security question.
Second, can the product demonstrate that nobody else could have created the same key independently? That is the entropy question, and it is the one that determines whether cold storage is truly cold.
That demonstration should be concrete enough for an outside researcher to reproduce. A wallet maker should publish the exact source code that reads every entropy source, combines its output, performs health checks and handles every fallback path, including the build-time and run-time conditions that can disable a hardware random-number generator. It should publish fault-test results showing that seed creation stops, rather than quietly switching to predictable inputs, when the hardware RNG is unavailable, returns repeated output, fails initialization or produces data that does not pass defined health checks.
The company should also provide reproducible-build instructions, release hashes and a public record showing that the published source produces the firmware image users install. And when a defect is found, it should maintain a version-by-version list of affected devices and firmware releases, state the dates and conditions under which those versions generated vulnerable seeds, and give owners a documented migration sequence: how to identify exposure, verify the replacement firmware, create a new seed, test recovery, move funds across every relevant derivation path and permanently retire the old mnemonic.
Those are evidence that users, auditors and researchers can inspect. Without them, “secure hardware” remains a claim about a black box. With them, a wallet maker can show not only that its device protects a key after creation, but that its seed-generation process fails safely, can be independently verified and gives owners a workable path when that assurance is lost.
