What Is the Privacy Stewards of Ethereum (PSE) Initiative and Why It Matters

Privacy has always been a paradox on Ethereum. The network is pseudonymous, as users transact with addresses rather than legal names. Still, it is also radically transparent: every transfer, approval, and contract call lives forever on a public ledger.

Over the last few years, Ethereum researchers, protocol developers, and builders have been converging on a multi-layered roadmap to square that circle: keep what needs to be public verifiable and public, while giving users practical tools to keep sensitive information confidential and to prove facts about themselves without doxxing their entire history.

The Ethereum Privacy & Scaling Explorations (PSE) program was rebranded and unveiled its roadmap on Sept. 15, 2025. The initiative, now called Privacy Stewards of Ethereum (PSE), released a roadmap detailing its long-term strategy to build end-to-end privacy features into the Ethereum ecosystem. 

This guide walks through the significant pieces of that roadmap, from private payments and “selective disclosure” primitives, to privacy-preserving applications on layer-2, and finally to decentralized identity standards that let people authenticate and carry credentials without handing over raw personal data.

Private Transfers on Ethereum

Stealth Addresses (ERC-5564)

Stealth addresses let a sender create a one-time address for a recipient, derived from a shared secret so that only the recipient can spend the funds.

To external observers, the payment looks like it went to an unrelated address, breaking the easy chain-analysis link between sender and recipient. ERC-5564 standardizes how wallets exchange the necessary “ephemeral” keys and metadata so that the mechanism can work across clients and dApps. The recipient keeps their public identity, but actual inflows land on unlinkable addresses they alone can recognize and control.

• What this solves: basic “salary-to-public-address” or “invoice” privacy, recurring payouts, and donations that don’t expose a recipient’s entire portfolio to anyone watching Etherscan.
• What it doesn’t: value privacy (the amount on L1 is still visible) or timing metadata; it’s about address unlinkability, not fully shielded transfers.

“Privacy Pools”: Compliance-Aware Mixers

Classic mixers (e.g., Tornado Cash) achieved plausible deniability by pooling funds, but became regulatory flashpoints.

The Privacy Pools research line proposes a way for users to provide a zero-knowledge proof that their withdrawal comes from an “allowed set” of deposits (e.g., not associated with sanctions or known hacks), without revealing which deposit is theirs.

This creates a separating equilibrium between honest and dishonest users: privacy for the former, accountability for the latter. It’s a conceptual shift from “privacy versus compliance” to “privacy and compliance.”

This is an active research or implementation area rather than an Ethereum core upgrade. Expect iterative deployments and audits rather than a single flip-of-a-switch moment.

Account Abstraction as a Privacy Enabler (ERC-4337 and Beyond)

At first glance, ERC-4337 (“account abstraction”) is about usability: smart-contract wallets with programmable validation, session keys, batched transactions, and sponsored gas. However, these features unlock privacy patterns that are awkward or impossible with vanilla EOAs (Externally Owned Accounts).

For example:

• Session keys that only authorize specific actions for a short time reduce the need to expose a long-lived key across many apps.
• Batching can combine multiple actions into one on-chain operation, revealing less behavioral metadata.
• Paymasters can sponsor your gas or accept alternative tokens, removing the “top up ETH first” fingerprinting vector and making new-user flows more private.
  

Account abstraction is not a magic cloak (contract calls and state changes are still public) but the plumbing makes private-by-default wallet UX practical at scale.

Scaling That Helps Privacy: EIP-4844 and the L2 Effect

Privacy doesn’t exist in a vacuum; it needs cheap proving and data publication. The March 2024 Dencun upgrade (EIP-4844, “proto-danksharding”) added a new transaction type with “blob” data, dramatically reducing the cost of publishing large batches of rollup data to Ethereum.

Lower data costs make zk-proof systems and privacy-preserving L2 protocols cheaper to operate and, therefore, more usable.

This is not a privacy feature per se, but lowering rollup fees and separating blob data from regular transaction gas allows privacy-first L2 designs to flourish.

Privacy-First Layer 2s: Toward End-To-End Confidentiality

The most ambitious direction is privacy-preserving rollups that encrypt user state and application logic, revealing only proofs necessary for verification.

Aztec Network is a leading example: its privacy-first L2 entered the public testnet in May 2025, with a mainnet target by the end of 2025. Aztec emphasizes client-side proof generation so sensitive data stays on the user’s machine, and it’s designed for composability with the broader EVM world.

