What Coldcard Got Wrong and Why Self-Custody Still Stands

There is a particular kind of shock in seeing bitcoin move from a wallet you believed had been secured years ago. The device may still be where you left it. The recovery words may still be hidden. Nothing appears disturbed, copied or exposed. Yet the balance is gone, and the blockchain records a transaction you did not make.

For some Coldcard users, that was the reality at the end of July. These were not all obvious cases of careless storage, compromised computers or recovery phrases handed to scammers. All affected holders had generated their seed on the device, written it down, kept the signer offline and left the wallet untouched for years. They had followed the normal logic of hardware-wallet security: isolate the keys, protect the backup, and avoid contact with internet-connected devices.

Unfortunately, taking these steps did not protect them, and on July 30th rumours started to circulate that Coldcard hardware wallets had been compromised and funds were being swept. The first person to notice was Kevin Loaec:

The attacker didn’t need to steal the Coldcard, bypass its PIN, or gain access to the paper copy of the seed phrase. Bitcoin that had remained dormant could be spent remotely by someone who had never even entered the room where the Coldcard was stored. That is what makes this incident so serious. The attack reached beyond the threats most holders had been trained to recognize. There was no fake support conversation to remember, no suspicious transaction to reconstruct, and no obvious moment when the owner surrendered control. The weakness was already present inside wallets whose owners reasonably believed the difficult part had been completed.

Once the exploit had begun, the funds began moving in waves. As of August 7th, on-chain researchers had mapped approximately 1,596 BTC swept from around 7,300 addresses, with broader estimates including suspected and pattern-matched activity reaching roughly 2,055 BTC. Those addresses do not represent 7,300 confirmed individuals, and the totals may continue to change, but the scale is no longer in doubt. The opening wave alone moved approximately 1,083 BTC in roughly 40 minutes.

The speed of the attack added another layer of cruelty. A holder could have spent years accumulating patiently, checked the wallet only occasionally, and discovered the loss after the transaction had already settled. Meanwhile, researchers, users and the manufacturer were still trying to establish which devices, firmware versions and wallet histories were exposed. The technical details matter, but they shouldn’t be used to distance us from the people affected. The victims trusted a specialist Bitcoin wallet manufacturer to perform the most basic task expected of the product: create a secret that nobody else could reproduce. They were severely let down.

That deserves to be acknowledged without immediately reaching for an advanced configuration they supposedly should have used. Private dice rolls, passphrases and multisig may have protected certain wallets, but their existence doesn’t excuse a standard seed-generation process that produced seeds with far less randomness than users were entitled to expect. Coldcard’s failings here are serious.

It is easy to understand why the incident has unsettled confidence beyond Coldcard’s existing customers. Hardware wallets are sold as the point where abstract cryptography becomes something an ordinary holder can use. Most people cannot inspect random-number generators, build configurations or verify the way firmware combines several security components. They have to “trust” that the device will perform its foundational task correctly before they take responsibility for everything that follows.

The incident materially undermined that trust. The harder question is what follows from it. If the device remained secure, the backup remained private, and the attacker never needed physical access, where did things actually break down?

‍

How Coldcard Shrunk the Search Space

A hardware wallet has three foundational jobs.The first is to create the wallet from enough unpredictable randomness (aka entropy) that nobody else could realistically recreate. The second is to protect the private keys once that wallet exists. Those jobs happen in that order, and the distinction matters.

A hardware wallet doesn’t hold bitcoin in the way a physical wallet holds cash. The bitcoin remains recorded on the network. What the device protects are the private keys that give the owner the authority to spend it. When a new wallet is created, the device first produces a very large secret number. Writing that number down as a long string of digits would be impractical, so the wallet translates it into a list of ordinary words chosen from a fixed dictionary.

The third is to allow those private keys to be used without exposing them to an internet-connected device. This is where air-gapped transactions come in. Instead of connecting the hardware wallet directly to a computer or phone, an unsigned transaction can be transferred to the device using a QR code or microSD card. The hardware wallet then verifies the transaction and signs it internally, using the private keys it protects.

That system is known as BIP-39, although the name matters less than the idea. The seed phrase is simply a human-readable way of recording the secret from which the wallet can be rebuilt. Think of it as translating a long computer code into a short series of labelled boxes. Each word represents part of the original number. A small error check is included too, similar to the final digit on a bank card or the check built into a barcode. It helps the wallet recognize when one of the words has been entered incorrectly, but it doesn’t add any extra security to the secret itself.

