Ethereum’s public mempool has always been a double-edged sword.
On one hand, it reflects the openness of the network and allows for auditability. On the other, that same openness creates an “exploit window,” where pending transactions can be seen and acted upon before they’re finalized. This fuels harmful forms of MEV like front-running and sandwich attacks.
Encrypted mempools aim to close the exploit window. Using threshold encryption and distributed key generation, they keep transactions hidden until they’re securely included in a block, then reveal them for full verifiability.
Implementing an encrypted mempool requires big changes to Ethereum at the proposal level, and like any big change, the idea has both supporters and skeptics.
In this article, we’ll explore both sides of that debate. We’ll examine why many see encrypted mempools as a necessary step forward and why others remain cautious or resistant. We’ll highlight new research that has started to shift opinions, and address common misconceptions that, once clarified, have led some skeptics to reconsider their stance.
The Two Sides of the Debate
Who Supports Encrypted Mempools - and Why
Supporters believe encryption strengthens fairness, protects users, and levels the playing field across the ecosystem.
End users & most wallets: They face the consequences of malicious MEV: poorer trades, failed swaps, and unpredictable slippage. By concealing transactions in the public mempools, encrypted mempools reduce these risks while preserving post-reveal price competition.
DEXs & liquidity venues (including OTC and derivatives): If the taker's intent is hidden, there are fewer predatory fills and less adverse selection for liquidity providers. Price discovery occurs after the reveal, rather than against the user in the mempool.
Intent / order-flow-auction managers: Less leakage means cleaner auctions. More value flows back to users through rebates and better execution instead of leaking racing intent. Benign backruns continue to compete after the reveal.
Regulation-conscious validators, sequencers, relays, builders, supply chain intermediaries: When transaction contents are encrypted, these intermediaries have less discretionary power in ordering. This positions you favourably when it comes to regulating supply chain intermediaries, e.g. in the context of market abuse or censorship.
Privacy‑minded researchers and core contributors focused on censorship resistance: Encryption provides real-time protection against selective suppression and targeted reordering. For those focused on censorship resistance, it is a strong complementary measure alongside other safety protocols.
Long-tail validators / solo operators: Encryption reduces the profit available from passive mempool monitoring. Reduced value from passive mempool monitoring levels the playing field. Protocol-style assurances like encrypted mempools decrease reliance on unclear private routes where you have to trust the platform.
L2 sequencers: By hiding L1 intent until inclusion, encrypted mempools minimize cross-domain signaling and predation. This improves fairness across rollups and bridges.
Who Remains Skeptical - and Why
Skeptics worry about lost advantages, reduced visibility, and the operational challenges of running an encrypted system.
Public-mempool searchers: Their advantage lies in early visibility. Encryption removes the signals for sandwich attacking and front running, reducing searchers’ margins. (Benign MEV strategies like arbitrage and liquidations still remain viable after the reveal.)
Independent builders reliant on leaked order flow: Builders who capture public flow lose that advantage. Encrypt-then-commit shifts competition toward inclusion guarantees rather than flow capture.
Mempool analytics / observability providers: With less public data available, these providers worry about reduced monitoring and execution quality if designs are careless.
Orderflow-privileged operators: Encryption makes discretionary reordering and top-of-block strategies harder. This is the main point, but it alters their economics.
Operational pragmatists (node, RPC, client teams): These teams are concerned about complexities such as spam handling for ciphertext, key management, decryption liveness, and fee estimation under privacy. They expect gradual rollouts and clear objectives.
Common Misconceptions Causing Skeptism
Much of the skepticism around encrypted mempools comes from early misconceptions on what encrypted mempools do. Furthermore, over the past couple years, research and pilot deployments have identified cryptographic primitives for addressing many concerns, showing that many previous limitations of encrypted mempools have been solved.
“Encryption hides Ethereum forever.”
A common worry is that encrypted mempools would undermine transparency. In reality, privacy is temporary. Transactions are revealed as soon as they’re included in a block, which closes the exploit window without concealing Ethereum’s state.
“All MEV disappears, and markets break.”
Another misconception is that encryption removes all forms of MEV. That’s not true. Benign MEV, like arbitrage, liquidations, and non-predatory backruns remains possible after reveal. Market quality can improve even as harmful MEV decreases.
“You can’t separate good MEV from bad MEV.”
Early critics argued that encrypted mempools were too blunt an instrument. New designs like through-encryption ordering (using TEEs or FHE) or post-inclusion ordering show it’s possible to preserve beneficial MEV while filtering out the predatory types.
“Threshold encrypted mempools can’t scale, will always be too rigid and too slow.”
This has been a major sticking point, but it’s also where new research is making the most progress. Advanced cryptographic tools are starting to break through limitations:
- Secret sharing with snitching and traceable threshold encryption deter collusion by making it detectable and punishable.
- Silent setup reduces the complexity of establishing and rotating Keyper sets, making them flexible instead of fixed.
- Batched threshold encryption cuts latency by allowing all transactions in a block to be decrypted with a single compact proof, instead of one per transaction.
These primitives aren’t yet production-ready, but they point to a practical path forward.
Learn more about other encrypted mempool misconceptions and recent research helping us to overcome limitations of encrypted mempools:
- Debunking Myths and Misconceptions Around Encrypted Mempools
- On the Limits of Encrypted Mempools – A Response to a16z Crypto’s Analysts
- Breaking Encrypted Mempool Limitations with Advanced Cryptography
Understanding Where This Fits in the Ethereum Roadmap
To fully understand the potential of encrypted mempools - and to assess whether they support or detract from Ethereum’s future - it’s helpful to see how they could fit in Ethereum’s roadmap.
Holy Trinity for Censorship Resistance
Encrypted mempools are not an isolated fix, but one part of what some are calling the Holy Trinity for Censorship Resistance: ePBS, FOCIL, and encrypted mempools working together to make Ethereum more fair and credibly neutral.
- ePBS (enshrined Proposer–Builder Separation): Now advancing in the Glamsterdam fork, this brings the builder–proposer split into the protocol itself. It reduces reliance on trusted intermediaries and clarifies who does what.
- FOCIL (Fork-Choice enforced Inclusion Lists): Now under consideration in the Glamsterdam fork, FOCIL enforces inclusion guarantees to counter censorship.
- Encrypted mempools: while ePBS and FOCIL tackle long-term neutrality and censorship, encrypted mempools fill the missing piece: they remove the real-time leak that fuels harmful MEV.
Proposing a Phased Approach to Implementation
Because integrating an encrypted mempool is such a significant change, the plan is to introduce it gradually through phased integration.
Earlier this year, Shutter and collaborators published The Road Towards a Distributed Encrypted Mempool on Ethereum, a whitepaper outlining this path:
- begin with opt-in endpoints outside the protocol to prove liveness and usability,
- Then add proposer commitments as adoption grows,
- Finally, if the interfaces stabilize and the advantages are evident, we can then consider adding in-protocol hooks.
The principle is simple: move gradually, and let data guide the way - helping to overcome concern in the debate about introducing too much complexity too quickly.
Open Questions
Even as progress is made, several key questions remain unresolved. These aren’t blockers, but they will shape how and when encrypted mempools can be adopted at scale.
- Metadata leakage vs. overhead: What padding/batching gives strong protection with acceptable latency and cost?
- Committee operations: Rotation, slashing, recovery, and incident response. How do we balance liveness and simplicity?
- Phasing and potential enshrinement: Which interfaces should solidify off-chain first, and when (if ever) should parts move in-protocol?
Join the Conversation
Encrypted mempools spark strong opinions: some see them as the missing piece in Ethereum’s neutrality roadmap, others as added complexity. What matters is that the discussion continues - each new conversation helps surface issues, refine the design, and identify a better model for Ethereum.
What thoughts and questions do you have? Share your opinion on X/Twitter or drop a message to the team to discuss further.
