Encrypted mempool EIP hardens MEV and censorship resistance

Ethereum researchers are advancing an encrypted mempool eip proposal that would harden the protocol against MEV-related abuse while keeping block production efficient and permissionless.

Overview of the proposed encrypted mempool

The new Ethereum Improvement Proposal (EIP) introduces an enshrined encrypted mempool directly at the protocol level. It allows users to submit encrypted transactions that remain hidden until included in a block, mitigating front running and sandwich attacks while improving censorship resistance. However, the upgrade does not target long-term privacy, as every transaction is eventually decrypted and revealed on-chain.

The design is explicitly encryption-scheme agnostic. It supports arbitrary decryption key providers using threshold encryption, MPC committees, TEEs, delay encryption, or FHE-based systems. Moreover, traditional plaintext transactions remain fully supported, and the chain is guaranteed to keep progressing even if specific key providers fail to supply keys.

The proposal builds on prior initiatives such as the Shutterized Beacon Chain and a live, out-of-protocol encrypted mempool deployed on Gnosis Chain. That said, by moving this functionality in-protocol, the EIP aims to address long-standing MEV issues and to reduce harmful second-order effects such as builder centralization.

Motivation and role in Ethereum’s roadmap

The primary motivation is to defend users against malicious transaction reordering, including front running and sandwiching. By temporarily blinding builders and other market participants, the mechanism also seeks to increase the protocol’s real-time, or so-called “weak”, censorship resistance. Moreover, it aims to lower regulatory risks for block builders by limiting their visibility into user intent during block construction.

The EIP is not designed as a privacy upgrade in the classic sense. Instead, it acts as a MEV mitigation and fairness layer, ensuring that user transactions are not exploited during the critical pre-inclusion window. The design fits naturally with enshrined proposer-builder separation (ePBS), making it a logical extension of Ethereum’s long-term roadmap.

Key provider registry contract and trust graph

On the execution layer, the proposal deploys a key provider registry contract. Any account can register as a key provider and receives a unique ID. Registration requires specifying a contract with both a decryption function and a key validation function, each accepting a key ID and a key message as byte strings. Additionally, key providers may designate other providers as directly trusted, forming a directed trust graph.

Under this model, a key provider A is considered to trust a provider B if and only if there is a directed path from A to B in that graph. The beacon chain mirrors the state of the registry, using a mechanism analogous to how beacon chain deposits are handled today. This ensures that both the execution and consensus layers have a consistent view of registered key providers.

Registration is explicitly technology neutral, minimizing barriers to entry and enabling users to select preferred schemes. However, many advanced encryption systems are inefficient to express in the EVM, which would require dedicated precompiles. Strategy and implementers note that such precompiles are out of scope for this EIP.

Transaction format and ordering rules

The EIP introduces a new encrypted transaction type made of two components: an envelope and an encrypted payload. The envelope specifies an envelope nonce, gas amount, gas price parameters, key provider ID, key ID, and the envelope signature. The encrypted payload contains its own payload nonce, value, calldata, and payload signature, which collectively represent the actual transaction logic.

In a valid block, the protocol enforces strict ordering rules. Any transaction encrypted with a key from provider A may only be preceded by plaintext transactions, encrypted transactions using keys from provider A, or encrypted transactions using keys from providers that A trusts. This ordering binds encrypted inclusion to the trust graph and thereby reflects user preferences indirectly via their chosen providers.

This structure effectively splits every block into two sections: a plaintext segment followed by an encrypted segment. Builders can fully simulate the plaintext section and apply existing block building and MEV strategies. Moreover, they can then append encrypted transactions to the end of the block without significant opportunity cost, preserving competitiveness in PBS auctions.

Envelope execution and decryption workflow

During execution payload processing, once all plaintext transactions are handled, the envelopes of encrypted transactions are executed in a batch. This updates the nonces of the envelope signers and charges gas fees from the corresponding accounts. The fee is designed to cover block space used by the envelope, decrypted payload, and decryption key, as well as computation associated with decryption and key validation.

Subsequently, the protocol attempts to decrypt each payload using the decryption function specified by the relevant key provider. If decryption succeeds, the resulting payload transaction is executed, bounded by both the gas limit on the envelope and the overall block gas limit. However, if decryption or execution fails, or if the decryption key is attested as missing, the protocol simply skips the transaction without reverting the already executed envelope.

The inclusion of the signature inside the encrypted payload is chosen for simplicity. A less private but more efficient approach would be to treat the envelope signer as the ultimate sender of the payload. That said, the current design prioritizes flexibility and clear separation between envelope metadata and underlying transaction logic.

Key revelation process and the role of the PTC

In each slot, once a key provider sees the execution payload published by the builder, it collects all key IDs referenced in the envelopes addressed to it. For every such key ID, the provider must publish either the corresponding decryption key or a key withhold notice. The decryption key message references the relevant beacon block hash, preventing replays in future slots. Providers may publish immediately or delay release until later in the same slot.

