Ethereum privacy in 2026: validators and confidential EVMs

In July 2026, the Ethereum Foundation spun out EthSystems as a for-profit organization focused on institutional privacy. A week earlier, Vitalik Buterin published The Extremely Lean Chain, a proposal that redesigns Ethereum consensus around validator anonymity. Two moves, three weeks apart, one direction — privacy is now a first-class Ethereum problem.

These two announcements target different problems for different users. Validator anonymity is a protocol-layer answer for decentralization and staker safety. EthSystems and confidential EVMs like Oasis Sapphire are application-layer answers for institutions that need to protect trading positions, payment flows, and settlement details. This article walks through both.

Ethereum, the second-most popular blockchain, is adopting new privacy standards that meet these expectations at both the consensus and data layers.

One major component focuses on the privacy of the identities of those securing the blockchain, specifically validators, or nodes responsible for validating transactions on the network. 

Vitalik Buterin, the primary co-founder of Ethereum, recently published The Extremely Lean Chain, highlighting how Ethereum can improve decentralization through privacy. To reduce the risk of collusion or third-party influence in validating transactions, the identities of validators are untraceable and distinguishable by rotating their identifiers daily and using cryptographic schemes to prove account balances without linking them to identities.

If we want to make the Lean Ethereum consensus chain aggressively more "lean", and add strong validator privacy (ZK-unlink deposit from staking activity from withdrawal, and re-anonymize stakers every day), here is a path:https://t.co/Gdee7tE53R

— vitalik.eth (@VitalikButerin) July 6, 2026

In addition to the privacy of validators, those that secure the chain, the Ethereum ecosystem is seeing a push in privacy tools. 

In July 2026, the Ethereum Foundation Institutional Privacy Task Force founded EthSystems, a for-profit organization focused on building privacy infrastructure for institutions.

Newly launched Ethereum Virtual Machine (EVM)-compatible chains are providing complete privacy to blockchain users. Unlike public blockchains, these blockchains enable end-to-end encryption of the blockchain state, appealing to institutions that want to protect user privacy and maintain a competitive advantage by keeping transaction data completely confidential. On such new chains, such as Oasis Sapphire, developers can deploy private smart contracts that keep smart contract data confidential.

Privacy on the blockchain is not a paradox; it is essential to its core values and adoption. Validator privacy supports decentralization, while blockchain state privacy builds trust among institutions and their millions of users.

Why privacy matters (to institutions)

Institutions such as banks, governments, and funds expect blockchains to meet privacy standards, despite their public nature, to protect users’ identities and preserve the competitive advantages they are accustomed to in traditional finance.

Adoption of crypto amongst institutions

The adoption of cryptocurrency and blockchain amongst institutions has grown significantly since the passage of the GENIUS Act in July 2025, which provided the first comprehensive regulatory framework for stablecoins in the United States. Institutions are using crypto to hedge against inflation and to provide more investment options and faster settlement for their customers.

As of January 2026, more than 2,000 U.S. advisory firms have allocations in crypto ETFs. 18% of financial institutions and corporations globally use stablecoins, including Visa and Western Union. Nearly 770 million USD has flowed into Bitcoin and Ethereum ETFs in the past three months, as of July 2026.

Institutional investment in crypto is expected to grow, increasing demand for blockchain privacy.

Privacy requirements for institutions

Institutions are not seeking complete privacy of transaction data but are primarily concerned with preventing the disclosure of their trading data to competitors and with preventing data leaks that could compromise the blockchain’s security.

Institutions are less interested in private cryptocurrencies in which user identities and transaction data are completely untraceable, because they must still comply with anti-money-laundering and know-your-customer regulations.

Instead, with a public blockchain, they are most concerned with the risk of revealing their daily deposit amounts, payment flows, positions, and the customers involved in large transactions, allowing competitors to analyze this data.

Several institutional privacy use cases include:

• Private bonds: the issuance of bonds and bond trading where volumes, prices, and positions must remain confidential to prevent other firms from front-running each other and exposing strategies.
• Private payments: payment transfers in which transaction details that could reveal business relationships, purchasing behavior, and financial health are kept confidential.
• Private commodities: trading details should remain confidential to prevent disclosure of position sizes, trading strategies, and physical delivery arrangements.

Any blockchain that provides the infrastructure to support use cases must also remain completely secure against attacks that could lead to the loss of user funds. One key area is ensuring the privacy of stakeholders’ identities on the blockchain to prevent any collusion, third-party influence, or targeted hacks.

Specifically, the privacy of validators, the nodes that are responsible for validating transactions and securing the blockchain, is crucial to ensuring valid transactions are approved.

How to make the blockchain private

Ethereum is adopting new privacy standards that address these use cases at the consensus level through validator privacy and at the infrastructure level through new tools and smart contracts.

Validator privacy

