Look at the number first: $70 million. That is roughly the value Galaxy Research now attributes to a single wallet exploit involving Coldcard, the Bitcoin hardware wallet widely regarded as the gold standard for paranoid self-custody. The initial estimate was smaller, nearly half of that figure. The fact that the loss has been revised upward by almost two times tells me something important: this is not a finished incident. This is an evolving attack surface revealing itself in disclosure increments.
The error was not in the code, at least not yet publicly confirmed. The error is in the assumption. For years, the industry has whispered a comforting mantra: keep your keys on a Coldcard, keep your bitcoin offline, and you are untouchable. That narrative has now collided with reality, and the impact is not just a dent in one company's reputation. It is a fracture in the entire mental model of what hardware wallets actually protect.
CZ, speaking in his now-familiar role as the industry's loudest risk commentator, put it bluntly: "Nothing is 100%." He advised Bitcoin holders to spread funds across multiple wallets. That sounds like common sense, but behind that common sense lies a deeper technical truth that most users do not want to face. If a Coldcard can be exploited, then the private key is not the only attack vector. The trust chain itself is compromised.
Tracing the gas trails back to the root cause requires us to ask a question nobody at the headline level is asking: what exactly was exploited? A firmware bug? A supply-chain interception? A compromised signing process? Or something more mundane, like a sophisticated transaction substitution attack that rendered the hardware wallet's display reliably but falsely? We do not know. And that ignorance is the most dangerous part of this event.
Let me be clear about what I am not saying. I am not saying Coldcard is a bad product. I have spent years in smart contract audits, and I know that security is never absolute. Every layer of a system has its own risk profile. But a hardware wallet is a layer that we have collectively chosen to trust almost unconditionally. When that layer breaks, the entire security architecture built on top of it needs re-qualification.
This article will walk through the technical context of the exploit, the flawed assumption at the heart of hardware wallet adoption, the blind spots that this incident exposes, and what the next few months will reveal. I will also tell you, based on my experience auditing multi-signature and custody systems, why the solution is not to abandon self-custody or to rush back to exchanges. The solution is to stop treating any single device as a root of trust.
The Context: Coldcard's Reputation and the Architecture of Trust
Coldcard, produced by Coinkite, holds a unique position in the Bitcoin ecosystem. It is not the most user-friendly hardware wallet. It is not the most visually polished. What it offers is a very specific promise: a minimized attack surface, open-source firmware, and a design philosophy that prioritizes security theater reduction. For Bitcoiners who understand the difference between a Trezor and a multisignature quorum, Coldcard has long been the device of choice.
Its architecture is built around a secure element and a deliberately austere interface. Transactions are reviewed on a small screen, and the user confirms them with physical buttons. The private key never leaves the device. In theory, even if your computer is infected with malware, the attacker should not be able to extract your keys. In theory, even if a malicious transaction is broadcast, the hardware wallet's display would show the true destination address.
That is the promise. And this is where the industry's collective throat tightens: a $70 million theft has occurred, and we do not yet know whether that promise was broken at the hardware level, the software level, or the process level.
If the vulnerability is in Coldcard's firmware, then it affects a vast population of users who share the same codebase. If it is in the supply chain, then a batch of devices may have been tampered with before reaching end-users. If it is in the signing process, then the attack may have succeeded without ever touching the private key's confidentiality. That last scenario is the one that keeps me up at night, because it means the user's verification process itself can be manipulated.
Let me explain this with a forensic frame. In a standard cold signing flow, the user creates a transaction on a connected device, transfers it to the Coldcard, reviews it on the Coldcard's screen, and then signs it. The hardware wallet's display is supposed to be the trusted point of truth. What if the attacker is able to make that display lie? What if the transaction that appears on the screen is not the transaction that gets signed? That is not a private key leak. That is a security boundary violation at the most fundamental level.
I am speculating here, and I want to be transparent about the confidence level. The public details are thin. But I have seen enough audits to know that when a loss is initially reported and then revised upward by nearly double, the attack often involves automation and broad targeting, not a single targeted victim. A 70-million-dollar exploit usually means a systematic extraction path has been discovered.
This shifts the industry conversation from "which wallet should I buy" to "what can I actually trust at the end of the day?" And the answer, as uncomfortable as it might sound, is: nothing, until it is verified. The code does not lie, but the auditor must dig.
The Core: What This Exploit Reveals About Our Security Models
Let me break down the security assumptions layer by layer, the same way I would in a protocol audit.
Assumption 1: Physical possession equals private key security. This is the foundation of all hardware wallets. The device stores the key in a secure enclave, and the user physically controls the device. This assumption remains, in most cases, valid. But the exploit suggests that the margin of safety is thinner than we thought. If an attacker can influence the signing process without extracting the key, physical possession still protects the key, but it does not protect the transaction.
Assumption 2: Air-gapped communication is a secure channel. Many Coldcard users use an air-gapped workflow, transferring transactions via microSD cards. This is designed to prevent network-based attacks. But an air gap only secures the communication channel, not the decision-making process. If the transaction data can be meaningfully altered before it reaches the device, the air gap becomes irrelevant. The attacker does not need to steal your key. They just need to make you sign something you do not intend to sign.
Assumption 3: Open-source firmware means community audit equals security. Coldcard's firmware is open source, and I respect that deeply. But open source does not mean free of vulnerabilities. It means more eyes can review the code. It also means attackers can review the code just as easily. I have seen open-source projects with severe vulnerabilities that remained undetected for years because the code was complex enough to hide subtle issues. Open source raises the cost of attack, but it does not eliminate it.
Assumption 4: A hardware wallet is a single root of trust. This is the assumption CZ is attacking with his "multiple wallets" advice. In my own audits, I have always pushed clients toward redundancy and separation of duties. A single device, even a very secure one, is a single point of failure. If that device is compromised, you lose everything stored under its authority.
These assumptions are not broken simultaneously by this event. But the event demonstrates that they are not independently robust either. A chain is only as strong as its weakest link, and the weakest link in hardware wallet security has always been the human and the process, not the silicon. We just prefer to believe otherwise because silicon is easier to talk about.
What the missing technical details tell us
The lack of disclosure is itself a signal. When a security incident occurs and the affected vendor stays silent, or when the only public statements come from an exchange founder and a research firm, the responsible inference is that the investigation is still active and the attack surface may be broader than a single user.
There are three plausible technical scenarios, each with a different risk profile.
Scenario A: A targeted physical attack. The device was intercepted during shipping, modified, and then shipped to a specific high-value target. This would be an expensive and sophisticated attack, likely aimed at a whale address. The loss of $70 million would be consistent with a targeted operation. In this scenario, the broader user base is not necessarily at risk.
Scenario B: A firmware-level vulnerability. A bug in the signing code allows an attacker to craft a malicious transaction that the device signs without proper user validation, or a transaction that validates correctly but behaves differently after broadcast. This is the worst-case scenario because it is systemic. In this case, every Coldcard user is technically at risk until a firmware update is released and applied.
Scenario C: A supply-chain compromise. A batch of devices was tampered with, either at the manufacturing stage or during distribution. The tampered devices would appear normal but contain additional malicious behaviors. This is harder to detect and would require physical inspection to confirm. This scenario also implies a potentially broader impact, but limited to a specific batch or distribution channel.
We do not know which scenario this is. That uncertainty is why I cannot in good conscience tell you to keep your entire stack on a Coldcard or any similar device. The architecture of trust needs to be rebuilt with the explicit acknowledgment that any single device can fail.
The technical progression I expect to see
Based on patterns from previous wallet incidents, here is what I think will unfold. First, we will see a detailed post-mortem, either from Coldcard or from an independent researcher. That report will identify the attack vector. Second, we will see firmware updates and revised security guidance. Third, we will see a shift in user behavior. Some users will move back to exchanges. Some will adopt multi-signature setups. Some will simply diversify across different hardware wallet brands.
I want to focus on that last point because it is the most misunderstood. Diversifying across brands does not solve the fundamental problem if you still use only one device per key. If your security model relies on a single hardware wallet to hold a single key, then you are still exposed to the same class of failure. The attack might come from a different vendor, but the vulnerability is in the architecture, not the vendor.
Multi-signature, on the other hand, changes the security equation. With a 2-of-3 multisignature arrangement, you need to compromise at least two independent key-holding devices to steal funds. This is not just a redundancy play. It is a way to structurally reduce the probability of a single point of failure. And it is not new, but this event will push more users toward it.
I have personally recommended multi-signature setups to every client I have worked with, not because hardware wallets are bad, but because the consequences of a single point of failure are catastrophic. The code does not lie, but the auditor must dig, and the auditor's job is to find single points of failure before the attacker does.
The Contrarian Angle: The Real Threat Is Not the Hardware, It Is the Myth of Absolute Security
The contrarian take that most commentators are missing is this: the exploitation of a Coldcard should not primarily be read as a hardware wallet failure. It should be read as a failure of the narrative that any security tool can be absolute. We have built an industry culture that treats hardware wallets as the end state of security. We sell them as firewalls between the user and the wild west of the internet. But firewalls can be bypassed. Encryption keys can be extracted. Hardware security modules can be tampered with.
When a user asks me, "Is a hardware wallet safe?" I know they are asking the wrong question. The right question is: "What is my complete security model?" A hardware wallet is one component in a broader architecture that includes passphrase management, transaction verification practices, disaster recovery, and even physical security.
The second contrarian point is the uncomfortable relationship between hardware wallet vendors and the exchange community. CZ's advice to spread funds across multiple wallets sounds neutral, but it also carries a subtle subtext. If users lose confidence in self-custody, where do they go? They go to custodial exchanges. And custodial exchanges benefit from that migration. I am not accusing anyone of manipulating the narrative, but I am pointing out that the incentive structure is visible.
This is the same pattern I observed during the FTX collapse. When self-custody tools become synonymous with risk, the default fallback is centralized custody. That fallback is not necessarily safer. It is just another set of risks, including regulatory seizure, exchange insolvency, governance failures, and operational errors.
The third contrarian point is about the risk of over-reaction. If the attack vector turns out to be a highly targeted supply-chain interceptor, then the correct response is to update purchasing practices and verify device authenticity. It is not to abandon hardware wallets entirely. We need to avoid throwing out the entire security paradigm because of a single exploit.
But we also need to avoid the opposite mistake: dismissing this as a one-off event and continuing to hold all assets on a single device. The error budget has been spent. This event is a signal that the adversary is willing and able to attack the highest layers of our security stack.
The Takeaway: From Single-Device Trust to Multi-Layered Verification
In the chaos of a crash, the data remains silent. But in the aftermath of an exploit, the data starts to speak. We need to listen carefully to what this event is telling us.
Hardware wallets remain a valuable tool. They protect against many classes of attacks, particularly remote malware and phishing. But they are not a panacea. They cannot protect you from a compromised signing process. They cannot protect you from a tampered supply chain. And they cannot protect you from the assumption that they will protect you from everything.
The industry's response to this event should not be to panic, nor to pretend it did not happen. It should be to accelerate the adoption of architectures that do not rely on a single root of trust. Multi-signature wallets, passphrase-protected seed phrases, and independent transaction verification should become the baseline, not the advanced option.
I also expect to see a renewed focus on wallet incident response. Just as smart contract protocols have learned to publish post-mortems and security advisories, hardware wallet vendors will need to adopt similar practices. Transparency after an incident is the only way to rebuild trust. Security theater and legal hedging only deepen suspicion.
Here is what I am watching for in the coming weeks. First, the official disclosure from Coldcard. The depth and honesty of that report will determine how quickly user confidence stabilizes. Second, the final loss estimate. If the number climbs above $100 million, this event becomes a different category of incident. Third, the on-chain movement of the stolen funds. If the attacker starts moving money through mixing services or bridges, that will tell us something about the sophistication and intent of the operation.
I want to close with a question for you, the reader. If you hold a meaningful amount of Bitcoin, how would you describe your current security model? Single hardware wallet? Multiple devices? Multi-signature? Or are you relying on an exchange? Be honest with yourself, because the answer is the first step toward real security.
The quiet lesson of this exploit is that security is not a product. It is a process. And the process should never end at a single device. Shifting the consensus layer, one block at a time.
In the chaos of a crash, the data remains silent. But in the quiet of a post-mortem, the data becomes the only witness. The code does not lie, but the auditor must dig. And right now, we are all waiting for the audit to conclude.
One thing is certain: the era of "just buy a Coldcard and you are safe" is over. What replaces it is up to us. If we are willing to build multi-layered architectures and verify every step of the transaction process, we can make self-custody genuinely robust. If we refuse to update our mental models, then we will keep repeating this cycle of confidence, exploit, and loss.
I have seen this movie before. In 2017, I spent six weeks dissecting the Parity multisig wallet and found the kill function vulnerability that would eventually drain millions. The lesson was the same then as it is now: trust is a vulnerability. The only sustainable approach is defense in depth.
Let this event be the catalyst, not for abandoning cold storage, but for finally building the security stack that Bitcoin deserves.
Tracing the gas trails back to the root cause has never been more urgent.