The owner writes down those words as the seed phrase. Together with any optional passphrase, they allow the wallet to recreate the same private keys and addresses in the future. That makes the seed phrase more than a password. Anyone who can recreate the same underlying secret can recreate the same wallet. Once that secret has been created, the hardware wallet’s other protections take over. The private keys remain isolated from the phone or computer preparing a transaction. The PIN restricts access to the device. Secure elements make it harder to extract what’s stored inside. The screen lets the owner verify what the device is being asked to sign.

These protections are very useful. But only if the secret they are protecting is truly secret.

Coldcard’s failure happened before any of those defenses became useful. The security of a seed phrase doesn’t come from the words looking unusual. It comes from the number of possible phrases from which it could have been selected, and from how unpredictable that selection was. That unpredictability is called entropy. A properly generated 24-word seed phrase represents 256 bits of entropy.

The number of possible seeds is on roughly the same scale as estimates for the number of atoms in the observable universe. Imagine assigning every possible seed phrase to one atom somewhere in that universe. One atom is selected, and an attacker is asked to identify it. The atom exists. In theory, it could be found. In practice, the search is so vast that it’s considered beyond reach.

Coldcard was supposed to choose from that entire universe. What happens when the device chooses from a microscopic droplet instead? On the most exposed Mk3 devices, the affected code reduced the practical search to something closer to a microscopic droplet of water. The correct atom was still hidden, but it had been chosen from a vastly smaller place. The metaphor isn’t an exact scientific conversion, but captures the change that mattered: instead of facing the full universe of possible seeds, an attacker faced a dramatically reduced field.

Coldcard hadn’t exposed the seed phrase directly or transmitted it across the internet. The affected code had created some wallets using far less unpredictability than users were entitled to expect. The resulting seed phrases still looked completely normal. They contained valid words, passed the built-in error check and produced ordinary Bitcoin wallets. Nothing about the written phrase told the owner that it had come from a much smaller set of possibilities.

In simple terms, what this means is that because the seeds were not created from enough randomness, they were easier for the attacker to ‘guess’ by using computational brute force.

Random-looking and unpredictable aren’t the same thing. A predictable process can produce an output that appears chaotic. If you don’t know how it began, the result may look completely random. Someone who understands the starting conditions, however, may be able to reproduce it. Hashing that output can make it look even more uniform, but it can’t create possibilities that weren’t present at the beginning. Putting a weak secret through sophisticated mathematics may disguise the weakness, but it doesn't remove it.

For affected Mk3 firmware, Coinkite estimated roughly 40 bits of effective search space according to its own numbers. That represents around one trillion possible states. A trillion sounds enormous in ordinary life. In cryptography, it’s a very different proposition. Every additional bit doubles the number of possibilities. The difference between 40 bits and the 128 bits expected from a standard 12-word seed isn’t a modest reduction. A 128-bit search space is roughly 300 septillion times larger. In other words, the difference between “practically impossible” and “a determined attacker with enough compute and a quiet afternoon”.

Later Coldcard models were affected differently. The Mk4, Q and Mk5 incorporated material from their secure elements, but only 32 bits of that material reached the reseeding process. Coinkite estimated a ceiling of roughly 72 bits for those devices. That was noticeably less broken than the exposed Mk3 path, although still well below the intended security level. We still don’t know how practical the attack on later models will be but so far there are very few reports of compromised MK4 and CCQ HWWs.

‍

The Code Change That Opened the Wrong Path

The weakness entered Coldcard firmware in March 2021 through a change that looked almost routine. Until then the device created new wallets by drawing randomness straight from its hardware generator. However, the updated code bypassed the hardware and asked a different software library for random bytes instead.

Because of the way Coldcard’s build settings interacted with the library, the request was silently routed to a deterministic fallback generator used by MicroPython. Instead of drawing fresh unpredictability from the hardware, the device began producing numbers from a much smaller internal state based partly on device identifiers and timing values. The firmware still compiled. The seed phrase still looked valid. Addresses appeared normally, and transactions signed as expected. The software did the one thing security software is rarely criticised for: it kept working.

There were no obvious issues in how the Coldcard devices functioned, allowing the vulnerability to remain hidden in plain sight.

That helped the mistake survive for more than five years. It’s tempting to blame one infamous line of code, but the deeper failure was the system around it. The wallet-generation function called a library and that library interpreted a build setting incorrectly. Instead of the device then refusing to continue, it simply re-routed to a non-cryptographic fallback and any subsequent health checks the device performed did nothing to highlight the problem.

