Ethereum Privacy: The Road to Self-Sovereignty

Special thanks go to Paul Dylan-Ennis, Tim Beiko, and Vitalik Buterin for feedback and review.

Consider this roadmap a work in progress with many moving parts. Its primary goal is to offer a tangible direction for building a privacy-first Ethereum, while each outlined approach demands its own discussion and research. You can share your feedback on this blog post in the discussion thread here.

Ethereum must provide privacy unconditionally, without forcing users to prove their innocence.

This roadmap outlines the necessary steps to transform Ethereum into a maximally private and self-sovereign financial system. Privacy must not be an optional feature that users must consciously enable — it must be the default state of the network. Ethereum's architecture must be designed to ensure that users are private by default, not by exception.

Today, Ethereum operates in a partial, opt-in privacy model, where users must take deliberate steps to conceal their financial activities — often at the cost of usability, accessibility, and even effectiveness. This paradigm must shift. Privacy-preserving technologies should be deeply integrated at the protocol level, allowing transactions, smart contracts, and network interactions to be inherently confidential. A system that treats privacy as suspicious by default is fundamentally flawed. Ethereum must empower users with unconditional privacy — making self-sovereignty a guarantee, not a privilege.

Principles of Sovereignty and Risk

Unconditional privacy comes with tradeoffs. It will be used by both the innocent and the malicious. But if privacy is granted only to those who can justify it — based on innocence, identity, or intent — then it is no longer a right. It's a permission. And permissions can be revoked.

This roadmap is rooted in the Cypherpunk belief that freedom must never be weakened in the name of safety. Privacy tools — like encryption, shielded transactions, and obfuscated smart contracts — are neutral. They do not create harm; they prevent it. Their misuse should be addressed by punishing harmful actions, not by restricting access to the tools themselves.

As articulated in the Open Access section of my The Ethereum Cypherpunk Manifesto, essential tools and infrastructure — privacy included — must remain universally accessible. A permissionless system cannot pick and choose which freedoms are acceptable to express. If we allow core technologies to be restricted based on how they might be misused, we risk ceding control to gatekeepers and undermining the very principles Ethereum was built upon.

We don't defend freedom by breaking it. We defend it by building stronger protections for the innocent, and holding the guilty accountable — without turning everyone into a suspect.

This is the foundation of everything that follows. Each phase is not a technical milestone alone — it's a step toward a world where privacy is not a feature, not a favour, but a default.

Status Quo

Currently, Ethereum's transparency model presents significant challenges to privacy. Publicly accessible transaction graphs allow anyone to trace the flow of funds between accounts, and balances are visible to all participants in the network, undermining financial privacy. While the Ethereum network's transparency fosters trustlessness, it also opens the door to potential surveillance, targeting, and exploitation.

The current state presents several specific technical challenges^[1]:

• Address reuse: The account-based model encourages address reuse, creating persistent identities tied to on-chain activity.
• Public state: All contract state variables are publicly readable, making truly private applications impossible without additional cryptography.
• MEV vulnerability: The transparent mempool enables Maximal Extractable Value (MEV) extraction primarily at users' expense.
• Metadata leakage: Network-level metadata, including IP addresses and transaction propagation patterns, can de-anonymise users even when using application-level privacy tools.

To address these issues, several privacy solutions have emerged within the Ethereum ecosystem:

• Tornado Cash: A zk-SNARK-based mixer that obfuscates transaction trails by breaking the link between sender and receiver. While effective, Tornado Cash faces usability challenges and ongoing regulatory scrutiny (with a recent win!), and its reliance on Ethereum's base layer makes it subject to the same public transparency issues.

• Aztec: Aztec offers a Layer 2 privacy solution that leverages encrypted state mechanisms through their Noir language for zero-knowledge circuit development. This enables confidential transactions within its ecosystem while still allowing verifiability, although the adoption and scalability of Aztec are still evolving.

• RAILGUN: RAILGUN leverages zero-knowledge proofs to shield transaction details but faces the limitation of needing broader adoption and integration across the Ethereum ecosystem. It also offers conditional privacy through Private Proofs of Innocence. Its system architecture utilises zk-SNARKs with Groth16 proofs and a smart-contract-based shielded pool model.

• Privacy Pools: Privacy Pools is another privacy solution, employing a multi-layered design with an upgradeable contract layer, a zero-knowledge layer, and an Association Set Provider (ASP) layer. Due to the ASP layer, it provides conditional privacy. As a relatively new project, its long-term success and integration impact are yet to be fully assessed, and like others, it faces usability and integration challenges as an application-layer solution.

