Where Privacy Lives: Reading EIP-8250 Through the Stack

A new Ethereum proposal landed recently that, together with the architecture it depends on, describes a path to L1-native privacy primitives. But several companies have spent years building privacy infrastructure before this path was articulated. What does this EIP mean for the work already done?

The proposal

EIP-8250 was filed on May 5 by Thomas Thiery, Toni Wahrstätter, lightclient, and Vitalik Buterin to change how Ethereum tracks transaction ordering for one specific class of transactions, so that many independent users can share a single sender address without bottlenecking each other.

In plain terms, that matters because shielded-pool privacy protocols on Ethereum L1 like Tornado Cash, Privacy Pools, and Railgun work by routing many users' withdrawal transactions through a single shared address. Today that's typically a relayer, since the fresh withdrawer address holds no gas. Under frame transactions, with relayers abolished, it would be the pool contract itself. Either way, under Ethereum's current single-nonce-per-sender design, one user's pending transaction can hold up everyone else's. The proposal fixes that, with the natural derivation being to use the user's privacy nullifier as the per-transaction key.

So what does that unlock?

EIP-8250 builds on EIP-8141, filed in January, which introduces a new transaction type called a frame transaction. Frame transactions are an account-abstraction primitive that lets an account define its own validity rules and pay gas in flexible ways, without the off-chain relayers that today's L1 shielded-pool protocols rely on to bridge the gap between a fresh withdrawer address and the gas it doesn't yet hold. Buterin has described frame transactions as making "privacy protocols much more first-class." They're targeted for the Hegota hard fork, expected sometime this year.

EIP-8250 is the second-order proposal once frame transactions exist that fixes the bottleneck so shielded-pool protocols can actually use them at throughput.

One other important point to mention comes from an analysis of frame transactions that finds that under the default parameters being drafted, privacy transactions would actually be excluded from every default path to censorship resistance.

Wahrstätter's proposed remedy is what he calls a "canonical privacy pool," a contract recognized at the protocol level that gets exemptions from the otherwise-strict mempool rules, with storage organized so that ordinary partial-node operators can track it cheaply. The changes give privacy transactions a viable path to propagate through the public mempool natively, get included by validators, and have that inclusion be enforceable.

Buterin tied it all together by describing keyed nonces as "a first foray into a new state scaling strategy" that create specialized storage on Ethereum optimized for specific use cases. Privacy transactions running at sustained scale would generate around 500 billion records that can never be deleted. Putting that into ordinary state would push storage into the tens of terabytes. A dedicated store handles that horizon while keeping general state manageable for everyday node operators.

Read end-to-end, the architecture is for frame transactions to abolish relayers, and keyed nonces unblock the shared-sender bottleneck. The canonical privacy pool exception makes the design workable inside the public mempool and specialized storage handles long-term scaling.

For the companies that have been building privacy infrastructure, the question is what a successful version of this path would mean for the work they've already done. There are dedicated rollups built around their own privacy primitives. There are application-layer protocols that sit on L1 and use shielded pools. There are token standards that encrypt balances at the asset layer rather than the chain layer. There are FHE coprocessors and MPC networks and TEE-based confidential compute. And there are specialized institutional chains that handle privacy through operational permissioning rather than cryptography.

If it ships in close to the proposed form, Ethereum L1 itself becomes a place where shielded transfers can happen natively, with no relayer infrastructure, public-mempool propagation, and inclusion-list enforcement. That doesn't replace any of the existing approaches, but it does change the surface they're operating on.

How it lands across the stack

Programmable-privacy rollups and alt-VMs: Aztec, Miden, Prividium, Aleo

These projects took a different bet from app-layer protocols that meaningful privacy on a public chain requires its own execution environment, with privacy designed in at the language and VM level.

Aztec is the longest-running of the group. It's a zk-rollup with its own programming language, Noir, designed for applications where some state and computation are private and some are public. Contracts can hold both kinds of state and call both kinds of functions in a single transaction. Proofs are generated on the user's device rather than on the network.

Miden, spun out of Polygon, is a STARK-based zkVM organized around an account model where most computation happens locally on the user's device and only the resulting proofs are submitted to the network. Accounts carry their own state; interactions between them happen through notes that can be public or private.

Prividium is Matter Labs' enterprise privacy environment, built on the ZKsync stack. Institutions deploy their own private execution environments, effectively their own ZKsync-derived chains, that inherit Ethereum settlement, with programmable privacy policies controlled by the deploying institution.

Aleo is a privacy-by-default L1, not on Ethereum, built around its own snarkVM execution layer. Programs are written for snarkVM and run privately at the chain level by default; disclosing data is the opt-in rather than the default. Compliance hooks are programmable, with a predicate-graph approach to defining disclosure rules per asset or flow.

None of this work gets made redundant by L1-native primitives. They're solving different problems on different surfaces.

