Privacy tools can hide activity from the public yet still leak it to specific parties. Our five adversary archetypes reveal who can learn what a privacy protocol promises to hide, and whom users must trust. They assess the live protocol and a released app, using source code, onchain data and observed behaviour.

Each project promises at least one private field: sender, recipient, amount, asset or the link between two actions. We rate that field against each adversary independently and report other exposed fields separately. An adversary is a capability that different people or companies may have.

Ratings

The ratings assume a careful user follows ordinary hygiene and the review’s advice, using settings offered by the reference app. Ordinary hygiene means waiting between steps, common amounts, the largest pool, a fresh exit address through a relayer and a new network session per step.

• Private (green): the promised field stays hidden from this adversary.
• At risk (yellow): protection is limited, private use can be denied, or keeping the field hidden takes substantial effort beyond the app’s options. A workaround must preserve ordinary use of the protocol.
• Exposed (red): the field is exposed with no reasonable workaround, or no usable, verifiable app supports private use. A custodian who can require disclosure to release funds also earns red.

A closed app’s delivery risk falls to the privileged insider. When the review reads and pins the code a closed web app or extension serves, the other cells rate that code like open code. A native closed app caps the network observer at yellow.

When privacy depends on hiding among other users, the size of that group (anonymity set) affects the adversary who sees the later action. Until real use builds that group, ratings rest on what the design allows.

Adversaries

• Public observer: reads public transactions and follows explicit links.
• Chain analyst: combines public data to correlate timing, amounts, gas payments and addresses.
• Network observer: sees traffic on the user’s network path and at third parties, such as ISPs, VPNs, public RPCs and relayers. Services the operator runs count as the insider, a service under the operator’s account counts for both.
• Privileged insider: controls or serves part of the system, holds keys or plaintext, custodies funds, or delivers the app.
• Future adversary: archives public data, then runs the known quantum attacks and uses every key they recover. Other schemes stand until an attack on them is known, and the cell names the assumption that remains. Retained logs, insider keys and recorded traffic are outside this scenario.

A third party ties requests to one user by content, session or timing. Content is what a request names, like an account or a hash. Session is what requests share, like an IP, a Tor circuit, a fingerprint or a login. Timing narrows the candidates to users active at the same moment. The network observer is green only when no third party ties both sides of the promised field by content or session. Timing must leave many candidates.

Vendors behind an operator’s backend are third parties. Each one the backend needs or the operator declares, such as an RPC provider, is presumed to receive what its job needs, grouped by user. Open backend code or a specific public statement from the operator rebuts this.

Bulk downloads and a local node keep content out of requests. An IP-hiding route keeps the IP out. An app that routes its own traffic can also give each step its own session. A mixnet’s cover traffic hides when the user is online, but only the app can hide when they act.

Counterparties (e.g. private transfer recipients) also learn what the protocol hands them, such as a received note. We report this under the chain analyst and rate it only when it reaches parties the user never dealt with voluntarily.

The public observer, chain analyst and future adversary see the same public data with increasing ability.

IP-hiding routes

An IP-hiding route hides the user’s IP from the services an app calls. Our advice names one where an app needs it. Its entry sees the user’s IP, and its exit sees the destination. We list a route when it passes three checks:

• It carries all of the app’s traffic, and the exit gets no identifier that links connections.
• One operator or hosting company holds both the entry and the exit of at most 1% of connections, at every location we test.
• Its client’s source and node list are public.

A route is decentralised when any two operators or hosting companies together hold the entry and the exit of at most 10% of connections. All routes below are.

• Tor Browser: websites, each site on its own circuit.
• Tor for all traffic: Tails or Whonix on a computer, Orbot’s VPN mode on Android. Tor carries no UDP.
• NymVPN with the Random profile: all traffic on desktop and mobile, UDP included. Its exits accept only listed ports. Its default and mixnet profiles pick gateways near the user, which fails the second check in some regions.

Reference app

Each project names a reference app, the most private released app we found for the protocol. The ratings assume this app. Other apps we checked appear below it, each with one sourced finding that shows it leaks more.

An app takes the spot when it leaks less to the five adversaries. Only released builds count.

App teams can propose their app in the Privacy adversaries framework thread on the ETHBEAT forum.

Categories

Categories describe how a protocol tries to hide data. Pools, shielded ledgers and anonymous access usually promise to hide a link. Stealth addresses hide a recipient. Confidential amounts hide an amount. Secret ballots hide how each voter voted. A project keeps its category even when it fails that promise.

Summary table

Next to the adversary ratings, the privacy summary shows:

• Anonymity set: For link privacy, unique depositors over the last 30 complete UTC days, in the largest tracked pool. For recipient privacy, unique addresses that registered stealth keys in the last 30 complete UTC days.
• Trusted setup: Trusted setup used by the project’s proving system and its risk. Risks follow the Trusted Setups Risk Framework.
• Exit window: Time users have to withdraw before a malicious upgrade can take effect.
• Walkaway test: The walkaway test says whether users can still fully use the protocol if every centralized participant disappears.
• Reproducibility: Whether all source code needed to audit the protocol and participate in it is published and can be used locally.

Feedback on the framework is welcome in the Privacy adversaries framework thread on the ETHBEAT forum.