These efforts represent valuable steps forward, but they are not fully integrated into the Ethereum base layer and remain limited in scope and scalability. Privacy is still largely a secondary feature, and a comprehensive, seamless solution that protects all aspects of Ethereum usage is still lacking.

A Step-by-Step Roadmap to Privacy

To establish Ethereum as a maximally private and self-sovereign financial system, the roadmap takes a structured and incremental approach:

1. Phase 1: Foundational Transaction Privacy
2. Phase 2: Private ERC-20 and ERC-721 Transactions
3. Phase 3: Private Smart Contracts & Execution
4. Phase 4: Protocol-Level Privacy Integration & Ordering
5. Phase 5: Quantum-Resistant Privacy and Finalisation

Phase 1: Foundational Transaction Privacy

The first step is to shield native ETH transactions and protect user activity before it is confirmed on-chain. This involves rethinking Ethereum's transaction model while securing both execution privacy and mempool privacy.

1. Confidential ETH Transactions

• Rethinking transaction formats: Introduce a new transaction structure supporting privacy natively. Transactions should obscure sender, recipient, and amounts while remaining compatible with Ethereum validation. EIPs like EIP-7503 (WormholeTxType) offer potential foundations for generalisation.
• Zero-knowledge proofs (ZKPs): Utilise zk-SNARKs to validate transactions without revealing inputs, maintaining Ethereum's security while enabling privacy (e.g., proving sufficient funds without revealing balances).
• Sealed amounts and addresses: Employ cryptographic commitments like Pedersen commitments to encrypt transaction values. Implement native stealth addresses (building beyond EIP-5564) to generate one-time recipient addresses, disrupting blockchain analysis.
• Mana (aka gas^[2]) privacy: Obfuscate mana usage patterns, which can leak information even with confidential transactions. Explore techniques like randomised fee structures or dummy mana consumption.
• Seamless integration: Ensure Ethereum clients (e.g., Geth) can efficiently verify the necessary zero-knowledge proofs. Leverage Account Abstraction (EIP-4337) to allow smart contract wallets to manage privacy features automatically for users.
• Efficiency considerations: Zero-knowledge circuits must be highly optimised for performance (proving time, proof size, verification cost) to be practical in real-world applications. At the same time, they must preserve strong auditability and verifiability, enabling independent inspection, formal analysis, and compatibility with evolving protocol standards. These circuits must efficiently prove ownership, balance consistency, and transaction validity under strict cryptographic soundness guarantees. Tools like ZoKrates, snarkjs, and Circom provide a foundation for building such systems. The overarching goal is to minimise user friction and performance overhead without compromising trust assumptions or protocol transparency.

2. Encrypted Mempool

• Threshold encryption: Transactions should remain encrypted while propagating through the mempool. A threshold scheme can ensure decryption only occurs upon block inclusion via validator consensus, preventing single points of failure or censorship.
• MEV mitigation via encryption: Encrypting transaction details until near execution significantly hinders common forms of MEV like front-running and sandwich attacks.
• Early commit-reveal mechanisms: Explore cryptographic commit-reveal schemes where transactions commit to their actions without revealing details until inclusion, reducing validators' ability to reorder for profit.
• Inspiration from existing research: Build upon research like Shutter Network's encrypted mempool concepts.

3. Early MEV Protection & Network Privacy

• Enhanced proposer-builder separation (PBS): Implement PBS designs with privacy-enhanced relays that offer stronger confidentiality guarantees than initial versions (e.g., Flashbots Protect).
• Network-level anonymity: Integrate or encourage protocols like Dandelion++ to obscure transaction origins at the peer-to-peer level, mitigating IP address tracing and censorship. Consider integration with mixnets like Nym for stronger guarantees.
• Decoy traffic & mixing: Explore wallet-level strategies like sending decoy transactions or participating in background mixing to further obfuscate real user activity patterns.

4. UX & Wallet Integration

• Invisible privacy defaults: Privacy features should be enabled by default in wallets wherever feasible. Users should not need to be cryptography experts to benefit. Wallets must handle stealth address generation, encryption, and proof generation automatically.
• Seamless onboarding: Integrate privacy tools into popular existing wallets (e.g., MetaMask, Rabby) via Snaps, SDKs, or native integration, rather than forcing users onto niche, privacy-only wallets.
• User-friendly recovery: Develop secure and usable recovery mechanisms for private accounts/keys, exploring options like social recovery adapted for privacy contexts.
• Education: Clearly communicate the benefits and workings (at a high level) of privacy features to users and developers to foster understanding and adoption.