Members of the Payload Timeliness Committee (PTC) are required to listen for all such decryption keys. They then validate each key using the validation function defined in the registry, subject to a small, hardcoded gas limit per key. Finally, the PTC attests to the presence or absence of a valid decryption key for each encrypted transaction through an extended payload attestation message with a dedicated bitfield.

This mechanism introduces an additional layer of cryptographic accountability for key providers. Moreover, it creates in-protocol data that can be consumed by off-chain monitoring or custom slashing schemes, enabling the market to reward reliable providers and penalize poor performance.

User trust assumptions and security implications

Users must trust their chosen key providers not to release decryption keys prematurely, which would expose them to classic MEV tactics, or too late, which would cause their transactions to fail while still paying the envelope fee. Providers can build this trust through cryptographic guarantees such as threshold encryption, hardware-based protection, economic penalties like slashing, or governance-driven reputation.

To a lesser extent, users also have to trust all key providers used for encrypted transactions that appear before theirs in a block. These providers can decide to publish or withhold keys after observing keys for subsequent transactions, granting them one bit of influence over the pre-state of later transactions. Maliciously designed “decryption” schemes could abuse this to manipulate specific parts of the decrypted state and perform a more powerful front running sandwiching mitigation bypass.

Importantly, users do not have to trust any key provider used for encrypted transactions included after theirs, as later payloads do not affect the pre-state of their own transaction. Similarly, users who submit plaintext transactions do not need to trust key providers, although they continue to rely on honest behavior from builders.

Mitigating reorgs and decryption key front running

Because decryption keys are published before the underlying encrypted transactions are finalized, a chain reorg can lead to situations where a transaction becomes public even if it ultimately is not included. However, the decryption key messages reference the beacon block hash, enabling the validation function to invalidate keys when the underlying block is not part of the canonical chain. This prevents execution of the payload and limits front running opportunities.

A separate risk involves attackers exploiting shared key IDs. When a user encrypts with a specific key ID, an attacker could observe that transaction in-flight and craft another encrypted transaction using the same key provider and key ID. If the second transaction lands first, a naive provider might reveal the key, unintentionally exposing the original transaction. This is one form of decryption key withholding attack pressure.

Key providers can mitigate such scenarios by “namespacing” key IDs. For example, they may only release keys where the key ID is prefixed with the envelope signer’s address and withhold all others. Since the attacker typically lacks control over the victim’s signing account, they cannot generate a valid transaction with the correctly namespaced key ID, preserving the original user’s confidentiality window.

Incentives, collusion risks and future extensions

The current EIP deliberately avoids defining in-protocol rewards or penalties for key providers. Instead, it leaves room for diverse incentive models to develop off-chain. Key providers may charge users on a per-transaction basis, make bespoke agreements with builders, or even operate as public goods, possibly backed by external funding. Moreover, providers can voluntarily adopt slashing rules for unjustified key withholding to enhance their credibility.

A potential collusion vector involves key providers and builders. To build a new block, builders must know the full post-state of the previous block, including which keys were revealed or withheld. While this information becomes public once PTC attestations are broadcast, a malicious provider could privately inform a favored builder earlier, granting a small head start in block construction.

The impact of such collusion is considered limited. The interval between PTC attestations and slot end is typically long enough for competitive block building, and the critical moment remains near the end of the slot when the full transaction set is known. Additionally, delaying key publication to favor one builder risks missing PTC attestation, negating any advantage. If few encrypted transactions rely on the colluding provider, optimistic strategies that approximate state without full decryption may also mitigate the edge.

Execution payload encryption and backwards compatibility

The authors outline a possible future evolution in which builders use the same key providers to encrypt the entire execution payload. This would allow builders to publish payloads immediately after construction, instead of waiting until around the 50% slot mark. Such a change could improve peer-to-peer efficiency and reduce missed slots due to crashes, especially if combined with zero-knowledge proofs attesting to which keys are used in a block.

In that scenario, attaching a zero-knowledge proof would allow the decryption window to start earlier and last longer, providing more flexibility for key providers. However, this functionality is explicitly left for a future EIP to avoid overcomplicating the current design. The present proposal still introduces backwards-incompatible changes to both the execution layer and consensus layer, as it alters transaction types, block structure, and the rules for payload timeliness committee attestation.

Overall, the encrypted mempool eip proposal represents a substantial step toward protocol-level MEV mitigation, aligning closely with Ethereum’s long-term push toward robust proposer-builder separation epbs and fairer transaction ordering.

Summary

The encrypted mempool aims to embed encrypted transactions envelope execution, key provider coordination, and structured decryption into Ethereum’s core protocol. By doing so, it strengthens user protection against MEV, enhances censorship resistance, and opens the door to future upgrades such as full execution payload encryption, all while preserving optionality for users and builders.