---
date: 2026-02-20
tags: [blog, pse.dev, privacy-stack, strategy, ecosystem]
status: draft
target: pse.dev blog
---

# Ethereum's Privacy Stack: What Leaks, What's Fixed, and What's Missing

Privacy on Ethereum is not one problem. It's at least six.

You can use a shielded pool to hide a swap, but your RPC provider still sees the query that triggered it. You can submit transactions through private RPC, but the builder processing them sees the full plaintext. You can hide your onchain activity behind zero-knowledge proofs, but your IP address leaks to every peer in the gossip network.

The result is that users get a false sense of security, and builders don't know what they're missing or what ecosystem gaps exist.

At PSE, we've been building a model to see the full picture. We call it the Ethereum Privacy Stack. It maps every point in the Ethereum architecture where information leaks, who's building fixes, and where the gaps remain. This post walks through the first iteration of this mental model.

The goal is to give privacy builders, funders and activist a way to reason, understand dependencies, and see what's missing above and below.

## The Model

The stack has five layers plus one cross-cutting concern. From top (user-facing) to bottom (protocol infrastructure):

| Layer | Privacy Question | What Leaks Today |
|-------|-----------------|-------------------|
| **1. Applications** | Who is using this? | Identity, activity patterns, anonymity set size |
| **2. Wallets** | Which identity is acting? | Address correlation across dApps, IP leakage |
| **3. Gateway** | What are you reading and submitting? | RPC queries, tx content, IP address |
| **4a. Execution / State** | What's visible on-chain? | Balances, transfer history, calldata |
| **4b. Mempool** | What's visible before inclusion? | Tx content, ordering opportunity for MEV |
| **5. Consensus** | Who is validating? | Proposer identity, validator behavior |
| **Networking** | Who is talking to whom? | IP, timing, gossip patterns at every layer boundary |

Three design principles make this model work:
- **Layers are defined by what they abstract**, not by what they contain.
- **Reads and writes fork at Layer 4.** When a user queries state, the path is Gateway to Execution/State (and stops there). When a user submits a transaction, the path is Gateway to Mempool to Consensus.
- **Networking is cross-cutting.** Every layer boundary has a transport privacy concern. The gossip network leaks metadata at the mempool layer. WalletConnect leaks wallet-to-dApp pairings at the wallet layer.

## Layer by Layer

### Layer 1: Applications -- Who is using this?

The application layer is where users interact with privacy features directly: anonymous group membership (Semaphore), private voting (MACI), shielded transfers with compliance proofs (Privacy Pools), and identity attestation without document disclosure (zkEmail, Anon Aadhaar). Here is where use cases live:
- finance:: transfers & defi
- governance:: voting & collaborating
- identity

This is Ethereum's strongest layer. The apps and tools exist, they work, and several are in production.

**The gap is below.** Application-level anonymity sets are only as strong as the layers underneath. A Semaphore group proof that proves membership without revealing identity is worthless if the user's RPC provider logs the query that generated the proof. Privacy at this layer depends entirely on the layers below.

### Layer 2: Wallets -- Which identity is acting?

The wallet layer manages keys, identities, and signing. The privacy question: can an observer correlate a user's activity across addresses?

Today, the answer is almost always yes. MetaMask, with 30 million monthly active users, has zero privacy features -- it leaks IP addresses to the RPC provider, uses a single connection for all accounts, and ships with telemetry. The most-used wallets are the least private.

**Who's building:** Brume Wallet does per-account Tor isolation (unique circuit per address). Railgun provides shielded balance management with $100M TVL. Blanksquare offers a privacy SDK with ~1s ZK proof generation. PSE is building Kohaku SDK as a reference privacy wallet.

**The gap:** Wallet-level privacy depends on wallet adoption. The privacy-preserving options are niche. Until the mainstream wallets integrate basic features -- per-account network isolation, stealth address support, zero telemetry -- the wallet layer remains the weakest link for most users.

### Layer 3: Gateway -- What are you reading and submitting?

The Gateway is where user-space meets protocol-space: where your wallet connects to the Ethereum network, where your queries go out, and where your transactions go in. It is the single biggest metadata chokepoint on Ethereum today.