Vitalik Buterin’s proposal, The Extremely Lean Chain, outlines a design in which validators no longer have a permanent, trackable identity. Instead, they will have a daily rotating identity, and cryptographic schemes can be used to verify their eligibility as validators without revealing their previous identities.

At present, each validator is identified by an index and a permanent public key, which can be looked up to see their Ethereum staking amount and staking income in an explorer similar to this one:

In Vitalik’s proposal, to remain active as a validator, the validator would need to declare and prove an effective or approximate balance daily, based on its previous balance, using a ZK-STARK, a type of zero-knowledge cryptographic proof designed to be scalable and not require an initial setup phase. In this same process, each validator would rotate or change their index and public key from a fixed seed. For outside parties, the ZK-STARK shows only the validator’s balance change since the last proof (probably the day before) and whether it has been slashed, making it unlikely that the validator’s identity can be traced from indexes and keys.

Any staking withdrawals from the validator require an additional ZK-STARK that is not tied to the daily balance change proof ZK-STARK. Because the withdrawal ZK-STARK must include an exact balance to verify the withdrawal, two cryptographic proofs guarantee that a validator’s identity cannot be traced through the effective and exact balances.

Such a design provides stronger guarantees that validators and their staking and withdrawal amounts remain untraceable, thereby enabling broader onboarding of institutional validators seeking to protect their competitive advantage.

New privacy infrastructure for institutions on Ethereum via EthSystems

Developers and institutions can also expect new privacy infrastructure for institutions with the launch of EthSystems.

In July 2026, the Ethereum Foundation’s Institutional Privacy Task Force spun out into EthSystems, a for-profit organization dedicated to building privacy infrastructure for institutions.

Yesterday was my final day at the Ethereum Foundation.

Today, we’re launching @eth_systems .

I started my career at @GoldmanSachs , working inside the financial system. Years later, I found myself at the @ethereumfndn , working with institutions exploring how that system could… https://t.co/oSQ6p2Ftx0

— Mo (@motypes) July 14, 2026

Despite a recent launch, EthSystems has already developed several proofs-of-concept (PoC) addressing the following institutional privacy use cases mentioned earlier:

• Private bonds: The PoC tested three ways to hide information while still proving that the trade is valid:

1. Representing each bond as a sealed note that only a holder can open using Noir
2. Issuing bonds on Aztec, a separate privacy L2
3. Using an FHE-based encryption approach using Zama

• Private payments: The PoC hides the amount and parties involved in stablecoin transfers using:

1. a shielded pool using Noir, where verified participants can send funds without the amount or recipient becoming public
2. a network that keeps transaction data off-chain

• Private trade settlement: The PoC uses a Trusted Execution Environment (TEE), an enclave isolated from the node’s hardware, in which private information, such as counterparty identities and asset and amount, is handled.

Confidential smart contracts

Several new EVM chains, such as Oasis Sapphire, take confidentiality a step further by providing end-to-end encryption of transaction data natively on-chain, without requiring developers to create any new tools. Developers can directly deploy confidential smart contracts that keep that data private.

EVM chains that offer confidential smart contracts separate execution from consensus. On Oasis Sapphire, the consensus layer still handles block production and finality. Each compute node responsible for executing smart contracts and processing transactions runs a Trusted Execution Environment (TEE), an enclave isolated from the node hardware, where private information is handled. The private information that a TEE handles separately from the compute node is the transaction calldata, a temporary data input when making a transaction, and contract state, the state variables a contract holds between calls, such as balances.

From a developer’s perspective, deploying to Oasis Sapphire is like deploying to another EVM, except confidentiality is handled under the hood. 

1. Write and deploy a Solidity contract onto Oasis Sapphire.
2. When a user calls the contract, their wallet encrypts the calldata before it leaves their device.
3. The still-encrypted transaction is submitted to the network and routed to the TEE.
4. Inside the TEE, the runtime decrypts the calldata, executes the contract logic against the contract state, and re-encrypts the result.
5. The encrypted output is passed to the consensus layer, which orders and finalizes it without ever decrypting it.

The value of using Oasis Sapphire, as opposed to a new infrastructure add-on on Ethereum developed by EthSystems, for example, is that a developer would not need to run their own TEE hardware. 

For example, unlike on Ethereum, private trade settlement on Oasis Sapphire requires only smart contract updates.

While on Oasis Sapphire, transaction calldata and contract state are private; events are public by default. Events are one-off logs that a smart contract emits during a transaction for external parties to read. For a contract logging something like a trade settlement, that means the asset, amount, and price could leak.

Oasis Sapphire encryption precompiles allow a smart contract to encrypt event data before it’s emitted. Here is what an example of a smart contract optimized for private settlement looks like:

pragma solidity ^0.8.0;

import { Sapphire } from "@oasisprotocol/sapphire-contracts/contracts/Sapphire.sol";

