As Ethereum evolves, its transaction supply chain faces two persistent challenges: front running and real-time censorship. Encrypted mempools, where transaction details are temporarily hidden, have emerged as a promising solution to address these issues.
Like many emerging technologies, myths and misconceptions have quickly taken root. These misunderstandings risk slowing adoption and detracting from the actual value that encrypted mempools can bring to Ethereum and its users.
Shutter has been developing and implementing encrypted mempool technology utilizing threshold encryption. This technology has already been tested and is currently live on the Gnosis Chain. Now, we are moving towards integration with Ethereum Layer 1. In this post, we will address the most common myths, explain their origins, and clarify the facts.
Myth #1: Encrypted mempools eliminate all MEV
The misconception
Some people believe that encrypted mempools are a "magic bullet" that eliminates all Maximal Extractable Value (MEV). This misconception often arises from confusing malicious MEV, such as front running, with benign MEV, like arbitrage, or from oversimplifying the complexities of transaction ordering.
The reality
Encrypted mempools aim to prevent malicious MEV while preserving beneficial MEV. They hide the transaction details until the transaction order is confirmed, which mitigates front running and sandwich attacks.
However, they do not-and should not-eliminate all forms of MEV. Certain types of MEV are essential for maintaining healthy markets. For instance, arbitrage between (decentralized) exchanges helps keep prices aligned, and liquidation events in lending protocols ensure solvency. Completely removing these mechanisms could negatively impact market efficiency and stability.
Encrypted mempools should be viewed as precise tools; they specifically address the types of MEV that emerge from information asymmetry in the mempool and negatively impact users, rather than those that stem from open-market price variations.
Myth #2: Encrypted mempools provide permanent transaction privacy
The misconception
Because "encryption" is in the name, many people mistakenly believe that encrypted mempools make transaction data completely invisible, similar to privacy-focused blockchains or zero-knowledge shielded transactions.
The reality
Encrypted mempools offer temporary privacy to transactions. The aim is not to keep transaction details secret forever, but to obscure them long enough to avoid targeted manipulation before confirmation.
Once the order is finalized, the transaction is decrypted and becomes visible on-chain, just like any other Ethereum transaction. This means that encrypted mempools serve as a complement to long-term privacy solutions rather than a replacement. They protect your transaction during its most vulnerable phase—when it is in the mempool, exposed to anyone operating a node or monitoring pending transactions.
By closing the visibility gap in the short term, encrypted mempools help prevent targeted censorship and predatory trading while maintaining Ethereum's transparent and auditable design.
Myth #3: Ethereum isn't prioritizing it, so it must not be important
The misconception
Since encrypted mempools are not currently part of Ethereum's main protocol roadmap, some people interpret this as a sign that they are not worth pursuing—or worse, that they have been dismissed.
The reality
Ethereum's development roadmap is busy, with current priorities centered on scaling upgrades, proposer-builder separation (PBS), and related enhancements. However, this doesn't imply that encrypted mempools are unimportant; instead, they are being developed alongside these initiatives, similar to how early Layer 2 solutions evolved before receiving recognition at the protocol level.
Shutter has already implemented encrypted mempool technology on the Gnosis Chain, and prototypes for Ethereum Layer 1 are currently in development. These experiments aim to refine the technology, build trust in its reliability, and demonstrate its compatibility with the broader Ethereum ecosystem.
Over time, these building blocks can be combined with other upgrades—such as FOCIL and ePBS—to create a transaction pipeline that is resistant to censorship and frontrunning. The key to this approach is incremental adoption: first, we validate the concept outside of the protocol. Once the benefits are clear and the design has been thoroughly tested, we can integrate it into the protocol.
Myth #4: Encryption will slow Ethereum down or add excessive complexity
The misconception
Encrypting and decrypting transactions may introduce latency or compromise Ethereum's transaction flow.
The reality
Threshold encryption, the method used by Shutter, is focused on efficiency. In most implementations, the extra delay is minimal, typically adding just one additional slot. The encrypted transaction is published in one slot, decrypted in the next, and then executed, all without interrupting the production of blocks.
This trade-off—slightly longer confirmation time in exchange for protection from front running—is one that most users and applications would gladly accept. For high-value or latency-sensitive trades, knowing your transaction cannot be exploited is worth the extra seconds.
On the complexity side, users do not need to interact directly with encryption. Wallets and dApps manage the encryption and decryption steps automatically, providing a seamless experience.
Myth #5: Encrypted mempools are the same as private mempools
The misconception
It’s common for people to confuse encrypted mempools with private mempools used by block builders, searchers, or relay operators. Private mempools restrict transaction data visibility to a specific group of trusted parties, often implementing their own rules for ordering and access.
The reality
Private mempools depend on trust in the operator; you're essentially placing bets that they won't front run, delay, or censor your transaction. In contrast, encrypted mempools eliminate the need for such trust by ensuring that no one can view the contents of transactions until it's too late to change their ordering.
This is a crucial distinction. In a private mempool, a malicious or compromised operator may still take advantage of your transaction. However, in an encrypted mempool, even the block proposer cannot access the transaction beforehand, making it basically impossible for them to censor or frontrun in real time.
Encrypted mempools can interact with private mempool infrastructure, but their security relies on cryptography rather than the reputation or goodwill of any specific entity.
The Bigger Picture: Encrypted Mempools in Ethereum’s Censorship Resistance Strategy
While MEV protection is often highlighted, encrypted mempools are crucial for real-time censorship resistance. They represent a key pillar in what is considered the holy trinity of censorship resistance for Ethereum.
- ePBS (enshrined proposer-builder separation)
- FOCIL (forced inclusion lists)
- Encrypted mempools
These three technologies work together to address various stages of the transaction supply chain, ensuring that transactions are included promptly, ordered fairly, and protected against predatory reordering or selective censorship.
The recent Glamsterdam decision to advance both FOCIL and ePBS at the protocol level marks a significant step toward enhancing censorship resistance. When combined with encrypted mempools, these upgrades can establish a transaction pipeline that is secure against both long-term and real-time forms of censorship.
Ethereum provides a level of censorship resistance, meaning that your transaction will eventually be recorded on the blockchain as long as there is at least one honest validator. However, in certain situations, "eventual" is not sufficient. High-frequency DeFi trades, options execution, and governance voting often require immediate inclusion rather than a delayed one.
Encrypted mempools prevent validators and builders from selectively censoring transactions in real-time, as they cannot view the contents of transactions until the ordering is finalized. When combined with FOCIL’s guaranteed inclusion lists and the separation of roles provided by ePBS, this results in a resilient and globally neutral transaction supply chain.
The Shutter approach
Shutter's design utilizes a decentralized network of Keypers who work together to generate the keys required to decrypt transactions. No single entity can access the transaction data prematurely; a threshold of participants must collaborate, ensuring that no single party can exploit the mempool data.
This approach:
- Prevents front running by securing the transaction order before the details are disclosed.
- Improves censorship resistance without relying on trusted hardware.
- Integrates incrementally into the existing Ethereum transaction flow
Roadmap and next steps
Shutter is implementing a gradual strategy to introduce encrypted mempools on the Ethereum network:
- Out-of-protocol deployment — We are developing prototypes that utilize builder and proposer commitments, beginning with Primev's MEV-Commit framework.
- EIP 7793 — A proposal to prevent proposers from reordering transactions after decryption, even if they act maliciously.
- Protocol integration with FOCIL and ePBS — Combining encryption with other inclusion and ordering guarantees for maximum censorship resistance.
Closing thoughts
Encrypted mempools are not intended to make Ethereum completely private or to eliminate all instances of MEV. Instead, they aim to address specific harmful behaviors that compromise fairness and trust in the network.
Encrypted mempools enhance transaction security, making Ethereum fairer for traders, safer for users, and more resistant to censorship.
At Shutter, we believe this is a natural next step in Ethereum's evolution—and we're building it in the open, with a focus on decentralization, composability, and usability.
