The email arrived on August 13, and I read it twice — once as a user, once as someone who has spent a decade reading disclosures for what they choose not to say. Trezor had notified 13,689 customers that a shipping partner's systems had been compromised. By the time the count was revised upward, more than 80,000 names, phone numbers, and physical addresses were exposed. The device, Trezor emphasized, was not breached. The keys were safe. The firmware was untouched.
None of that mattered.
Because the attacker did not need my private key. They needed my address — and the quiet certainty that the person living there owned something worth taking. In cryptographic terms, that is a data pairing. And data pairings do not require entropy attacks, side-channel exploits, or a broken elliptic curve. They require a database that was never supposed to persist, retained long past its purpose, and protected by a promise that no independent party ever verified.
I have audited smart contracts professionally. In 2017, I found a logic flaw in the early stability fee calculation of a then-ascendant lending protocol — a rounding error that could have compounded into insolvency for users who trusted the math. I reported it anonymously and watched the fix land within weeks. That experience taught me that code is falsifiable. You can test it. You can fork it. You can argue about it in public.
A shipping vendor's retention policy is not falsifiable. And that asymmetry — between the verifiable world of the chain and the unverifiable world of the customer service database — is where this entire crisis lives.
The Boundary Nobody Was Watching
For fifteen years, the crypto industry told a single, coherent story about security. The private key is the asset. Guard the key, and you guard everything. This framing was elegant, pedagogically clean, and — as of this year — demonstrably incomplete.
What Trezor's disclosure reveals is not a failure of cryptography. The device layer held. What it reveals is that the security perimeter of a self-custody wallet extends far beyond the silicon. It runs through the logistics provider that ships the box, the warranty system that stores the serial number next to a name, the customer support ticket that logs a delivery address, and the tax authority that happens to sit on a filing cabinet full of crypto owners' records.
Hacken, the security and GRC firm, framed the shift plainly: the attack surface has moved from the key to the supplier database. Zama, a firm working on fully homomorphic encryption, and Chainalysis, the on-chain analytics provider, both appear in this conversation now — not because cryptography failed, but because the data around the cryptography was never governed with the same rigor.
The technical claim is simple and brutal: if an attacker can pair a physical address with proof of crypto ownership, they do not need to break anything at all. They need a map. And the industry has spent a decade building that map, one order confirmation at a time.
This is not a niche observation. Across France, the Interior Ministry has recorded more than 70 crypto-related violent incidents, and the profile of those incidents is shifting. In 2023, roughly 26 percent of crypto home invasions targeted the holder directly. By 2026, that figure has climbed to 37 percent — and the more alarming number sits beside it. More than 40 percent of these events now target relatives: a spouse, a parent, a teenage child who has no hardware wallet, no seed phrase, and no idea what a UTXO is.
The French case is instructive because it is not hypothetical. A tax official was caught stealing files and selling them — the very definition of an insider threat against a database that was never designed to be an attack target. When the people who hold your data are also the people who can be bribed to leak it, "retention for operational convenience" becomes a liability with a human face.
Chainalysis estimates that global crypto-related physical attacks in the first half of 2026 produced more than $30 million in losses, with total exposure — the value that could be reached by an attacker who knows where to look — running above $107 million. And that figure counts only the cases that were reported and only the victims who actually paid. The dark figure, the unreported remainder, is almost certainly larger. A statistic that measures only what people admit to is not a measurement; it is a floor.
The Ninety-Day Lie
Here is where the technical analysis must become precise, because vagueness is exactly how this problem survives.
Hardware wallet vendors, like most consumer electronics companies, hold customer data for a stated period. The common figure is 90 days — long enough to process a return, resolve a warranty claim, satisfy a tax record-keeping obligation. After that window, the data is supposed to be deleted.
In practice, it is not.
I have spent enough time inside data engineering to know how deletions actually happen at companies that are not built around data rigor. A deletion policy lives in a document. A deletion job runs as a scheduled task that someone disabled during a migration and never re-enabled. A backup taken in year one quietly persists into year four. A vendor's subprocessor keeps a copy in a marketing analytics tool that no one from the security team has access to. The record is deleted from the primary table, and the residue lives on in eleven other places.
When I audited the post-mortems of fifty failed protocols after the 2022 collapse, the pattern I found was not malicious. It was administrative. Systems fail because governance fails, and governance fails because no one owns the outcome. The same pattern is now playing out in data retention — but the consequence has moved from a lost treasury to a broken front door.
Yasmanovych, speaking from Hacken's vantage point, put the missing link in plain language: deletion policies rest on manual declarations with no independent audit. When a company says it deleted your address, you are trusting a sentence. And a sentence is not a control. A rule that depends on self-reporting provides very little protection, because the party who benefits from saying "deleted" is the same party doing the saying.
This is precisely where the crypto industry's own philosophy should have prepared it. "Don't trust, verify" is not a slogan about blockchains. It is a general epistemic commitment about systems that concentrate power. We applied it to custody. We did not apply it to PII. And so we built a world where your assets are verifiable and your personal data is taken entirely on faith.
"Openness is not a feature; it is a philosophy." That line has been my signature for years, and I have usually meant it about source code. This year, I mean it about disclosure. A vendor that tells you "our systems were not breached" while declining to say which fields leaked is not being open. It is being legal. Those are different things, and the difference is measured in home invasions.
The Fields Matter More Than the Breach
Trezor's original notice reached 13,689 customers. The revised figure exceeded 80,000. That gap alone should tell you something about the quality of the initial disclosure. But the more important question is not how many people were affected. It is which fields were exposed.
"A city leaked" and "a full name, a street address, a phone number, and confirmation that the resident holds crypto" are not the same event. The first is embarrassing. The second is an operational dossier. Yasmanovych made this point directly: the risk level of a leak is determined by field composition, not record count. An attacker with a name and an email is a spammer. An attacker with a name, an address, and proof of crypto ownership is a planner.
This is why the industry's instinct to measure breaches in "number of affected users" is analytically useless. It manufactures headlines and destroys nuance. A million email addresses are less dangerous than five hundred addresses paired with hardware purchase confirmations. The integer on the press release tells you nothing about the threat model.
I want to be concrete about what a threat model actually looks like here, because the abstraction hides the mechanism. An attacker who has obtained a vendor's shipping database does not need to compromise a device. They can:
First, cross-reference the leaked address list against public blockchain data to estimate holdings. This is trivial for anyone with institutional-grade tooling — and increasingly feasible for amateurs, since address clustering heuristics are widely documented.
Second, prioritize targets. A hardware wallet purchase is itself a signal. It means the buyer cared enough about self-custody to spend money on it. That correlates with holdings above a casual exchange user.
Third, execute a low-tech approach. A knock at the door. A family member answering. The coercion attack that no amount of 2-of-3 multisig can resist, because the target is a person, not a protocol.
Fourth, convert. Swap the victim's phone number to intercept exchange withdrawals, or simply take the hardware wallet and demand the PIN at gunpoint.
Every step in that chain is off-chain. Every step is legal to prepare. And no cryptographic primitive interrupts it, because the vulnerability was never in the cryptography. It was in the address book.
I have said before, and I will say again, that "in the chaos of DeFi, I found my silence" — but this is a different silence. This is the silence of a database that answers questions it was never asked, holding records its owners assumed were gone.
The Negative Externality No One Prices
Here is the part that should trouble anyone who thinks about incentives, and it is where my training in applied mathematics insists on precision.
Data retention is economically rational for the vendor. Storing a shipping address costs fractions of a cent. It enables warranty verification, fraud prevention, and marketing analytics. The benefit accrues entirely to the company.
The risk, however, accrues entirely to the customer. If that address leaks, the vendor faces a disclosure obligation, some reputational damage, and perhaps a regulatory fine. The customer faces a home invasion. This is a textbook negative externality — a cost imposed on a third party who had no say in the transaction and no ability to price it.
The market, left alone, will not fix this. The vendor does not bear the cost of the invasion, so the vendor has no incentive to minimize the data that makes the invasion possible. This is why "just trust the company" is not a security strategy; it is a category error. You are not negotiating with a malicious actor. You are negotiating with an incentive structure that is indifferent to your front door.
And here is the uncomfortable corollary: the industry's most vocal self-custody advocates — myself included — spent years teaching people to hold their own keys without teaching them that holding your own keys makes you a target. We optimized for one threat model and neglected another. We told people to be their own bank. We did not tell them that banks, historically, keep armed guards, and that the alternative to armed guards is not courage but concealment.
There is a reason the Lightning Network's routing complexity and channel management burden have confined it to a niche for the better part of a decade. It is the same reason privacy tooling stalled: we build for the adversary we find intellectually interesting, not the adversary who shows up at the door. A protocol that solves micropayment throughput does nothing for a person whose address is in a spreadsheet. The threat did not change shape; it changed layer.
This connects to a broader illusion the industry keeps renewing. On-chain governance was supposed to make decisions transparent and participatory. In practice, voter turnout on the major DAOs has hovered below five percent for years, and the decisions that matter are made by a handful of whales and venture funds who hold the quorum keys. The rhetoric of community governance and the reality of concentrated control have never reconciled. Now watch the same dynamic repeat around data standards. When the industry eventually responds to physical security, the standard will not be written by the community. It will be written by the largest incumbents, and it will be drafted to protect their balance sheets rather than your family.
The Contrarian Read: Encryption Is Not a Shield Against a Wrench
Now let me argue against the instinctive response of my own industry, because that is where the real insight hides.
When a story like this breaks, the security community reaches for its familiar tools. Use multisig. Use a hardware wallet. Use a passphrase. Use a timelock. Add two-factor authentication. Rotate your keys.
Every one of these is a defense against a digital adversary. Not one of them is a defense against a person standing in your living room.
The contrarian claim I want to make is this: the industry's default answer to physical coercion is a category error, and it is a category error that flatters us. We prefer the multisig conversation because it is technical, familiar, and makes us feel in control. The honest conversation — that a determined attacker with your address and your family in the room will get what they want, and no software can prevent it — is uncomfortable, because it admits the limits of the thing we have built our identities around.
There is a deeper version of this argument. We have spent a decade convincing ourselves that decentralization is a security property. It is not, by itself. Decentralization is a governance property. It distributes control. It does not distribute risk. When the risk is physical, decentralization spreads the exposure across a wider set of households, many of which never consented to holding it. A protocol's resilience and a person's safety are orthogonal variables, and confusing them has consequences that are measured in emergency room visits.
This is also why the regulatory reflex deserves scrutiny. The European instinct will be to tighten. But notice what recent European stablecoin rules already did: steep reserve requirements and compliance costs were severe enough that they functionally killed small operators while larger, better-capitalized firms absorbed the burden — which is, conveniently, the outcome incumbents prefer. If the response to physical risk becomes another compliance regime, the same pattern will repeat. The small wallet vendors and privacy-first startups — the ones with the cleanest data practices — will be regulated out first, and the firms with the deepest pockets will survive with the same leaky databases.
The answer is not more regime. It is fewer retained fields. The cheapest security control in existence is the data you never collected. No breach can expose a record that was never written. No subpoena can compel a field that does not exist. Data minimization is not merely a principle buried in a European privacy statute; it is the only control whose failure mode is dormant by construction.
I learned this the hard way. In 2021, I coded the smart contracts for a non-speculative NFT collection with three indigenous artists on Tezos. We rejected the standard speculation-first model. We wanted oral histories preserved, not floor prices pumped. The project raised fifteen thousand dollars, a rounding error in that year's market. But we made one design decision that I now recognize as the entire thesis of this article: we collected nothing we did not need. No emails, no addresses beyond what fulfillment required, no analytics pixels. "We minted souls, not just tokens," I wrote at the time, thinking about the artists. I did not realize I was also writing about attack surface.
What Verifiable Deletion Would Actually Require
If I am going to diagnose the problem, I owe the reader a concrete mechanism, because vagueness is how this survives.
The missing primitive is verifiable deletion. Today, deletion is a claim. What the industry needs — and what the privacy-computing sector is circling — is a way to prove that a record has been destroyed without exposing the record itself. This is genuinely hard, and it is the frontier where firms like Zama are working, though their public posture on this specific application remains thin. Fully homomorphic encryption allows computation on ciphertext, which means a system can process a warranty claim without ever decrypting the customer's address into plaintext. That is a meaningful shift: the data is present for computation and absent for exfiltration.
But FHE alone is not the answer, and I want to be honest about the gap. Verifiable deletion requires three layers that do not fully exist yet:
An attestation layer, where a trusted enclave or cryptographic commitment logs that a specific record was destroyed at a specific time, in a way that a third party can audit without seeing the data.
A retention policy enforced by code rather than by document, so that deletion is a property of the system, not a task someone is supposed to perform.
A field-level encryption architecture, where even a full database dump yields nothing without keys held separately and rotated aggressively.
"Truth emerges when the ledger is transparent." That is true of blockchains, and we assume it is true everywhere. But a transparent ledger of deletions is not the same as a transparent ledger of transactions, because deletion is irreversible and its verification must not itself become a privacy leak. The proof that a record is gone must not reveal what the record was. This is a subtle and genuinely unsolved problem, and it is where I would put engineering effort if I were building infrastructure today.
None of this is speculative in the sense of being unneeded. The European right to erasure is already law. It is simply unenforced against the specific class of firms — crypto hardware vendors and their logistics partners — where the consequence of failure is physical. The regulation exists. The verification does not. And a right without a verification mechanism is a suggestion.
The second-order market is already forming around the gap. I expect physical-security insurance for crypto holders to emerge as a real product category within eighteen months, because the risk is now quantifiable and the pool of exposed households is large enough to underwrite. I expect anonymous fulfillment and zero-retention hardware vendors to market data hygiene as a differentiator, the way some exchanges once marketed proof of reserves. And I expect the dark-figure problem to get worse before it gets better, because the incentive to report a home invasion is weak when reporting it also confirms that you hold assets worth invading for. These are not forecasts I make with enthusiasm. They are forecasts I make because the incentive structure is boring and legible, and boring, legible incentives are the most reliable things in any market.
The Takeaway
In the chaos of this particular year, I have found a new silence — the silence of a disclosure notice that explains everything except the one thing you need to know.
The security boundary of a self-custody wallet has moved. It is no longer the silicon, or the seed phrase, or the firmware signature. It is the spreadsheet at the logistics company, the filing cabinet at the tax office, the retention policy that runs on a scheduled job nobody remembers. The next decade of crypto security will not be won with more entropy. It will be won by deleting more.
I do not think the industry is ready for this, because the fix is unglamorous. It means collecting less. It means vendor contracts with data-minimization clauses written by people who understand threat models, not lawyers who understand liability. It means holding ourselves to the standard we demand of chains — verify, don't trust — and applying it to the boring databases we never audited because they were never interesting.
Code is poetry, but community is the chorus. And a chorus is only as safe as its quietest member — the spouse who does not hold keys, the parent who does not know what a cold wallet is, the child who answers the door. Humanity remains the only non-fungible asset, and it is the only one that cannot be reissued after a breach. Join the fork if you must, but keep the lineage — because the lineage is what a leaked address list puts at risk, and no protocol upgrade will ever patch a person.
So the question I leave with you is not whether your keys are secure. They may be. The question is whether anyone, anywhere, still holds the record that connects you to them. If the answer is yes — and for most of us, it is — then you have not finished securing your assets. You have merely secured the easy half.