Introducing the Universal Enshrined Encrypted Mempool EIP

Malicious MEV has been a problem on Ethereum for years. Traders get sandwiched. NFT mints get front run. Transactions get censored in real-time. All of these issues come from the same root cause - by default your transaction sits visible in the public mempool before it gets included in a block, giving bots and builders a chance to exploit it. At the same time, we have a complicated and fragmented out-of-protocol transaction supply chain, which doesn’t actually address the core issues fully and it introduces further centralized actors and points of censorship.

Today marks an important step toward solving that problem. Shutter and collaborators have published the first draft of the Universal Enshrined Encrypted Mempool EIP.

The EIP proposes a native encrypted mempool in Ethereum which hides the contents of users’ transactions from absolutely everyone until the chain has fixed their ordering. Once no one can see what users are trying to do, the most harmful MEV disappears.

This EIP is the next step in years of research and real-world deployments of encrypted mempools. Its design fits naturally alongside Ethereum’s ePBS roadmap and it moves Ethereum closer to a future where every user gets protection by default, without needing special wallets or custom RPCs.

Proposed for Inclusion in Heka/Bogotá

This EIP is being put forward for inclusion in Ethereum’s upcoming Heka/Bogotá upgrade. We invite the Ethereum community to review, challenge, improve, and share this proposal.

Quick links:

At a glance, what the EIP introduces

The Universal Enshrined Encrypted Mempool EIP changes how Ethereum handles pending transactions. Instead of exposing them in the public mempool, users can choose to submit their transactions in encrypted form until the chain has included and ordered them.

The EIP introduces three major pieces to make this work.

1. A new encrypted transaction type

Ethereum would support a native transaction format that keeps a user’s calldata and intentions hidden until after block ordering is fixed. Each encrypted transaction has two parts:

Envelope: visible to everyone, pays gas up front, includes gas parameters and the chosen key provider.
Encrypted payload: hidden until the correct decryption key is published.

Builders include envelopes normally, and the chain decrypts and executes the payload safely once the correct key arrives.

This prevents malicious MEV by removing the early visibility attackers rely on.

2. A registry for key providers (technology agnostic)

Ethereum introduces a simple onchain registry where any entity can register as a key provider. Key providers supply the decryption keys that unlock encrypted transactions once ordering is fixed.

The registry is fully technology agnostic. It supports threshold encryption, MPC, TEEs, delay schemes, FHE, and future approaches. The protocol does not choose a single cryptographic system. It creates a neutral framework that invites competition and lets the best techniques evolve over time.

This means the encrypted mempool is not controlled by Shutter or any one group. Any provider, including Nillion, Zama, Aztec, and others, can participate and contribute to the ecosystem.

3. A fast mechanism to include decryption keys in the chain

Encrypted transactions can only execute once their decryption keys are revealed. If those keys are delayed, block execution cannot continue.

To avoid this, the EIP introduces a fast, sub-slot mechanism inspired by ePBS. It allows decryption keys to be collected and recorded on chain before the next block, keeping encrypted transactions practical and block production smooth.

Critically, plaintext transactions remain fully supported. The design avoids breaking existing applications and keeps block production stable while adding strong protections for users who choose encryption.

Why Ethereum needs an encrypted mempool

1. Stops malicious MEV at the root

Since 2020, more than 1.8 billion dollars has been drained from Ethereum users through MEV, much of it from malicious tactics like front running and sandwich attacks. Encrypted mempools hide transaction contents until ordering is fixed, removing the visibility that attackers rely on.

2. Protection moves toward default

Today, users must hunt for protected DEXs, special wallets, or custom RPCs for malicious MEV protection. As a result, protection is fragmented and can be missed, especially by newcomers.

A native encrypted mempool moves Ethereum toward a future where users are protected against front running, sandwich attacks, and real-time censorship by default, without needing special wallets, DEXs, or RPCs.

In the near term, this EIP enables wallets to give their users this protection, without relying on private infrastructure or trusted intermediaries that introduce additional risk.

3. Protects against harmful MEV, while still allowing good MEV

Not all MEV is bad. Encrypted mempools protect against front running and sandwich attacks (which is generally considered to be the major source of bad MEV), while still allowing arbitrage, liquidations, and back-running which is considered good MEV.

4. No more trusting private intermediaries

Private mempools, commonly used via custom RPCs, are a popular way Ethereum users protect themselves against malicious MEV. But they still rely on a small group of operators who can see your transaction and must be trusted not to attack it. That visibility creates a real point of failure.

By contrast, encrypted mempools keep transactions hidden from everyone. No operator, partner, future sequencer, or infrastructure provider can see transactions until it’s confirmed.

That’s the level of credible neutrality required to protect current users and attract serious liquidity, intent systems, and institutional users. By integrating an encrypted mempool, we’re removing trust as a barrier to Ethereum’s adoption.

5. Reduces builder concentration risk

Today most Ethereum blocks are built by a few high performance builders who gain early access to transaction contents. This concentration reduces Ethereum’s censorship resistance guarantees. Encrypted mempools are a countermeasure that enables users to hide transaction content from builders and thereby make censorship much more difficult.