**The read side:** Infura handles over 50% of all Ethereum RPC traffic. Every eth_call, every balance check, every contract read -- logged, with your IP. Even if your on-chain activity is shielded, your RPC queries reveal what you're looking at. Private Information Retrieval (PIR) and TEE-ORAM are research-stage solutions that would let users query state without revealing which state they're querying.

**The write side:** Flashbots Protect and MEV Blocker are production solutions for private transaction submission, routing around the public mempool to prevent frontrunning. Over 50% of Ethereum transactions already use private submission channels. But these are trust-based: the operator sees your full transaction.

**The gap:** Read privacy is almost entirely unsolved. Nobody in the ecosystem except PSE is working on production-grade private state queries. This is the layer where a single infrastructure change -- a private RPC standard -- could have the highest leverage across the entire stack.

### Layer 4a: Execution / State -- What's visible on-chain?

After a transaction is included in a block, what can observers learn from the on-chain record? Balances, transfer amounts, contract interactions, calldata -- by default, everything is public.

**Who's building:** This is the most crowded layer. Railgun uses zk-SNARKs for shielded balances. Privacy Pools adds compliance through proofs of innocence. Stealth addresses (EIP-5564) provide unlinkable recipient addresses, with FluidKey, Umbra Cash, and Curvy all shipping implementations. On the confidential compute side, Zama's fhEVM brings fully homomorphic encryption to EVM contracts (mainnet since December 2025), and Fhenix, Inco, and Nillion offer variants of encrypted computation.

**The gap:** Fragmentation. There are many teams building execution-layer privacy, but no interoperability standards. Shielded state from Railgun can't compose with Privacy Pools. FHE-encrypted state on Zama can't interact with ZK-shielded state on Aztec. The opportunity here isn't another privacy protocol -- it's a standards convening role that helps these solutions interoperate.

### Layer 4b: Mempool -- What's visible before inclusion?

Before your transaction lands in a block, it passes through the mempool -- and today, that means broadcasting its contents to anyone watching. The result: MEV extraction. Sandwich attacks alone accounted for 51% of all MEV on Ethereum in 2025, extracting $290 million from users.

Mempool privacy is evolving through three generations, each reducing trust assumptions:

**Gen 0: Public mempool.** The current default. Your transaction is visible to everyone. Bots sandwich you. No protection.

**Gen 1: Private mempools** (Flashbots Protect, MEV Blocker, Alchemy). You send your transaction to a trusted operator instead of broadcasting publicly. The operator sees your full transaction but promises not to exploit you. In exchange, you can get kickbacks -- MEV-Share returns approximately 90% of backrun profits to users. Trust model: "won't be evil."

**Gen 2: Encrypted mempools** (EIP-8105 / Shutter, Fairblock). Your transaction is encrypted before submission and decrypted only after ordering is committed. Nobody -- not the builder, not the proposer, not the relay -- sees the plaintext until it's too late to reorder. Trust model: "can't be evil." Trade-off: +1 slot latency (~12 seconds), no orderflow revenue.

**The gap:** Gen 1 is production. Gen 2 is not yet live on Ethereum mainnet (Shutter runs on Gnosis Chain today). EIP-8105 proposes enshrining encrypted mempools at the protocol level for Ethereum's Hegota upgrade. This is the most significant near-term protocol change for user protection.

Gen 1 and Gen 2 will coexist. Gen 1 offers revenue (you get paid for your orderflow). Gen 2 offers guarantees (nobody can exploit you, period). Over time, Gen 2 becomes the default floor, and Gen 1 competes on value-adds above it. The long-term direction: privacy should be infrastructure, not a service you subscribe to.

### Layer 5: Consensus -- Who is validating?

The consensus layer determines who proposes and validates blocks. The privacy concern: if the next proposer is known in advance, they can be targeted for DOS attacks or bribed for censorship.

**The numbers are alarming.** A USENIX 2025 study demonstrated that 15% of Ethereum validators could be deanonymized using just 4 monitoring nodes over 3 days. Validator identity leakage is not theoretical -- it's measured.