Privacy chains in other ecosystems: Penumbra, Namada

These projects are mostly orthogonal to the Ethereum question. Penumbra is a privacy-by-default Cosmos chain. All transactions are private, including staking and governance that operates as a shielded DEX in the Cosmos ecosystem. Namada (from Anoma) is a multi-asset shielded-transfer L1 that launched mainnet in June 2025 and offers cross-chain privacy bridges to Bitcoin, Ethereum, and Solana ecosystems.

If Ethereum's L1-native path lands, does the practitioner conversation around privacy consolidate around it, or does the heterogeneous-ecosystem reality remain durable?

Confidential tokens at the asset layer: ERC-7984, Solana Token Extensions, AvaCloud eERC20

A different cut entirely: privacy not at the chain or app level, but at the asset level. A token standard where balances and transfer amounts are encrypted while the rest of the chain remains public.

ERC-7984 is a draft Ethereum confidential-token standard developed by OpenZeppelin and Zama, designed to be compatible with FHE, MPC, or TEE backends. Solana Token Extensions provide encrypted balances with auditor-key disclosure for designated parties. AvaCloud's eERC20 is Avalanche's ZK-based confidential ERC-20.

Asset-layer privacy comes in different flavors, like explicit auditor-key disclosure for Solana Token Extensions and AvaCloud's eERC20, or threshold-key models for ERC-7984 implementations, and which approach fits a given use case is a question issuers answer for themselves.

FHE-based confidential computing on EVM: Zama, Fhenix, Inco, Mind Network

Zama and the projects building on its FHEVM stack take a different cryptographic approach: encrypt the data, then compute on it directly without ever decrypting. The privacy guarantee comes from the encryption itself rather than from anonymity sets.

Fhenix builds an FHE rollup on Zama's stack. Inco Network is a modular confidential computing layer on FHEVM. Mind Network ships a hybrid ZK/FHE/TEE architecture.

The L1-native privacy primitives don't displace that work. What they do is sharpen the line between cryptographic-transfer privacy and cryptographic-computation privacy. For simple private payments, builders would have a new option that competes on cost and simplicity. For anything that requires actually computing on encrypted data, like encrypted balances and swaps, confidential lending, sealed-bid order books, or federated AI inference, the L1 path doesn't enter the picture, and those use cases sit more clearly in the territory that requires FHE.

MPC and TEE confidential compute: Nillion, Arcium, Partisia, Soda Labs, Oasis, Phala

MPC and TEE-based confidential computing serve use cases that don't reduce to shielded transfers, like encrypted information markets, sealed-bid auctions, federated learning, attested AI inference.

Nillion combines MPC with homomorphic encryption and has enterprise partnerships including Deutsche Telekom, Vodafone, and Alibaba Cloud. Arcium is the MPC layer on Solana, with consumer apps Bench and Crafts going live this week and Manticore (encrypted AI compute) in development. Partisia is an MPC-based enterprise blockchain. Soda Labs ships Soda Bubble, a garbled-circuit MPC layer providing confidential token transfers and EVM-compatible private computation, with deployments on COTI Network and a European Central Bank Pioneer CBDC pilot. Oasis runs TEE-based confidential ParaTimes. Phala provides TEE off-chain compute infrastructure.

For these projects, the L1-native privacy path on Ethereum is largely unrelated. These aren't transfer use cases, and shielded ether transfers don't substitute for them. The one place there's any overlap is at the confidential-token edge of these stacks, as Soda Bubble's confidential token transfer capability, for instance, sits at roughly the same simple-payment layer that L1-native shielded transfers would address, but the broader surface these projects operate on, encrypted multi-party computation and attested compute, sits well outside what the L1 path can do.

Specialized institutional chains: Tempo Zones, Canton, Circle Arc

Tempo's Zones, Canton, and the issuer-owned chains being launched by Circle (Arc) and Tether (Plasma, Stable) are designed around permissioned execution environments overseen by named operators, with privacy provided through operational rather than cryptographic means.

They're solving for a regulatory and operator-trust model, not for the public-mempool censorship-resistance model that motivates the L1-native path. The horizon question is whether the institutional case for "public chains can't do private settlement at scale" weakens as L1-native primitives mature, and if so, whether the issuer-chain thesis has to defend itself on different terms (predictable fees, partner ecosystem, compliance posture, settlement speed) rather than on architectural necessity.

What to watch

The canonical-privacy-pool exception still has to clear a security review, and the trust assumptions in "recognized by code hash" are worth scrutiny.

The validation-index approach to inclusion-list enforcement is the alternative that makes the higher gas budgets affordable, but it's still in proposal stage and adds protocol complexity. And even if all the protocol-level pieces ship, the architecture only delivers censorship resistance for privacy transactions if enough validators choose to run the partial-state node software that lets them track the canonical pool.