This opens a path for developers to private DeFi, private voting, and HIPAA-grade data handling, all with Ethereum settlement security. This matters because L1-only approaches can hide recipients (stealth addresses) or pool provenance (Privacy Pools), but not application semantics.

A privacy L2 can keep what you’re doing (e.g., trading, lending, messaging) and which assets and amounts are private, while still giving the L1 the succinct proofs it needs.

Application-Level Building Blocks: Anonymous Signaling And Anti-Collusion

Two public-goods projects from Ethereum’s privacy research community are already widely used:

• Semaphore lets a user prove membership in a group and broadcast a message (e.g., a vote, endorsement, or “I am over 18”) without revealing which member they are. It’s a general-purpose gadget for anonymous authentication, mixers, and private governance designed to prevent double-signaling. Recent iterations (v4) strengthen performance and developer ergonomics.
• MACI (Minimal Anti-Collusion Infrastructure) powers privacy-preserving, bribery-resistant voting. Users submit encrypted votes; the coordinator and ZK circuits ensure tally correctness while preventing voters from proving their choices to a briber. The project shipped major upgrades through 2024 and continues to evolve as a building block for on-chain governance that protects voter privacy.
  

Together, these tools address the social dimensions of privacy: not just “hide a payment,” but “participate without coercion or doxxing.”

Decentralized Identity: Prove Things About Yourself, Not Who You Are

Ethereum’s identity stack focuses on cryptographic control and verifiable claims, not central registries. Three pillars stand out:

Sign-In With Ethereum (SIWE, EIP-4361)

SIWE standardizes how a website asks an Ethereum account to sign a structured message containing session details and a nonce. The site verifies the signature and logs the user in: there are no email, OAuth provider, or password leaks.

It’s widely deployed, and the spec captures security considerations (anti-phishing, replay protection, message length limits). SIWE is not a credential system itself, but it’s the entry point for wallet-based auth that preserves user pseudonymity.

DIDs On Ethereum (did:ethr And did:pkh)

Decentralized Identifiers (DIDs) give you an identifier you control, with a DID Document that lists public keys and service endpoints.

On Ethereum, two notable methods are:

• did:ethr: based on the ERC-1056 registry. Any Ethereum address or contract can be a DID supporting key rotation, delegates, and attributes, resolved by events in the on-chain registry. That design enables long-lived identifiers with robust lifecycle management.
• did:pkh: A generative method that wraps a public-key hash (CAIP-10 format) as a DID. It’s simple and doesn’t require on-chain writes, but because it’s generative, it has limited update capabilities; it’s often used as a bridge to richer methods or in contexts where key rotation isn’t needed.
  

Both methods interoperate with W3C Verifiable Credentials: a university, exchange, or DAO can issue a credential to your DID; later, you can prove possession or reveal only selected fields (e.g., “over-18,” “accredited,” “KYC-screened”) using zero-knowledge techniques, rather than dumping raw PII. (Specific credential formats live outside Ethereum but pair naturally with SIWE and wallets.)

ENS As A Human-Readable Identity

The Ethereum Name Service (ENS) maps names like alice.eth to addresses and metadata. Beyond convenience, ENS is becoming a public key directory and profile layer used by wallets, dApps, and Web2 integrations.

It’s widely adopted (millions of names) and is pursuing L2 scaling to reduce costs. Treat ENS as your public face and pair it with private credentials when you need to prove facts without leaking your full graph.

How These Privacy Layers Fit Together

A realistic private-by-default user journey on Ethereum in 2025 looks like this:

1. Authentication: You sign in to an app with SIWE from a smart-contract wallet (ERC-4337). The app learns you control 0x… (or alice.eth), but nothing else.
2. Proving eligibility: you present a credential bound to your DID that says “this address belongs to a user screened by Provider X,” revealing only that fact, not your legal identity. For on-chain membership or voting, you use Semaphore to prove group membership without revealing which member you are.
3. Payments: incoming funds arrive via stealth addresses so watchers can’t trivially link payers to your primary identity. For withdrawals from a pool, you use Privacy Pools to show your funds are from the honest set.
4. Activity: You trade or lend on a privacy L2 like Aztec, where the details (amounts, counterparties, even which app you used) are encrypted, while Ethereum verifies succinct proofs. EIP-4844 keeps the data posting costs low, so this is affordable.
5. Governance: When voting in a DAO, MACI prevents bribery and protects your ballot secrecy.
   

