Network-Level Anonymity

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.

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

Institution to institution

I2I

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.

Institution to end user

I2U

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

Variants

  1. 01

    Onion routing

    Medium CR, partial privacy, medium latency. Large external anonymity set; vulnerable to global passive adversaries.

    →
  2. 02

    Mixnet anonymity

    Medium CR, partial privacy, very high latency. Strongest resistance to traffic correlation via cover traffic.

    →
  3. 03

    TEE-assisted network anonymity

    Medium CR, partial privacy, low latency. Hardware trust assumption relaxes the anonymity trilemma.

    →

Open-source implementations