Coldcard's Dormancy Paradox: 3.5 Years, 250 Reports, and a Theft That Was Already Scheduled

On August 8, a number crossed my desk that should have been impossible. According to Galaxy Research, 88% of the bitcoin stolen in what is being called the Coldcard security incident had not moved for at least a year. The median stolen coin had been dormant for 3.5 years. The reporting included more than 250 victim claims, a median loss per address of 0.014 BTC, an average loss per address of 0.212 BTC, and then the far more uncomfortable pair: a median loss per report of 1.022 BTC and an average loss per report of 4.04 BTC. The maximum single reported loss was 58.97 BTC, and the lowest reported loss was 624 satoshis. The first thing I felt was not fear. It was recognition. I have spent enough time dissecting post-mortems to know that a dataset with this shape is not describing a random perpetrator tripping over a fragile wallet. It is describing a harvest. And the most important detail — the long dormancy — is not just a clue. It is the entire story. Trust is not a variable you can optimize away. I have said that in more audit reports than I can count, and this incident is shaping up to be a public demonstration of the sentence. Hardware wallets are designed to optimize trust in the signing device. They give you a verifiable screen, a secure element, a tamper-evident enclosure, and an offline signing ceremony. But the moment the seed phrase enters a human workflow, the optimization stops. Trust reappears in a backup sheet, a password manager, a spouse's safe, a cloud photo, or a legacy recovery process. Coldcard may be the most paranoid wallet on the market, but no wallet can optimize away the ten-year-old seed phrase that was exposed before it ever reached the wallet. Let me start with a clear disclaimer. The phrase "Coldcard security incident" is not, as of this writing, a confirmed technical conclusion. It is a label attached to a group of victim reports. The parsed source material does not include transaction hashes, firmware versions, device fingerprints, wallet software identifiers, or any on-chain evidence that would allow an independent auditor to verify the attribution. Galaxy Digital's head of research is a credible on-chain analyst, and the report carries weight. But credibility is not the same as forensic sufficiency. When I evaluate a security incident, the first thing I ask is whether the data supports the name on the headline. In this case, the data supports a narrower claim: an attacker obtained private keys for a collection of bitcoin addresses whose recorded balances had been stationary for a long time. Whether those keys were extracted from Coldcard devices, from the users' backups, from the users' host machines, or from a compromised generation process remains an open question. The Coldcard context matters. Coinkite's Coldcard is not your average hardware wallet. It is the device that bitcoin maximalists recommend when they want to move funds into a vault and forget they exist. It supports air-gapped signing via QR codes and SD cards, exposes PSBT tools that make partial signatures easy to verify, and has a firmware update process designed around reproducible builds and auditable release artifacts. In a community that treats self-custody as a religious act, Coldcard is one of the few products that claims to take the threat model seriously. That is precisely why a data pattern like this one is so dangerous. If the community sees a 58.97 BTC loss from a Coldcard user, the instinct will be to burn the entire category. But the honest forensic answer is that we do not yet know whether the wallet failed or whether the human system around the wallet failed. And as someone who has audited both code and human procedures, I can tell you that the human failure is usually the more probable path. Let me now walk through the numbers with the patience they deserve. The gap between address-based statistics and report-based statistics is not statistical noise. It is a fingerprint. If you calculate the average loss per address at 0.212 BTC and the average loss per report at 4.04 BTC, you are looking at a factor of roughly nineteen. A factor that large cannot be explained by a simple rounding error. It suggests a highly skewed distribution of losses. A small number of victims account for the overwhelming majority of the value, while a much larger number of addresses sit at the low end with tiny balances. The 624-satoshis figure is a natural artifact of that skew. Some addresses associated with the incident may have been change outputs, dust leftovers, or addresses that contained tiny balances before being consolidated into a sweep. Counting those dust amounts as equivalent losses is a category error. It pollutes the median and gives the attacker more credit than they deserve. But the more important message is hidden in the fact that the report-based median is 1.022 BTC while the address-based median is 0.014 BTC. This tells me that the reporting population is not the same as the address population. Many users had multiple addresses swept in the same theft, and the large balances were concentrated. A median report loss of over one bitcoin is not amateur theft. It is a target-rich attack. The attacker did not stumble upon one private key. They obtained access to a batch of keys, scanned the blockchain for the most valuable dormant outputs, and then performed a coordinated series of sweeps. The average report loss of 4.04 BTC reinforces that picture: this is not a skimmer at an ATM, collecting pocket change. This is a systematic liquidation of old wealth. Now I want to isolate what I call the Dormancy Paradox. A dormant bitcoin address is, in many ways, the most secure object that exists on a blockchain. It has no recurring interaction with a smart contract, no approval surface, no active liquidity pool, and no external dependency. It is simply a public key with a private key attached to it. But dormancy also means the owner is not looking. The owner has no reason to check the address, no reason to import the seed into a fresh piece of software, no reason to monitor the UTXO set for unexpected movement. This is the paradox: an address with three years of stillness is an address where the theft can remain hidden for months. The attacker knows this. They can test one transaction, see that no immediate response occurs, and then drain the rest of the address family in quiet waves. The data suggests that this is exactly what happened. If 88% of the stolen bitcoin had been inactive for more than a year, the victims were not active users of their cold storage. They were holders who had created a wallet, maybe written down a seed phrase, maybe transferred bitcoin into it once, and then placed it in a drawer. They had constructed a false narrative of permanence. They believed that because the private key was on a hardened piece of hardware, the asset was safe. But the private key was never just on that hardware. It was also in the memory of the person who generated it, on the backup paper, in the passphrase management software, and potentially in a cloud sync or a photograph. The hardware wallet is the visible fortress. The seed phrase is the invisible key hidden under the doormat. Let me bring in a specific example from my own career. In 2020, after the bZx flash loan exploit, I spent days simulating five different arbitrage vectors before I understood that the attack was not a single transaction. It was a sequence of assumptions stacked on top of each other. Each assumption looked reasonable in isolation. The oracle price was slightly off, the liquidity pool was shallow, the flash loan gave the attacker temporary capital. When I finally reconstructed the full narrative, I realized that the most dangerous attacker is the one who understands time. The bZx attacker did not need to be fast. They needed to know when the market had drifted from equilibrium. The same lesson applies here. The Coldcard attacker, if the dormancy profile is accurate, did not need to be fast. They needed to know that old keys still work. They needed to know that a seed phrase created in 2017 still signs for a bitcoin address created in 2017. And they needed to know that the owner had probably moved on and would not notice a silent sweep for months. This is the kind of insight that gets lost when the media reduces the story to "Coldcard hacked." The real story is more subtle. It is about the temporal decay of security assumptions. A hardware wallet is designed to protect a private key at rest inside the device. But the private key is not a static object. It is a relationship between a seed phrase, a derivation path, a set of addresses, and a human memory of how the backup was made. Every time that relationship is tested — during an upgrade, during a recovery, during a message to a tax accountant — the security surface changes. If the seed phrase was exposed in 2019, the Coldcard did not fail in 2025. The failure happened in 2019, and the blockchain simply waited years to reveal it. Let me now walk through the attack vectors that are actually compatible with the published data. The first is a hardware-level compromise. This would require an attacker to break the secure element in a Coldcard, exfiltrate the private key through a side channel, or tamper with the device at the supply-chain level. This is the scariest scenario, and it is also the hardest to prove. A well-designed hardware wallet like Coldcard has multiple layers of verification. Shipments are sealed, bootloaders are signed, and users are instructed to verify firmware hashes. But supply-chain attacks are not impossible. A malicious actor with control over a batch of devices could program them with a seeded RNG, generate predictable keys, and wait for users to deposit funds. That scenario would produce a distribution of losses that looks exactly like the one we see: many address balances, a few large ones, and a long period of dormancy before the attacker decides to sweep. The attacker would not want to strike immediately because sweeping a newly funded address would create an obvious trail. Waiting for the user to stop watching is the rational move. The second vector is seed phrase compromise. In my audit experience, this is the most common failure mode in self-custody setups. A user generates a 24-word seed, writes it down on a piece of paper, and then makes a mistake. Maybe the paper is photographed. Maybe it is stored in a cloud drive. Maybe a relative sees it. Maybe the user enters it into a software wallet during a failed recovery attempt. The seed phrase is the master key. The hardware wallet can only protect the key if the key never leaves the device. But the seed phrase, by design, is meant to leave the device exactly once — during the initial backup. If that backup is compromised, the hardware wallet becomes a plastic obelisk. It still signs transactions, but it no longer controls the security boundary. The 3.5-year median dormancy fits this scenario perfectly. The seed was created early in the wallet's life, the user transferred bitcoin in, and the seed sat in a backup location. Later, an attacker obtained the backup and waited until the user's attention shifted before sweeping the funds. The third vector is host computer compromise. Coldcard users usually connect the device to a computer to broadcast signed transactions. The cold, air-gapped model reduces the risk of malware directly stealing the private key from the device. But the host computer sees the xpub, the transaction history, and the addresses being constructed. If the host is compromised with spyware, the attacker may not be able to sign, but they can observe. They can learn that a particular address holds 25 BTC. They can learn when the user is likely to move funds. They can even intercept a PSBT and manipulate the destination address, although a careful user will check the screen on the Coldcard itself. In a more sophisticated attack, the malware could wait until the user imports their seed phrase into a recovery tool and steal it at that exact moment. This scenario does not require a Coldcard vulnerability. It only requires a user who believes their phone or computer is clean. And in 2025, with AI-generated spearphishing, no one can defend that belief with much confidence. The fourth vector is weak entropy during key generation. This is the hypothesis that makes the dormancy statistic the most haunting. If a batch of hardware wallets was generated with a flawed random number generator, or if the host supplied weak entropy during initialization, the resulting private keys might lie in a small, brute-forceable space. The addresses would look normal, the wallets would sign correctly, and users would never notice anything wrong. Years later, an attacker could scan the blockchain for addresses that match the vulnerable key space and steal every mirror of those keys. The theft would have a signature: the coins would be old, unused, and suddenly swept. This is not a theoretical concern. The bitcoin community has seen poor entropy before, from the Android SecureRandom bug in 2013, to wallets that generated keys from low-entropy timestamps, to firmware builds that made predictable nonce choices. The 3.5-year median is exactly the kind of delayed fuzz bomb that entropy flaws create. The fifth vector is not an attack on the device at all. It is an operational failure. A user creates a Coldcard wallet, writes down the seed, stores it in a safety deposit box, and then forgets it. A family member, a lawyer, a bank employee, or an executor discovers the seed years later and transfers the bitcoin. This is not a cryptographic invasion. It is a broken possession chain. But from a victim perspective, it is indistinguishable from a remote theft. The victim reports a loss, the address moves, and the analysis says the seed phrase was used. The Coldcard itself was never in the attacker's hands, and the private key never left the hardware. The seed phrase was the entire vulnerability. This is the kind of thing that never makes a compelling news headline but is shockingly common when you actually interview victims after a large-scale incident. I want to be honest about the source quality here. The information I have is not a forensic report. It is a collection of statistical claims from a reputable research firm, but without the underlying transaction data, I cannot verify attribution. I cannot determine whether the stolen coins were all sent to the same exchange, whether they were laundered through a mixer, or whether they moved in a single block or across years. I cannot check whether the victims generated their wallet with an old firmware, imported the seed into a hot wallet, or used a passphrase. The absence of this metadata matters. It means the responsible answer to the question "how were the keys compromised?" is a disciplined "I don't know." The irresponsible answer is to feed the fear machine by declaring that Coldcard is broken. There is also a statistical subtlety that the coverage will likely miss. The reported maximum loss is 58.97 BTC, which at the time of writing is a substantial amount. But the median report loss is only 1.022 BTC. This tells me that the distribution is heavily right-skewed. The majority of victims lost between one and two bitcoins, while a small number of victims lost tens of bitcoins. The presence of such a high maximum in a dataset of 250 reports is significant. It suggests that the attacker had access to a broad spectrum of key quality. If the attack were a single targeted hack against high-profile whales, the median would be much higher. The fact that there are many small losses and a few large ones is consistent with a database of compromised seeds or keys, sorted by balance. The attacker probably swept the largest addresses first, then worked their way down to the dust. This is why I keep returning to the phrase: trust is not a variable you can optimize away. When you optimize for the purity of a hardware wallet, you often neglect the human and procedural layers that surround it. You can have the most secure secure element on the planet, and then transfer the seed phrase into a Google Doc to create a backup for your spouse. You can verify the firmware hash on your Coldcard, then plug it into a compromised laptop that records the address on screen and associates it with your social identity. You can sign a transaction offline, then broadcast it through a public Wi-Fi network. The hardware wallet is a necessary layer of defense, but it is not a closed system. The entropy always leaks somewhere. Let me now address the contrarian angle directly. The usual conclusion from a story like this is: "Hardware wallets are not safe; move your coins to an exchange." That conclusion is a lazy retreat. An exchange is a different trust model, not a better one. When you place bitcoin on an exchange, you are trusting a centralized team, their cloud providers, their employees, their regulators, and their insurance policy. In a bear market, exchanges have a distressing history of finding new ways to lose customer funds. The lesson from this Coldcard incident is not that self-custody is impossible. It is that self-custody requires continuous rehearsal. You cannot simply generate a seed once and walk away. You must re-import the seed into a simulation, verify the derivation path, test the backup, and ask yourself what would happen if that backup were stolen today. Here is a practical experiment I recommend to anyone with a cold storage wallet. Take a small amount of bitcoin, send it to an address derived from your hardware wallet, and then attempt to recover that bitcoin using only your backup seed and a fresh software wallet. Do it in a controlled environment, on an offline computer, with no cameras around. If you cannot recover the funds, your backup is a fiction. If you can, you have just re-verified your security covenant. Many bitcoin holders will perform this test and discover that their seed phrase does not match the address they think it controls. The panic that follows is always embarrassing, but it is cheaper than losing 58 BTC. Another contrarian observation involves the address-based median of 0.014 BTC. Some analysts will use this number to claim that the theft affected ordinary retail users in large numbers. But 0.014 BTC is less than one thousand dollars at current prices. That is not the profile of a wealthy whale. It is the profile of someone who discovered bitcoin early, mined a few coins, bought a little on a local exchange, and then stashed it away. The 624-satoshis figure is even more telling. 624 satoshis is a piece of dust. Anyone who reports a loss of 624 satoshis is someone who probably had a very small transaction years ago and noticed that the output was swept by an attacker. The attack was indiscriminate. It did not target millionaires. It targeted any address whose private key was compromised and whose balance was greater than the transaction fee used to steal it. This is the signature of a large-scale private key database sweep, not a surgical hardware compromise. The dormancy statistic also raises a chronological question. If 88% of the stolen coins were older than one year and the median was 3.5 years, then the victims' wallet activities were concentrated in a relatively narrow window around 2021 and earlier. That timeframe is significant because it overlaps with the peak of the 2020-2021 bull market, when millions of new users entered cryptocurrency and many of them generated hardware wallets for the first time. A user who bought a Coldcard in 2021, generated a seed, and then moved bitcoin into it during the bull market would fit this profile perfectly. But so would a user who bought a different hardware wallet in 2021, or used software, or used an exchange's withdrawal tool. Without knowing when the victims acquired their devices, we cannot say whether this is a Coldcard-specific issue or a broader 2021-era key management problem. I can speak to this from experience. In 2022, while examining modular blockchain claims around Cosmos IBC, I ran latency simulations that showed how atomic swaps between chains introduced unacceptable delays for high-frequency trading. The data did not make me popular with certain core developers. But it taught me an important lesson about narratives. A community tends to believe what makes its security model feel coherent. It does not want to hear that a supposedly decentralized interchain protocol has a latency floor that makes it unsuitable for fast trading. Similarly, the Coldcard community does not want to hear that the beautiful hardware wallet they trust may not be the attack surface. It is much more comfortable to imagine a malicious firmware update than to reimagine your own backup procedure. But security is not a comfortable enterprise. It is a discipline of thinking about the moment when your assumptions stop being true. Let me also note that the phrase "long dormant" can be misleading. In blockchain forensics, dormant does not mean abandoned. It means the address has not initiated a transaction in a given time window. The owner might be alive, paying attention, and simply not moving funds. The attacker, however, cannot distinguish between a watched address and an abandoned address until they perform a test transaction. This creates an asymmetric game. The attacker can send a tiny amount to the compromised address, observe whether the balance is consolidated or moved, and decide whether to proceed. A victim with active monitoring would react to the test transaction. A victim who put the wallet in a drawer would not. The dormancy statistic is therefore not just a description of the funds. It is a description of the victim's attention level. The attacker chose targets where the absence of moving funds predicted the absence of vigilance. This is the kind of insight that should reshape how security professionals talk about cold storage. A hardware wallet is not an alarm system. It is a safe. But a safe does nothing if the combination is written on a sticky note attached to the front. The blockchain equivalent of the sticky note is the seed phrase backup stored in an unencrypted file, the screenshot of the recovery words, or the cloud sync that quietly copies your text messages. I have audited institutional custody systems where the cryptographic architecture was flawless and the access control was a simple password. I have also seen individuals with no formal security training who managed a hardware wallet perfectly because they understood the principle of least privilege. The difference is not the device. It is the discipline. Let me now outline what I would want to see in a real forensic investigation. First, a list of affected addresses with their creation timestamps and values. This would allow analysts to check whether the addresses were generated in a particular block range or with a particular derivation path. Second, the signature data from the theft transactions. If the attacker used a software wallet to spend, the signature format may reveal the wallet implementation. Third, the destination addresses and the flow of funds. If all the stolen coins eventually consolidated into a single exchange account, the attacker made a mistake that could identify them. Fourth, a group of victims' hardware wallet firmware versions and software management tools. If a particular firmware or host software appears in every victim, that is a clue. I hesitate to say this, but the current data is insufficient for any of those tests. Without more evidence, the only responsible conclusion is that the Coldcard label is a hypothesis, not a diagnosis. Nevertheless, I believe the dormancy pattern itself constitutes an information gain for the wider security community. It tells us that attackers are willing to wait. It tells us that the value of a private key does not depreciate over time. A key generated in 2017 is just as valid in 2025. This is a property of Bitcoin that cuts both ways. It gives holders a permanent store of value, but it also gives attackers a permanent target database. The longer an address sleeps, the more likely it is to be forgotten by its owner and the more attractive it becomes to an attacker who has the key. The phrase "zombie address" is often used in compliance circles to refer to old addresses that suddenly wake up. I prefer "sleeping asset," because it conveys the vulnerability rather than the resurrection. Maybe the most important takeaway is this: security is a practice, not a product. The Coldcard incident, if taken at face value, is a reminder that no hardware wallet can protect you from an exposed seed phrase. The hardware wallet protects your key from remote compromise while it is inside the device. It does not protect your seed from being photographed, printed, or uploaded. It does not protect you from a malicious host that observes your address activity and targets you later. It does not protect you from poor entropy during the generation process, unless the device itself is truly using a hardware entropy source and the user verifies the device firmware. This is not a failure of the hardware wallet concept. It is a failure to understand the full attack surface of self-custody. In the institutional work I have done, the most successful security teams are the ones that schedule regular key ceremonies. They do not assume that a cold wallet remains cold because it is locked in a safe. They periodically test the recovery process, rotate the addresses, and verify that the backup is still accessible. They treat the private key as a living asset that requires maintenance. The individual bitcoin holder needs the same discipline. If you have a Coldcard, or any hardware wallet, ask yourself: when was the last time you tested your recovery phrase? Do you know exactly where it is stored? Who else has access to it? If someone stole that paper today, would they be able to drain your wallet before you noticed? If the answer is yes, or if you simply do not know, then the Dormancy Paradox applies to you. There is also a deeper philosophical point. Bitcoin's security model rests on the economics of attack resistance. The cost of attacking a seed phrase is near zero if the seed phrase is exposed. The cost of attacking a hash preimage is astronomical. Hardware wallets move the security boundary from the mathematical layer to the physical and human layers. That means the most expensive part of security is not the silicon; it is the repeated human act of choosing not to expose the key. Every convenience, every backup tool, every cloud sync, every "just write it in your notes app" decision is a tiny erosion of that boundary. Over 3.5 years, a thousand tiny erosions can accumulate into an open door. I want to return to the 58.97 BTC figure one last time. That is a life-changing amount of money, and it was stolen from someone who probably believed they had done everything right. They bought a hardware wallet, they transferred their bitcoin, they stored the device in a safe place, and they waited. The theft took place on the blockchain, but it began long before, on a day when the seed phrase was exposed. The attacker did not need to break cryptography. They just needed to find the key. This is the uncomfortable truth of Bitcoin self-custody in 2025. The encryption is not the weak point. The key management is. And key management is not a variable you can optimize away. I have one final forecast. Over the next twelve to eighteen months, we are going to see more thefts with this same dormancy profile. Attackers are building databases of old addresses and cross-referencing them with leaked seed phrase repositories, password manager breaches, and historical ransomware dumps. The blockchain is a perfect ledger for this kind of hunting because it tells the attacker exactly where the value is. The cold wallet holder who has not checked their address in three years is the ideal victim. The only defense is to break the dormancy cycle. Re-verify your backups. Move your coins. Generate a fresh seed. Split the new seed across multiple geographic locations. And if you cannot do any of that, at least check your addresses on a regular schedule. Security is not a one-time event. It is a recurring obligation. How many of your keys are still alive? And more importantly, do you know which ones died the moment you stopped asking that question?