**Who's building:** Secret leader election (SSLE/WHISK) hides the next proposer's identity until their slot. Distributed Validator Technology (Obol, SSV Network) eliminates single-operator targets. FOCIL (forced inclusion lists) provides censorship resistance by letting validators force-include transactions.

**The gap:** These are all protocol-level changes requiring hard forks. The timeline depends on EF research priorities and the Ethereum upgrade schedule. Not a market gap -- a governance gap.

### Cross-cutting: Networking -- Who is talking to whom?

Networking is the privacy concern that nobody owns and everybody needs. At every layer boundary, transport metadata leaks: IP addresses, timing patterns, message correlation.

| Boundary | What Leaks | Fix |
|----------|-----------|-----|
| Wallet to Gateway | RPC provider sees wallet IP + all queries | Tor, Brume per-account isolation |
| Gateway to Mempool | Node operator sees submitted tx | Private relayers |
| Mempool to Mempool (gossip) | Peers identify tx origin node | Dandelion++, DC Nets |
| Consensus (gossip) | Network sees which validator proposes | SSLE / WHISK |

Two paradigms are competing: **mix networks** (Tor, Nym, HOPR) trade latency for strong anonymity, routing packets through multiple mixing layers. **DC Nets** (Flashbots' NAMP/FlashNet) trade bandwidth for latency, using secret-sharing schemes that offer anonymity without the mixing delay.

**The gap:** This is the least-addressed layer overall. No mandatory network-layer privacy exists on Ethereum. Tor and mixnets are opt-in. Dandelion++ was explored and found impractical for the consensus layer. DC Nets are research-stage. Meanwhile, every other layer's privacy guarantees are degraded by network-level metadata leakage.

## Where the Gaps Are

Taken together, here's the ecosystem health across the full stack:

| Layer | Health | Biggest Gap | Who Should Act |
|-------|--------|-------------|----------------|
| **Applications** | Strong | Anonymity sets are limited by the layers below | App devs: integrate private wallets and RPCs |
| **Wallets** | Weak | Dominant wallets have zero privacy | Wallet teams: adopt stealth addresses, per-account isolation |
| **Gateway** | Weak | Read privacy is unsolved at scale | Infra teams: PIR and private RPCs need production implementations |
| **Execution / State** | Moderate | Fragmented, no interoperability | Standards bodies: coordinate shielded state formats |
| **Mempool** | Strong (external) | Encrypted mempools not yet on mainnet | Protocol devs: advance EIP-8105 for Hegota |
| **Consensus** | EIP-dependent | Proposer anonymity requires a hard fork | EF research: SSLE/WHISK timeline |
| **Networking** | Weak | No mandatory network privacy | Core devs: this is the universal gap |

Two patterns stand out:

**First, the top layers are strong and the bottom layers are weak.** Applications and mempool solutions are production-grade. Wallets, Gateway, and Networking are not. This means the ecosystem has built good tools for specific use cases but hasn't secured the infrastructure those tools depend on.

**Second, the weakest layers are the ones with the least market incentive.** Read privacy, wallet-level isolation, and network-layer anonymity don't have obvious business models. Nobody charges for "your RPC queries are private." These are public goods -- and they're underinvested precisely because of that.

## What This Means

Privacy is not a feature you bolt onto a single layer. It's a property of the full stack. A leak at any layer compromises the layers above it. An encrypted mempool doesn't help if the gateway leaks which transactions you're submitting. A shielded transfer doesn't help if your wallet correlates your accounts. A zero-knowledge proof doesn't help if the network reveals your IP address to everyone in the gossip layer.

The stack model gives every project in the ecosystem a way to locate itself, see what's above and below, and understand what it needs from its neighbors. If you're building an application: what wallet-level guarantees do you depend on? If you're building a wallet: what gateway privacy does your user need? If you're building mempool infrastructure: what networking assumptions are you making?

PSE's role is to work on the layers where market incentives alone won't produce solutions. That means Gateway (read privacy, where nobody else is building), tooling (private proving, where the barrier to adoption is developer experience), and coordination across the stack (because privacy at one layer without the others is privacy theater).

The full ecosystem map, team profiles, and landscape analyses behind this model are being published alongside this post. If your project fits somewhere in this stack, we want to hear from you.