Phase 1 rethinks Ethereum's transaction model for initial privacy layers. Hiding on-chain details is insufficient if the mempool and network layers leak metadata. By combining confidential transactions, initial mempool encryption, basic MEV resistance, and network anonymity — alongside vital UX improvements — Phase 1 lays the groundwork for end-to-end privacy.

Phase 2: Private ERC-20 and ERC-721 Transactions

With foundational ETH privacy underway, the next step is extending privacy guarantees to token transfers. This phase ensures both fungible (ERC-20) and non-fungible (ERC-721) assets benefit from confidentiality, protecting user balances, transfers, and ownership metadata. Importantly, this is not just a natural extension — it's critical for ETH privacy to succeed in practice. Without privacy-preserving equivalents for widely used tokens (e.g. WETH), applications and exchanges may default to accepting only public assets, undermining the broader goal of end-to-end privacy.

1. Confidential ERC-20 Transactions

• Develop a standard (i.e., via EIP) for private fungible token transfers, potentially extending concepts from past proposals like ERC-1724 but using modern zk-SNARK constructions (e.g., PlonK, Halo2) leveraging nullifiers and commitments for efficiency and security. This standard should provide a migration path for existing tokens, allowing them to opt into privacy pools seamlessly, preserving liquidity while ensuring privacy.
• Implement confidential asset transfers akin to protocols like Zcash's Sapling, using nullifiers to prevent double-spending and cryptographic commitments to hide amounts, ensuring transaction unlinkability.
• Standardise commitment schemes and efficient range proofs (using constructions like those in PlonK or Halo2) for token amounts to improve verification efficiency.
• Encourage the development of shielded pools with large, growing privacy sets (aiming for >10,000 users initially) to provide meaningful anonymity guarantees.

2. Shielded NFT Ownership and Transfers

• Design a standard (i.e., via EIP) for private ERC-721 transfers that conceals ownership links and transaction history, allowing NFTs to be held and transferred discreetly. This standard should provide a seamless migration path for existing NFTs, allowing them to opt into privacy pools or shields, preserving liquidity while ensuring privacy.
• Utilise zero-knowledge proofs for verifying NFT ownership or attributes without revealing the owner's identity publicly.
• Explore Merkle-based ownership registries where users can prove ownership via zk-proofs of inclusion, similar to Zcash's note commitment tree, ensuring private yet verifiable ownership.

3. Layer 2 Privacy Enhancements

• Standardise private state transitions in rollups, perhaps via a common interface like zkInterface, to enable consistent cross-layer privacy guarantees.
• Promote native support in zk-Rollups for confidential transactions, leveraging privacy-preserving validity proofs for scalable and efficient private transfers.
• Enable private cross-rollup transfers using standardised SNARK-friendly hash functions and commitment schemes.
• Design privacy-preserving bridges between L1 and L2s, and between different L2s, potentially using shared anonymity set models where feasible.
• Ensure Layer 2 solutions can leverage Ethereum's evolving data availability layers (e.g., EIP-4844 blobs) cost-effectively for publishing the data needed for private state proofs.

Phase 2 builds on Phase 1 by extending privacy from native ETH transactions to all tokenised assets. With confidential ERC-20 transfers, shielded NFT ownership, and privacy-focused Layer 2 standards, this phase aims for comprehensive token privacy across Ethereum and its scaling ecosystem.

Phase 3: Private Smart Contracts & Execution

With transaction and token privacy established, the next critical step is enabling private computation on Ethereum. This phase focuses on allowing smart contracts to execute confidentially, protecting sensitive inputs and state while maintaining verifiability.

1. Confidential Smart Contract Execution

• Introduce execution environments where contract logic execution and state updates remain private from the public, yet can be proven correct to the network.
• Explore mid-term solutions like zero-knowledge Virtual Machines (zkVMs) that can prove the execution of specific computation, potentially using systems inspired by RISC Zero which avoid trusted hardware assumptions.
• Develop long-term full zkEVM implementations, building on work from projects like Aztec, Polygon zkEVM, Scroll, ZKsync, or Starknet, aiming for universal privacy for arbitrary smart contracts.
• Ensure mechanisms allow for private state updates and confidential interactions between contracts or users and contracts.

2. Smart Contract Logic Privacy