6. Future-proof and technology-agnostic

This EIP supports multiple encryption approaches, including threshold encryption, MPC, TEEs, FHE, and future schemes. New techniques can be added over time without hard forking the chain or changing how users interact with Ethereum. This keeps the ecosystem flexible and encourages more developers to participate.

7. Complements FOCIL and ePBS for stronger censorship resistance

Now that FOCIL and ePBS are on the Ethereum roadmap, encrypted mempools can join them to create a powerful protection system. Together they create a strong, three-part defense against censorship, making sure your transaction is included on time and cannot be filtered or delayed.

The foundation this EIP is built on

This EIP builds on years of research and live deployments.

A live encrypted mempool on Gnosis Chain has processed thousands of encrypted transactions with support from Nethermind and Erigon validators, proving the model works in production.
Shutterized Beacon Chain research demonstrated how encrypted ordering can integrate safely with Ethereum consensus.
Deployment on the Sepholia OP Stack testnet validated encrypted flows in an L2 environment.
An upcoming proof of concept with Primev brings encrypted ordering into Ethereum’s out of protocol transaction supply chain PBS.
A previously published long-term roadmap, created with partners including Gnosis, Nethermind, Chainbound, and MEV Blocker, outlined the path for bringing encrypted mempools to Ethereum.

The design also builds on ideas and research from contributors across the community, including Marc Harvey Hill, Martin Köppelmann, Julian Ma, Anders Elowson, Sebastian Faust, and others working on encrypted ordering, malicious MEV mitigation, and censorship protection.

These efforts prove that encrypted mempools are practical, reliable, and ready for Ethereum integration.

How You Can Contribute

This EIP is being put forward for inclusion in Ethereum’s upcoming Heka/Bogotá upgrade. We invite the Ethereum community to review, challenge, improve, and share this proposal.

FAQs

1. What problem does this EIP solve?

It prevents front running and sandwich attacks by hiding transaction contents until block inclusion, while improving real-time censorship resistance.

2. Does this EIP provide long-term privacy?

No. Transactions are decrypted and published after inclusion. The goal is about ordering, not transactional confidentiality.

3. Where are encrypted transactions placed in a block?

At the end of the block, after all plaintext transactions. This allows normal block simulation and guarantees fees are paid via envelopes before decryption.

4. What does an encrypted transaction consist of?

Envelope (plaintext): gas params, nonce, key provider ID, key ID, envelope signature, fee payment.
Encrypted payload: recipient, calldata, value, payload signature.

Execution order:

plaintext txs → 2) envelopes → 3) decrypted payloads.

5. What metadata leaks before decryption?

Visible: gas parameters, nonce, envelope signer, key provider ID & key ID, approximate tx size. Hidden: calldata, recipient, value, payload signer. Additional network-level metadata might be leaked depending on how the transaction is published (e.g., IP addresses to RPC providers).

6. What is the latency impact?

Plaintext txs: unchanged.
Encrypted txs: execution happens in the same block if keys arrive on time, with <1 slot overhead for key publication and PTC attestation.

7. How does the protocol ensure that encrypted transactions pay for their blockspace?

The envelope pays full fees upfront and executes before decryption. If payload execution fails or keys are missing, the envelope still pays and does not revert.

8. What prevents invalid encrypted transactions from wasting block space?

Envelope-first execution ensures fees are collected regardless of decryption success, protecting both builders and the protocol. Block space can be wasted nevertheless, but the same is true for regular transactions today.

9. What incentives do builders have to include encrypted transactions?

Builders receive:

guaranteed envelope fees,
fees for decryption/validation costs.

In addition, builders and key providers may make off-chain compensation agreements with each other.

Encrypted txs come after plaintext txs, preserving MEV strategies. Protocol rules make inclusion competitive.

10. How is back-running MEV handled? Who captures it?

Back-running opportunities created by encrypted transactions appear only after decryption in the next block. Therefore the next builder captures back-running MEV, not the current one.

11. What ensures that decryption happens on time?

Key providers publish decryption keys or withhold notices.
The Payload Timeliness Committee (PTC) validates and attests them.

If a key is missing or invalid, the encrypted payload is skipped, but the envelope remains valid.

12. What if key providers fail or behave maliciously?

Users take the risk. Skipped payloads still pay via the envelope, and unreliable providers lose market share. Optional slashing or trust-based incentive layers may be built off-chain. Builders or users who did not explicitly or implicitly trust a key provider are not affected.

13. How are key providers registered and trusted?

Any entity can register a key provider with custom:

decryption function
key validation function

A trust graph allows key providers to specify which other providers’ transactions may precede theirs, preventing monopolies while respecting user trust assumptions.

14. How does the protocol prevent Key ID front running?

Providers can use namespaced key IDs (e.g., prefixing key IDs with the sender address). An attacker cannot forge a valid namespaced ID without access to the sender’s key.

15. How do encrypted transactions behave under reorgs or when scheduled?

Keys might be published before finality, so payloads can become public even if the block reorgs. But keys bind to the block hash, preventing replay and preventing front running. Users may also schedule encrypted transactions into future blocks for improved reorg resistance.