contract PrivateTradeSettlement {
    event SettlementRecorded(address indexed counterparty, bytes32 nonce, bytes encryptedDetails);

    function recordSettlement(bytes32 key, bytes calldata tradeDetails) external {
        bytes32 nonce = bytes32(Sapphire.randomBytes(32, bytes("settlement-nonce")));
        bytes memory encryptedDetails = Sapphire.encrypt(key, nonce, tradeDetails, bytes(""));
        emit SettlementRecorded(msg.sender, nonce, encryptedDetails);
    }
}

In the contract, the counterparty address stays a public, indexed topic, so external systems can still filter or count settlements per party. 

event SettlementRecorded(address indexed counterparty, bytes32 nonce, bytes encryptedDetails);

The tradeDetails payload, including the asset, amount, and price, is encrypted before it is emitted.

bytes memory encryptedDetails = Sapphire.encrypt(key, nonce, tradeDetails, bytes(""));

This enables institutions to publish a verifiable, timestamped record of a settlement without revealing the specific details of the settlement.

What changes for RPC infrastructure

Both privacy tracks have consequences for the layer developers actually touch — the RPC endpoint.

Validator privacy: execution RPC is unaffected, consensus RPC and staking tooling aren’t. Standard methods like eth_call, eth_sendRawTransaction, and eth_getLogs don’t care who the validator is, so wallets and dApps see nothing different. The change lands on the Beacon Chain API. The /eth/v1/beacon/states/{state_id}/validators/{validator_id} endpoint currently returns a validator by index or public key. Under Lean Chain, those identifiers rotate daily. Staking dashboards like beaconcha.in and rated.network, MEV pipelines that bind proposer duties to a pubkey, and slasher software all need to migrate from stable keys to ZK-STARK identity commitments. For solo stakers, client teams (Lighthouse, Prysm, Teku) will need to hide the daily key derivation from the operator. For a deeper look at the mechanics behind these endpoints, see Understanding Ethereum proof of stake.

Confidential EVMs: standard JSON-RPC survives, but the client and endpoint both need to know. Sapphire keeps the Ethereum JSON-RPC surface, but calldata has to be encrypted before it reaches the endpoint. That adds three things to the stack:

• A new RPC method: core.CallDataPublicKey returns the runtime’s ephemeral public key. The client uses it to derive a session key and encrypt calldata before submitting the transaction. See the Sapphire developer docs for the full flow.
• A wrapped client library. Raw ethers.js or web3.js won’t do envelope encryption. Developers use @oasisprotocol/sapphire-paratime, which wraps the provider and handles the key fetch, encryption, and decryption transparently.
• Authenticated reads via SIWE. Confidential contracts also require a Sign-in-with-Ethereum token on read calls — even for state queries. Unauthenticated calls return no data. See view-call authentication for the pattern.

Limited introspection is the other consequence. debug_traceTransaction, eth_getStorageAt, and archive-style queries either fail or return encrypted blobs — the TEE gates them by design. Indexers reading eth_getLogs see cleartext for public events but ciphertext for anything the contract encrypted via the Sapphire precompile.

For an RPC provider, the harder part is upstream: Sapphire compute nodes have to run inside a Trusted Execution Environment (Intel SGX today). That means SGX-capable hardware, remote attestation, and a runtime upgrade path that doesn’t break the enclave — none of which is a normal ops workflow. Chainstack runs both the Ethereum endpoints that will keep serving execution-layer traffic through the validator-privacy transition, and the Oasis Sapphire endpoints that run the SGX hardware — so developers ship confidential contracts without operating enclaves themselves.

Conclusion

Ethereum’s answer to privacy in 2026 is not one design. It’s two, aimed at different problems.

At the protocol layer, validator anonymity solves a decentralization problem. Rotating identifiers and ZK-STARK identity commitments make it harder to trace, target, or coerce individual stakers — which matters for solo stakers and for institutional validators who can’t publicly show every deposit and withdrawal to competitors.

At the application layer, confidential EVMs solve an adoption problem. EthSystems’ PoCs on Aztec and Noir, and confidential-by-default chains like Oasis Sapphire, let institutions run private trading, settlement, and payment flows on smart-contract infrastructure without leaking positions or counterparties. This is the layer that determines whether a bank can actually settle a bond onchain. For a broader look at how enterprises are choosing between these approaches, see private blockchains vs ZK rollups.

Neither approach makes the other redundant. Validator privacy protects the network’s operators. Confidential EVMs protect the network’s users. Together they answer the question institutions have been asking since 2020: can we use public blockchain infrastructure without giving away the data that defines our business?

The infrastructure that runs both — Ethereum RPC endpoints that outlast the validator-privacy transition, and Sapphire endpoints that operate the TEE hardware developers don’t want to run themselves — is what Chainstack provides.

FAQ

Resources

• The Extremely Lean Chain
• EthSystems, including institutional privacy use cases and POCs
• Oasis Sapphire Documentation
• Aztec Network, including Noir