• Explore techniques for obfuscating^[3] contract bytecode or using cryptographic methods to prevent easy reverse-engineering of contract logic by adversaries.
• Utilise cryptographic commitments and zero-knowledge proofs to allow users or systems to verify correct execution according to a specific (but hidden) contract logic.
• Develop methods for zkSNARK-based contract verification where a proof attests that a contract executed correctly, without revealing the execution trace or intermediate states.
• Foster standardised libraries (similar to OpenZeppelin Contracts) for common DeFi primitives (swaps, lending, etc.) with built-in, audited privacy-preserving implementations.
• Model privacy-preserving contract development frameworks on languages designed for ZKPs, like Noir or Leo, to simplify development.

3. Privacy Precompiles

• Introduce EVM precompiles for verifying common zk-SNARK schemes (e.g., Groth16, PlonK, Halo2) to drastically reduce the mana cost of on-chain proof verification.
• Consider adding precompiles for basic Fully Homomorphic Encryption (FHE) operations or Secure Multi-Party Computation (MPC) primitives (inspired by libraries like MPyC) to enable different forms of collaborative confidential computation.
• Ensure these precompiles are mana-optimised implementations of well-vetted, secure cryptographic operations.

Phase 3 ensures Ethereum's programmability extends into the private domain. By enabling confidential execution, protecting contract logic, and providing efficient cryptographic primitives via precompiles, this phase paves the way for a rich ecosystem of private applications and DeFi without sacrificing security or composability.

Phase 4: Protocol-Level Privacy Integration & Ordering

At this stage, privacy transitions from an application-layer or optional feature into a core aspect of Ethereum's protocol design. Privacy mechanisms become default where possible, trust-minimised, and deeply embedded at the consensus and execution layers, including how transactions are ordered.

1. Protocol-Native Shielded Pools

• Integrate shielded pool functionalities directly into the protocol, allowing users to move assets into fully confidential state managed by Ethereum itself.
• Utilise efficient data structures like incremental Merkle trees for tracking committed values without revealing them, optimised for protocol-level performance.
• Implement robust nullifier-based double-spend prevention directly within the protocol logic, inspired by mature systems like Tornado Cash's implementation or Zcash.
• Explore designs for cross-asset or purpose-specific shielded pools managed by the protocol to maximise anonymity sets and usability.

2. Private Cross-Layer Operations

• Establish standardised, secure, and privacy-preserving bridge protocols between Ethereum L1 and Layer 2 solutions, potentially using zero-knowledge proofs to verify state transitions without revealing user data.
• Implement confidential deposit and withdrawal mechanisms between layers that obscure the link between L1 and L2 addresses involved in the transfer.
• Utilise standardised ZKP formats for cross-layer state proofs to ensure interoperability and security.
• Aim for a unified or shared anonymity set model across layers where feasible to prevent fragmenting user privacy.

3. Private and Fair Order Flow

• Build upon early encrypted mempool work (Phase 1) to implement robust protocol-level solutions for private transaction ordering. This includes sealed-bid auctions for block space, potentially using threshold encryption or commit-reveal schemes, ensuring proposers cannot front-run or sandwich based on full transaction content.
• Integrate fair ordering protocols, potentially based on Verifiable Delay Functions (VDFs) or other cryptographic sortition techniques, to prevent proposer censorship or malicious reordering.
• Design and implement cryptoeconomic mechanisms (e.g., slashing conditions) to strongly disincentivise validators or builders from attempting to break privacy or fairness guarantees.
• Refine commit-reveal schemes with threshold decryption, ensuring transaction contents are only revealed immediately before execution or after ordering is finalised.

Phase 4 solidifies Ethereum's privacy as protocol-native, not merely an application-layer feature. With deeply integrated shielded pools, secure private cross-layer operations, and robust private, fair order flow mechanisms, Ethereum transitions towards being a privacy-first execution environment by default, while preserving scalability and decentralisation.

Phase 5: Quantum-Resistant Privacy and Finalisation

As quantum computing capabilities advance, Ethereum's cryptographic foundations — especially those underpinning privacy — must be future-proofed. This phase focuses on migrating to post-quantum cryptographic primitives, implementing a fully private zkVM, and performing final optimisations to ensure long-term robustness.

1. Post-Quantum Cryptographic Migration

• Plan and execute a transition from current elliptic curve cryptography (ECDSA signatures, pairings in SNARKs) to quantum-resistant alternatives. For signatures, consider NIST standards like CRYSTALS-Dilithium or SPHINCS+.
• Design a phased migration strategy allowing legacy and quantum-resistant accounts/contracts to coexist, minimising disruption. Account abstraction could facilitate this.
• Implement quantum-resistant signature aggregation schemes to manage the potentially larger sizes of post-quantum signatures.
• Replace potentially vulnerable zk-SNARK systems (especially those relying on pairings or discrete logs) with quantum-resistant constructions, such as those based on lattices or secure hashes (like zk-STARKs).
• Provide clear migration paths and tooling for existing applications and privacy solutions (like L2s) to adopt post-quantum cryptography.

