No threat model, no privacy work

We decline privacy engagements that arrive without a threat model. Not because the projects are bad — because without a named adversary, “private” is not an engineering requirement. It is a mood.

“Private” against whom?

Every privacy mechanism defends against someone specific and fails against someone else. ZK proofs hide inputs from verifiers — not metadata from network observers. MPC removes single-party trust — not a quorum of colluding operators. TEEs exclude the host — until the next side-channel paper. Encryption at rest stops the disk thief — not the operator with the key. Choosing among these before naming the adversary is choosing a lock before knowing whether the burglar comes through the door, the window, or payroll. When a project says “we want privacy” and cannot say against whom, there is no engineering decision to make yet — only a marketing one, and we are the wrong vendor for that.

What a workable threat model contains

One page is enough. Adversaries: who, concretely — chain analysts, the operator itself, a state actor, a curious counterparty. Capabilities: what they see and control — full ledger, network timing, one compromised operator, legal process. Assets: what must stay hidden — amounts, counterparties, strategy, identity — and from whom, since the answer usually differs per asset. Acceptable leakage: what you concede — timing, participation, aggregates — because every deployed system concedes something, and the honest ones write it down. Non-goals: the adversaries you explicitly do not defend against. The regulatory floor: which authorities must be able to see what, under what process — decided now, not discovered later.

Generic frameworks like LINDDUN enumerate the privacy threat categories well; a crypto-native model adds the observers they were never built for — public-ledger metadata analysis, MEV-adjacent searchers, and validator-level adversaries who see ordering before inclusion.

The two failure patterns

Pattern one: privacy as checkbox. The mechanism is selected for the pitch deck, the adversary is discovered in production, and the retrofit costs more than the original build — because privacy composed after the fact composes badly. Pattern two: privacy versus compliance. The architecture makes everything invisible to everyone; then the first lawful-order letter arrives, and the team must choose between breaking its privacy promise and breaking the law — a fork that a one-page threat model would have priced in from the start. We saw the discipline done right in the Penumbra ecosystem, where we contributed as OSS engineers from 2022 to 2024: the protocol's privacy claims were stated against explicit observers from day one, and the engineering followed the statement.

Why refusal is the respectful answer

A privacy system built against no adversary costs full price and defends against nothing in particular. Declining that build is not gatekeeping; it is refusing to bill for a wall around an unnamed threat. The refusal has a track record behind it: we built the initial Penumbra Web Wallet — the extension that became Prax — as OSS contributors from 2022 to 2024, and the cryptography behind these positions is in five peer-reviewed papers. The conversation we want takes thirty minutes and starts with one question — who are you hiding what from? — and every serious answer we have ever heard fit on a page. Bring the page.