Every component did just enough to keep the product running. Together they sent the wallet’s most important secret down the wrong path. For the most exposed Mk3 devices, that path was reproducible enough for attackers to exploit. They could generate possible seeds on computers, derive the Bitcoin addresses those seeds would create, and compare them with public wallet information. Bitcoin’s public blockchain became the treasure map.

The frightening part was the asymmetry. The owner may have spent years protecting the Coldcard, the PIN, and the seed phrase. The attacker didn’t need any of them. Public information was enough. A Bitcoin address or an extended public key was all it took to test candidate seeds in private, one after another, until the same wallet appeared on their screen. That’s why physical security offered no protection against this attack. The PIN still guarded the device. The secure elements still guarded what was stored inside them. The air gap still kept the signing process away from an internet-connected computer.

The attacker had simply made all of that irrelevant. Once they held the private keys, Bitcoin treated their signatures exactly like any others. The network doesn’t know who bought the hardware wallet, who wrote down the seed phrase or which device produced the signature. It checks the mathematics. When the signature is valid, the transaction is accepted.

A brutal reminder of one of Bitcoin’s most important rules. Not your keys, not your coins.

Bitcoin worked exactly as designed. That distinction offers little comfort to somebody staring at an empty wallet, but it matters when deciding what failed. Nobody broke Bitcoin’s cryptography or discovered a shortcut through the network’s rules. They exploited a specific mistake in the way Coldcard generated certain wallets.

The fact that Coldcards were verifiable source adds one final discomfort. The vulnerable code had been public for years. That transparency eventually allowed researchers to trace the failure through exact commits, libraries and build settings once thefts had begun, but it didn’t prevent the attack from happening in the first place. The fear that followed is understandable. However the conclusion that self-custody itself failed is not.

‍

The Wrong Lesson is to Give the Keys Back

After watching careful people lose their bitcoin through no obvious mistake of their own, the appeal of handing the responsibility to somebody else is easy to understand. Buy IBIT, leave the coins on an exchange, and let institutions handle the keys, backups and operational security.

That choice does remove some risks. An ETF investor can’t lose a seed phrase they never held, and an exchange customer doesn’t need to build a recovery plan or explain multisig to their family. For some people, those trade-offs may be reasonable. But the risk hasn’t disappeared. It has only moved.

IBIT gives you shares in a trust whose value follows bitcoin. It doesn’t give an ordinary investor spendable bitcoin that can be withdrawn to your own wallet. An exchange gives you a balance inside its system while the platform controls the keys, sets the withdrawal conditions, and decides what happens when its compliance department, banking partners or regulators become interested.

You’re not holding Bitcoin, you’re holding an IOU.

Both can work beautifully while the rules remain friendly. So does every permissioned system. The difference appears when permission is withdrawn. Bitcoin lets you hold and move value without asking an institution to recognize your claim, approve your withdrawal or keep your account open. An ETF or exchange puts those decisions back in someone else’s hands. Frozen withdrawals, capital controls and political pressure only need to reach the broker, custodian or exchange standing between you and the asset.

That’s why the response to Coldcard matters. One vendor failed at generating secure keys, so the proposed solution is to return the keys to organisations whose entire role is deciding when customers may use them. The hardware risk vanishes. In its place come custody, access, insolvency, surveillance and legal dependencies. A surprisingly efficient exchange of problems, provided nobody looks too closely at the receipt.

FTX was one of the world’s largest centralized exchanges until it collapsed into bankruptcy on 11 November 2022. Customers saw bitcoin balances and were told their assets were held in custody; regulators later found that customer funds had been commingled and misappropriated. The first eligible customers waited 28 months for repayments to begin, and even then they didn’t receive their bitcoin back. Their holdings had been converted into dollar claims using November 2022 prices. One bitcoin became a claim worth roughly $16,900, plus applicable interest, while bitcoin was trading near $95,000 when the first distributions arrived in February 2025. The screen had displayed bitcoin. The bankruptcy returned a fraction of its later dollar value.

IBIT seizures may not happen. But the precedent matters because an asset held through brokers, custodians and regulated trusts remains inside a system that can rewrite the terms when pressure rises.

Self-custody exists because ownership and a claim to ownership aren’t the same thing. Coldcard proved that holding your own keys demands vigilance and that no manufacturer deserves blind faith. It didn’t prove that an exchange balance, an ETF share or a government-regulated promise becomes preferable, especially when the stakes are highest. One vendor made a serious error. Giving the keys back would be learning exactly the wrong lesson.