Each layer handles a different threat model: linkability, provenance, behavioral fingerprinting, and coercion/bribery. No single primitive solves “privacy”; the roadmap is compositional.

State of Ethereum Identity & Privacy Tech (2025)

Generally available today (production-grade or widely adopted):

• SIWE (EIP-4361) is used in many apps and wallets.
• ENS names as a profile/identity layer.
• ERC-4337 infrastructure across major wallet stacks; paymasters or session keys usable in production.
• Semaphore libraries and deployments for anonymous memberships or attestations.
• MACI is powering privacy-preserving votes in hackathons, grants, and DAOs, with a 2024 v2 release.

Standardized and implementable, but adoption is ramping:

• Stealth addresses (ERC-5564) standards exist; wallet support is the gating factor.
• did:ethr and did:pkh are well-documented methods with tooling (Veramo, ethr-did-resolver). The UX work is ongoing.

Emerging / in active development:

• Privacy Pools: Research with early prototypes to thread the needle between privacy and regulatory expectations.
• Privacy-first L2s: Aztec is on public testnet (May 2025) with mainnet planned for late 2025. Expect rapid iteration on tooling and performance.

Practical Considerations And Limitations

• Metadata leaks remain real. Even with stealth addresses, timing and network-level metadata can correlate flows. Use privacy wallets that randomize gas fee strategies and support batching.
• Regulatory posture varies. If you depend on privacy pools or shielded L2 apps, understand local compliance requirements and how selective disclosure proofs fit your obligations. The whole point of Privacy Pools is to help create a compliant path, but it’s not a silver bullet.
• Key management is identity. DIDs don’t help if you can’t rotate or recover keys. Prefer methods (e.g., did:ethr) that support rotation and recovery processes, and pair with ERC-4337 wallets that support social recovery.
• Composability costs. Complete privacy sometimes reduces DeFi composability or requires new designs (e.g., private AMMs). L2 bridges must handle the encrypted state carefully to avoid re-identification at boundaries.

How Developers Can Build Privacy-Preserving Apps on Ethereum (2025 Roadmap)

Ethereum’s privacy stack is no longer just research—it’s moving into production. For developers, this means there are already concrete steps you can take today to make your applications more privacy-preserving and future-proof.

While some technologies (like privacy L2s and Privacy Pools) are still maturing, others—such as SIWE, account abstraction, and Semaphore—are production-ready and can be integrated now.

Below is a set of actionable recommendations for builders who want to align with Ethereum’s privacy roadmap and deliver better protections for their users:

1. Adopt SIWE for auth and stop collecting emails/passwords you don’t need. Follow the spec for nonce handling and replay protection.
2. Ship 4337 wallets or integrate them, enabling session keys and paymasters to minimize UX fingerprints.
3. Use Semaphore for anonymous group membership, rate-limiting sybil attacks without invasive KYC.
4. Plan for stealth address receipts (ERC-5564) so users can accept funds privately once wallet support lands.
5. Experiment on privacy L2s like Aztec’s testnet to learn the new design patterns before mainnet.
6. Model compliance with Privacy Pools-style proofs in your threat and policy frameworks if you process user funds.

Conclusion

Ethereum won’t flip from “transparent by default” to “private by default” at L1. Instead, the roadmap points to selective disclosure:

• Public when it must be: consensus, settlement, and proof verification on Ethereum remain transparent and verifiable.
• Private when it should be: user data, fine-grained application logic, and linkages move behind zk-proofs and encrypted state, primarily on L2s, with L1 seeing only the proofs and commitments it needs.
  

The identity stack (SIWE + DIDs + credentials + ENS) ties this together so people can prove necessary things like ownership, eligibility, and compliance, without exposing everything else.

FAQs

About the Author

Giuseppe Ciccomascolo

Giuseppe Ciccomascolo began his career as an investigative journalist in Italy, where he contributed to both local and national newspapers, focusing on various financial sectors.

Upon relocating to London, he worked as an analyst for Fitch's CapitalStructure and later as a Senior Reporter for Alliance News. In 2017, Giuseppe transitioned to covering cryptocurrency-related news, producing documentaries and articles on Bitcoin and other emerging digital currencies. He also played a pivotal role in establishing the academy for a cryptocurrency exchange website. Crypto remained his primary area of interest throughout his tenure as a writer for ThirdFloor.

[email protected] LinkedIn