Title: Network-Level Anonymity · Pattern · EthSystems

URL Source: https://original.es-internal.pages.dev/patterns/pattern-network-anonymity/

Markdown Content:
---
description: Hide who is sending transactions or querying state at the network layer. Content-privacy patterns (ZK, FHE, MPC) hide what is in a transaction but not who submitted it: IP addresses, timing, and query patterns still leak sender identity. Network-level anonymity complements content privacy to close the metadata gap.
title: Network-Level Anonymity · Pattern · EthSystems
image: https://original.es-internal.pages.dev/og.png
---

[Skip to content](#main-content) 

#### Works best when

* Metadata leakage (IP, timing, query patterns) is a threat model concern.
* Content privacy alone is insufficient; who matters as much as what.
* Both read privacy (RPC queries) and write privacy (transaction submission) are needed.

#### Avoid when

* Threat model does not include network-level observers.
* On-chain content privacy is the only requirement.

### I2I vs I2U — context differences

Institutions typically run dedicated nodes or relays, so the metadata threat surface is inter-institutional rather than user-to-institution. Network anonymity hides query patterns and settlement-transaction submission from counterparty infrastructure.

The institution itself is often the network observer: it operates the RPC endpoint, sequencer, or relay through which users submit transactions and query state. Transport-layer protection is a precondition for meaningful user privacy, even when content-layer privacy (encrypted balances, shielded transfers) is already in place.

## Components

* Transport anonymity layer: a relay network, mix network, or hardware-assisted cluster that strips or obscures sender metadata before the message reaches the destination.
* Client routing or submission library: prepares the message for the chosen anonymity layer (layered encryption, mix encoding, or secret sharing).
* Destination: RPC endpoint, sequencer, or transaction mempool. The anonymity layer sits between the client and the destination.

Each sub-pattern instantiates these components differently. See `sub_patterns` in frontmatter.

## Anonymity trilemma

Any network anonymity system trades off between three properties:

* Anonymity set size: how many users your traffic blends with.
* Latency: delay introduced by the anonymity mechanism.
* Bandwidth overhead: cover traffic or padding required.

Pure-cryptographic approaches (onion routing, mixnets) must sacrifice at least one. Hardware-assisted approaches (TEE) relax the trilemma by offloading verification to hardware, but introduce a hardware trust assumption.

| Approach      | Latency                   | Anonymity strength | Trust assumption                      |
| ------------- | ------------------------- | ------------------ | ------------------------------------- |
| Onion routing | Moderate (100-500ms)      | Strong             | No single relay sees full path        |
| Mixnet        | High (seconds to minutes) | Strongest          | Threshold mix nodes and cover traffic |
| TEE-assisted  | Low                       | Medium             | Client TEE and server majority        |

## Guarantees & threat model

Guarantees:

* Hides sender IP, timing correlation, and query-to-identity mapping. Strength varies by sub-pattern.
* Complements content-privacy patterns. Together they hide both what and who.

Threat model:

* Pure-cryptographic approaches are vulnerable to a global passive adversary capable of correlating traffic at both ends of a circuit. Mixnets mitigate this via cover traffic; onion routing does not.
* Hardware-assisted approaches depend on TEE attestation integrity and are exposed to side-channel attacks on the underlying hardware.
* Does not hide message content. Pair with ZK, FHE, or MPC patterns for full-stack privacy.
* No Ethereum execution client natively supports any network anonymity layer as of 2026-04, unlike Bitcoin Core which has had built-in Tor support since 2016\. Integration requires external tooling.

## Trade-offs

* Stronger anonymity generally means higher latency; institutional latency requirements constrain the choice.
* Operational complexity varies: onion routing has mature tooling; mixnet integration remains non-trivial; TEE-assisted is research-stage.
* Coverage must be end-to-end. Mixing network anonymity for writes with a plain-HTTPS RPC provider for reads reintroduces the metadata gap.

## See also

* [Modular Privacy Stack](/patterns/pattern-modular-privacy-stack/): where network anonymity fits in the four-layer architecture.
* [RFP: Private Reads](../rfps/rfp-private-reads.md): read-side privacy gap.

### Variants

1. [ 01 Onion routing Medium CR, partial privacy, medium latency. Large external anonymity set; vulnerable to global passive adversaries. → ](/patterns/pattern-onion-routing/)
2. [ 02 Mixnet anonymity Medium CR, partial privacy, very high latency. Strongest resistance to traffic correlation via cover traffic. → ](/patterns/pattern-mixnet-anonymity/)
3. [ 03 TEE-assisted network anonymity Medium CR, partial privacy, low latency. Hardware trust assumption relaxes the anonymity trilemma. → ](/patterns/pattern-tee-network-anonymity/)

### Open-source implementations

* [ pse.dev TypeScript, WASM Tor-in-WASM library for browser-side onion routing from dApps ↗ ](https://pse.dev/projects/tor-js)
* [ gitlab.torproject.org Rust Rust implementation of the Tor protocol ↗ ](https://gitlab.torproject.org/tpo/core/arti)
* [ github.com Rust Mixnet with cover traffic ↗ ](https://github.com/nymtech/nym)

#### Referenced by

approaches4
* [Civic Participation](/approaches/approach-civic-participation/)
* [Private Identity](/approaches/approach-private-identity/)
* [Private Payments](/approaches/approach-private-payments/)
* [Private Transaction Broadcasting](/approaches/approach-private-broadcasting/)
use cases2
* [Private Payments](/use-cases/private-payments/)
* [Resilient Disbursement Rails](/use-cases/resilient-disbursement-rails/)
building blocks13
* [Cross-Chain Privacy Bridge](/patterns/pattern-cross-chain-privacy-bridge/)
* [Mesh Store-and-Forward Submission](/patterns/pattern-mesh-store-forward-submission/)
* [Mixnet Anonymity](/patterns/pattern-mixnet-anonymity/)
* [Onion Routing](/patterns/pattern-onion-routing/)
* [Private Information Retrieval](/patterns/pattern-private-information-retrieval/)
* [Private Stablecoin Shielded Payments](/patterns/pattern-private-stablecoin-shielded-payments/)
* [Private Transaction Broadcasting](/patterns/pattern-private-transaction-broadcasting/)
* [Relay-Mediated Proving](/patterns/pattern-relay-mediated-proving/)
* [Shielding](/patterns/pattern-shielding/)
* [Stealth Addresses](/patterns/pattern-stealth-addresses/)
* [TEE-Assisted Network Anonymity](/patterns/pattern-tee-network-anonymity/)
* [Threshold-Encrypted Mempool](/patterns/pattern-threshold-encrypted-mempool/)
* [User-controlled viewing keys](/patterns/pattern-user-controlled-viewing-keys/)

×

```json
{"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://ethsystems.org/#organization","name":"EthSystems","url":"https://ethsystems.org/","logo":"https://ethsystems.org/icon-maskable.png","sameAs":["https://x.com/eth_systems","https://www.linkedin.com/company/ethsystems/","https://github.com/ethsystems"]},{"@type":"WebSite","@id":"https://ethsystems.org/#website","url":"https://ethsystems.org/","name":"EthSystems","publisher":{"@id":"https://ethsystems.org/#organization"}}]}
```