‍

Dust Off the Setup Before Someone Else Tests It

Coldcard’s seed-generation failure shouldn’t send people running back to exchanges. It should send them back to their own setup.

We have already shared guidance on this, but it bears repeating in case anyone missed it. If your wallet seed may have been generated using affected Coldcard firmware without sufficient independent entropy, don’t assume that updating the firmware, restoring the same words on another device, or changing wallet software will repair the original seed. A seed that may have been weak when created should be treated as compromised.

The correct response is to move the funds to a completely new wallet created from fresh, using independently generated entropy using a verified process. However, the safest order of steps may differ depending on the firmware version, device condition, passphrase use, wallet setup, backups, and the person’s ability to complete the migration safely. You shouldn’t rush into a firmware update, seed recovery, test transaction, or transfer unless you understand exactly what each step does. A mistake made while trying to move quickly can create an additional risk.

Take your time.

Never share or screen-share your seed words, passphrase, PIN, private keys, or backup files with anyone. We are assisting affected clients individually because this is not a situation where one generic checklist is safe for everyone. Anyone who is uncertain should get qualified guidance before taking action.

For everyone else, this incident hasn’t uncovered the same RNG defect across every hardware wallet. It was a specific failure in Coldcard’s firmware, libraries and build configuration. That doesn’t prove other manufacturers are flawless. It means each device has to be judged on its own design rather than bundled into one ecosystem-wide panic. Still, the lesson is useful. Most people allow the hardware wallet to create all the randomness behind their seed, which means trusting the manufacturer to get that process right. Anyone who no longer wants to outsource the entire process should generate their own entropy.

There are several documented methods for doing this with dice rolls, coin flips, shuffled cards or other physical sources of randomness. Generating your own entropy can reduce reliance on the manufacturer, but only if the process is carried out correctly. Improvising the process is how sovereignty turns into an expensive maths experiment. At least 50 fair, independent and private rolls contribute 128 bits of entropy; 99 or more contribute roughly 256 bits. The rolls must remain private and be entered correctly.

That isn’t an excuse for Coldcard. Users were entitled to expect the normal setup to work. It’s simply a way to reduce dependence on any one manufacturer’s random-number generator. The same principle applies more broadly: know where the seed came from, test the recovery, and ask whether one device, vendor, location or knowledgeable person can bring the entire setup down.

‍

Self-Custody Is a Practice, Not a One-Time Decision

Nothing in this lesson reduces Coldcard’s responsibility. People trusted the standard setup, followed the guidance and lost bitcoin because the product failed at its most important task. They deserved better. But abandoning self-custody would give that failure more power than it deserves.

Self-custody was never supposed to mean buying a box, hiding it in a drawer and assuming the problem had been solved forever. Devices age. Firmware changes, backups deteriorate, people move, families change and recovery plans written years ago stop reflecting reality. A hardware wallet is only part of the setup. It isn’t the setup itself.

A hardware wallet should never represent a single point of failure, which is why using secure passphrases or creating your own entropy were pivotal in protecting the Coldcard users that did not have their funds swept.

The real work is understanding where control depends on one thing going right. Perhaps it’s the device that created the seed, the only copy of a backup, a passphrase nobody else can recover, or one person carrying the entire plan in their head. Those dependencies can remain invisible for years.

Coldcard showed what happens when one of them is exposed by someone else first. That doesn’t mean everyone needs an elaborate multisig arrangement, three continents and a family meeting chaired by a cryptographer. Complexity can become its own failure point. The goal is a setup you understand, can recover and have tested under realistic conditions. As the value and consequences rise, the standard should rise with them.

The best way to increase your security is to increase your knowledge.

This principle shaped how we prepared for extreme scenarios long before this incident. We worked from deliberately conservative assumptions, built redundancy into the process and avoided relying on any single device, vendor or component. This event put that approach under real pressure and, thankfully, it worked as intended. We’re now taking the same philosophy further, with stronger safeguards, deeper verification, greater redundancy and even less reliance on any single component. The thinking hasn’t changed. The standard has.

That same approach is what we help you to build. We review how your keys were created, identify hidden dependencies and single points of failure, test recovery and develop a security plan that remains usable when circumstances change. You shouldn’t have to discover the weak point in your setup during an emergency.

Book a free 30-minute introductory call with one of our advisers and take the first step towards a setup built around your circumstances, competence and long-term needs.