The message arrived from jobs@foundation.xyz. Not a lookalike domain. Not a homoglyph substitution. Not a spoofed envelope. The genuine domain, served from genuine infrastructure, authenticated by genuine credentials.
For the recipient β a Passport owner who roughly two years ago paid a few hundred dollars for a Bitcoin hardware wallet β every automated filter agreed. SPF returned a pass. DKIM returned a pass. DMARC returned a pass. The client appended no warning badge. Nothing landed in spam. The message simply arrived, carrying a name, a phone number, and a shipping address that the recipient recognized as his own.
I have spent thirteen years reading protocol specifications and auditing implementations. The first instinct in moments like this is not anger. It is a narrow question: which trust boundary collapsed? The answer here is uncomfortable, because it is not the boundary the industry funds.
The hardware was never breached. The private keys never left the secure element. And yet the page the email pointed toward carried a deposit button.
Consider what a hardware wallet actually promises. The Passport, Foundation's device, draws its marketing from a defensible technical position: open-source firmware, a dedicated secure element, and a QR-based air-gap that keeps the signing device physically disconnected from any network. Those are real properties. They map to a threat model that has, for a decade, been carefully rehearsed across the self-custody industry β firmware supply-chain tampering, counterfeit firmware, and user-initiated signing.
The third threat is the one that gets the least engineering attention, because it is not an engineering problem. It is a human protocol. Nothing in the secure element can stop a user who has been persuaded to sign a transaction, or to type a recovery phrase into a webpage, or to send coins to an address displayed on a screen. The cryptography is a guard at a door that the user can choose to walk around.
Foundation knew this. In 2022, the company publicly described moving its customer support and email tooling to self-hosted infrastructure to reduce third-party risk. That was a reasonable choice in isolation. Reconstructing the protocol from first principles, though, it introduced a second ledger of risk that the company did not balance against the first.
The anatomy of the incident is worth tracing slowly. Attackers obtained a Cloudflare API key β a programmatic credential granting access to the CDN, DNS, mail routing, and Workers logic tied to the account. With that key, they could send mail through Foundation's genuine sending infrastructure and point recipients toward foundation.support, a lookalike domain that replicated the Envoy wallet interface closely enough to pass a distracted glance. Some recipients received fully personalized messages containing order details. Former job applicants received only a first name. The two-version split matters more than it appears to at first.
Here is the technical core, and it splits into three parts.
The first is that this was not spoofing. It was abuse of a legitimate channel, and no recipient-side email control can detect it. SPF, DKIM, and DMARC collectively answer one question: was this message authorized by the domain it claims to come from? In this case the answer is yes β because the credentials that signed it were the domain's own. A defense built on "check the sender domain" is useless against this class of attack. Worse than useless, actually, but I will return to that.
The second part is the data side, and it is where the official narrative leaves a gap that no amount of secure-element reassurance can close. A leaked Cloudflare API key explains how the emails were sent. It does not explain how the attacker knew which addresses belonged to Passport owners, or their names, or their phone numbers, or the fact that a particular recipient had purchased a device two years ago. Sending privileges and personally identifiable information typically live in separate permission domains. A single credential compromise does not span both unless the same account happened to host mail routing and customer data storage simultaneously. The article to which I am responding flagged this contradiction; reading it, I found it the most load-bearing observation in the entire incident.
The two-version email distribution confirms the reading. Attackers sending a customer-specific message to buyers and a name-only message to former applicants are working from at least two heterogeneous datasets β a commerce order table and a recruiting or applicant-tracking system, or a merged marketing list. A single database export does not produce that pattern.
The third part is a policy collision that is hard to explain away. Foundation states that customer data is deleted sixty days after an order ships. Yet a purchase made two years ago produced leaked name, phone, and address. Only a small set of technical explanations survives: backups or archival systems outside the deletion policy's scope; residual data inside a support ticket platform, a marketing tool, or a third-party logistics provider; a policy that was never actually engineered into an automatic enforcement mechanism; or cross-matching against an external breach corpus. The ledger remembers what the narrative forgets.
I have done this kind of forensic reconstruction before. When I reverse-engineered the Terra stabilization mechanism in early 2022, the thing that mattered was not the stated design but the actual behavior of the code under negative equity β and the failure mode was the same shape as this one. A system promised a property (a stable peg, a deleted dataset) whose enforcement depended on assumptions that were never tested against the environment it actually operated in. Policies that exist on paper and mechanisms that run in production are not the same object.
And here is where the contrarian reading begins. The prevailing industry lesson from this event will be stated as "verify your senders." That lesson is not merely insufficient; it is actively inverted. Because the sending domain was authentic, the recipients most likely to fall were the ones who had internalized the deepest trust in foundation.xyz. The defense we have trained users to run β glance at the domain, then click β functioned as a delivery mechanism for the attacker, not a filter against him.
The second blind spot is bigger, and almost nobody is pricing it. The official crisis communication is technically true and materially incomplete: "the hardware was not compromised" and "funds on Passport remain safe" can both hold while an affected user loses everything. That is what a well-constructed incomplete truth looks like. But the real exposure is not the phishing click. It is the metadata. A name, an address, a phone number, and the durable fact that its owner holds Bitcoin β that combination cannot be deleted once it diffuses. CertiK's projection that 2026 wrench attacks will reach record highs lands directly on top of that leak. Ledger's 2020 e-commerce breach produced physical fake letters to users' homes for months afterward. The phishing page was a one-time event; the dataset behind it is a permanent liability.
Protecting the user means being honest about where the security boundary actually is. It ends at the secure element's edge. It never extended into the inbox, and it never covered the shipping label.
Which raises the question the next generation of device makers will have to answer in public: if a hardware wallet's real product is trust, and the metadata layer is now the cheapest way to attack that trust, why does the industry still treat customer data minimization as a marketing line rather than an auditable property? The first vendor that publishes a verifiable deletion proof β third-party witnessed, not self-reported β will reset the standard. Everyone else will be explaining, for years, why they did not. Stability is not a feature; it is a discipline, and the discipline here begins by admitting that the metal was never the whole perimeter.