# A maximally simple L1 privacy roadmap

Source: https://ethereum-magicians.org/t/a-maximally-simple-l1-privacy-roadmap/23459
Kiwi News: https://news.kiwistand.com/stories/A-maximally-simple-L1-privacy-roadmap?index=0x67f8a8e2202b847a053f1708f4f87c14d908b590278944ea386b12566ad9d2627d563acb
Submitted by tim on 2025-04-11 UTC, 8 upvotes, 0 comments

## Summary

The author's roadmap proposes practical privacy improvements for Ethereum users that require few consensus changes, covering onchain payments, partial anonymization within applications, RPC read privacy, and network-level anonymization. Key steps include adding privacy tools such as Railgun and Privacy Pools to existing wallets with a default "send from shielded balance" option, and moving toward one address per application by default. The roadmap also proposes implementing FOCIL and EIP-7701, using TEE-based RPC privacy as a short-term mitigation (with Automata's existing version to be verified and hardened), and eventually replacing TEEs with private information retrieval.

## Article

A maximally simple L1 privacy roadmap

See also: pcaversaccio’s roadmap: Ethereum Privacy: The Road to Self-Sovereignty - Privacy - Ethereum Research

These are my current thoughts on how we can practically improve the state of privacy experienced by Ethereum’s users in a way that is very light on Ethereum consensus changes. This covers four primary key forms of privacy:

Privacy of onchain payments

Partial anonymization of onchain activity inside applications

Privacy of reads to the chain, ie. RPC calls

Network-level anonymization

This roadmap can be combined with a longer-term roadmap that makes deeper changes to L1, or privacy-preserving application-specific rollups, or other more complex features.

Roadmap

Incorporate privacy tools (eg. Railgun, Privacy Pools) into existing wallets. Wallets should have a notion of a shielded balance, and when you send to someone else, there should be a “send from shielded balance” option, ideally turned on by default. This should all be designed to feel maximally natural from a UX perspective. Users should NOT have to download a separate “privacy wallet”

Move the ecosystem toward “one address per application” by default. This is a major step, and it entails significant convenience sacrifices, but IMO this is a bullet that we should bite, because this is the most practical way to remove public links between all of your activity across different applications. Moving toward such a design also works very naturally with in-application wallets, and the new workflows required to make this work look very similar to what is needed already with cross-chain interoperability (eg. depositing funds to a chain from one of multiple sources)

Make send-to-self privacy-preserving by default - needed to make (2) work

Implement FOCIL and EIP-7701, and make sure to implement a version of FOCIL that is EIP-7701-friendly. Along with EIP 7701’s account abstraction benefits, this allows protocols like PP, Railway, Tornado etc to operate without needing relays / public broadcasters, greatly simplifying the development and maintenance of such protocols. FOCIL greatly improves censorship resistance of all transactions, including privacy-preserving transactions.

Incorporate TEE-based RPC privacy into existing wallets, as a short-term mitigation. Automata has a version of this already; this needs to be verified and hardened as much as possible. This allows users to interact with RPC nodes while getting stronger assurances that their private data is not being collected.

Replace TEEs with private information retrieval (PIR) once the tech becomes ready. PIR offers cryptographic guarantees, and so is much stronger than TEEs, but it is currently not efficient enough for large datasets. Potentially we can consider hybrid approaches, eg. use TEEs to isolate regions of the state of size 2**20, and use PIR inside of those, shifting the constants up over time as PIR becomes more efficient.

Wallets should connect to multiple RPC nodes, optionally through a mixnet, ideally use a different RPC node per dapp. If we also add security armoring to RPC nodes (ie. light client support), it becomes practical for a user to trust a much larger set of RPC servers. This reduces metadata leakage.

Work on proof aggregation protocols to allow multiple privacy-protocol transactions to share a single onchain proof. This greatly reduces the gas costs of privacy protocols.

Work on privacy-preserving keystore wallets (see more detailed explanations in this post). This allows users to upgrade their account verification logic (algorithm or keys) in one transaction, and have this change be immediately reflected in all private notes that they control (across L1 and all L2s!), without publicly linking those notes.

At the end of this, we will have a world where:

A large portion of sends are private, and private sends are default in many cases

Activity inside of each individual application is public, but the link between your activity in application A and your activity in application B is private

Privacy guarantees hold not just against adversaries passively observing the chain, but also adversaries operating RPC nodes