2. Full zkVM Implementation

• Develop and integrate a general-purpose zkVM capable of proving the correct execution of arbitrary EVM/smart contract logic privately. This means both state transitions and the executed logic remain confidential from the public network. Build upon maturing research and implementations from projects like Risc0, Polygon Miden, and others exploring STARK-based or similar quantum-resistant ZK proof systems.
• Ensure the zkVM leverages quantum-resistant proof systems (like zk-STARKs), which often offer transparency (no trusted setup) as a bonus.
• Optimise ZK circuit generation and proving for EVM opcodes and common smart contract patterns, aiming for competitive proof generation times (e.g., ideally sub-5 seconds for typical transactions).
• Create mature developer tooling and high-level languages (building on ideas from Noir etc.) specifically designed for privacy-first smart contract development on the zkVM.

3. Privacy Hardening and Optimisation

• Implement cutting-edge optimisations for existing (pre-quantum migration) proof systems like PlonK and Halo2 (e.g., recursion, aggregation techniques like Nova) to minimise proof sizes and on-chain verification costs.
• Continuously optimise STARK-based proving systems to improve proof size and verification efficiency, keeping them competitive with SNARKs.
• Encourage development and standardisation of hardware acceleration (FPGA/ASIC) for core cryptographic operations (both pre- and post-quantum) to reduce proving times for users and provers.
• Further optimise mana costs for privacy-related operations through the EIP process, ensuring private transactions remain economically viable.
• Develop comprehensive test suites, formal verification methods, and ongoing audits for all privacy protocols integrated into Ethereum.

Phase 5 ensures Ethereum's privacy stack remains secure and efficient long-term, even in a post-quantum world. By migrating critical cryptography, enabling fully private and universal smart contract execution via a zkVM, and relentlessly optimising performance, Ethereum can maintain robust privacy guarantees while remaining scalable and secure for the future.

The Path Forward

Privacy is not optional; it is the backbone of self-sovereignty and digital freedom. Achieving this vision requires a concerted, sustained effort from developers, researchers, cryptographers, and the broader Ethereum community.

The roadmap outlined here presents a phased, technically grounded approach, leveraging existing research and proposing future directions. However, realising this vision demands more than just technical breakthroughs; it necessitates careful consideration of how such a significant focus on privacy integrates with Ethereum's ongoing development roadmap and governance processes.

A critical discussion point is how this privacy-first direction aligns with existing priorities like the The Merge, The Surge, The Scourge, The Verge, The Purge, and The Splurge. Does adopting this renewed emphasis mean revisiting the current roadmap to elevate privacy? Or could this function as a distinct, parallel development track, perhaps akin to a new "Privacy Pillar", aligning with evolving ideas about structuring core development (such as the concept of more parallelised workstreams discussed within the community, e.g., Tim Beiko's post on reconfiguring AllCoreDevs (ACD))?

Furthermore, the scale and specialised nature of this undertaking might benefit from dedicated coordination efforts. Could focused working groups, similar in spirit to the Robust Incentives Group (RIG) or potentially structured as distinct initiatives, be necessary to drive the research, specification, and implementation phases effectively? Drawing inspiration from ZK teams not directly focused on privacy, such as 0xPARC and PSE, could offer valuable insights into how specialised efforts can be structured for maximum impact. Addressing these organisational and procedural questions is vital for turning the technical vision into reality.

The optimal path for integrating this privacy focus — be it through reprioritisation, parallel tracks, dedicated groups, or other means — is deliberately left as an open question in this roadmap. Finding the answer requires thorough discussion and consensus building within the broader Ethereum community.

Ultimately, whether this roadmap represents a reprioritisation, a new parallel effort, or a catalyst for evolving governance itself, its implementation path requires broad community discussion and consensus. While specific protocol changes will proceed through the established EIP process, the strategic integration of this privacy focus needs buy-in and rigorous review at every level. Challenges around usability, interoperability with the transparent world, and user education must be tackled concurrently with these governance considerations.

With a shared commitment — both technical and procedural — privacy can (and must) become an inherent part of Ethereum's DNA. The time to build this future, and determine how we build it collectively, is now.

Let's make Ethereum Cypherpunk again!