TL;DR
- Public mempool visibility enables $60 million yearly sandwich attacks.
- EIP-8105 encrypts transactions before block inclusion to stop bots.
- Key providers reveal decryption keys after block builders publish data.
Ethereum users lose approximately $60 million each year to sandwich attacks. How does happen? MEV bots monitor the public mempool, where transactions wait for confirmation. They spot a user’s trade, place their own transaction just before and just after, pocketing profits at the user’s expense. The problem has persisted for years. Out-of-protocol mitigation attempts have failed repeatedly.
The public mempool operates like an open ledger. Every transaction becomes visible to everyone before block inclusion. Bots exploit information, reorder transactions, and insert their own for profit. Sandwich attacks represent only one form of harmful MEV. Front-run liquidations and other extraction methods also exist. Yet the result remains the same: regular users pay more or receive less than expected.
The industry needs a protocol-level solution. A response that prevents bots from seeing transactions before execution. The most promising answer: encrypt the mempool. The idea has circulated for years. Proposals like Shutter, Batched Threshold Encryption, and Flash Freezing Flash Boys explored the path. Now a new meta-proposal draws attention: EIP-8105, also known as “Universal Enshrined Encrypted Mempool.”
How EIP-8105 approaches mempool encryption
EIP-8105 does not impose a single encryption method. Instead, it functions as a scheme-agnostic design. It supports multiple technologies: threshold encryption, MPC committees, trusted execution environments (TEEs), delay encryption, and fully homomorphic encryption. Developers can choose their preferred method. Flexibility defines the proposal.
The system introduces a new contract on the execution layer: the key provider registry. Any account can register as a key provider. Each provider holds and reveals decryption keys using its preferred technology. An open and decentralized mechanism.
EIP-8105 creates two new transaction types under the EIP-2718 framework. Type 0x05 for encrypted transactions. Type 0x06 for decrypted transactions. An encrypted transaction works like an envelope. It contains an encrypted payload and a public payload. The public part includes: the envelope nonce, gas amount, gas price parameters, key provider ID, key ID, and a digital signature. This structure associates the transaction with a specific provider, assigns a nonce, and covers gas fees for blockspace.
The execution flow follows two clear steps. In the first step, the encrypted transaction envelope enters a block, but the payload remains hidden. Key providers monitor transactions with encrypted payloads, collect relevant key IDs, and publish either decryption keys or a withhold notice once the block builder releases the data.
In the second step, after the block builder publishes the execution payload, the key provider reveals the decryption key or a withhold notice. A Payload Timeliness Committee (PTC) monitors whether the referenced decryption keys arrive on time. The committee validates keys and attests to whether a valid key exists. If the key is available and decryption succeeds, the resulting decrypted transaction executes in the following block. If the key is missing, withheld, or decryption fails, the decrypted payload gets skipped. The envelope remains included, and the user still pays the transaction fee.
The block structure prevents MEV extraction. Decrypted transactions appear at the beginning of the block. Plaintext transactions stay in the middle. Encrypted transactions sit at the end. This ordering allows revealing and executing encrypted payloads only after inclusion, while blocking secondary MEV. No bot can insert an extracting transaction in the window between decryption and execution.
A limitation persists. Earlier key providers in the block retain a reduced ability to extract MEV from later transactions by selectively revealing or withholding their decryption keys. The proposal attempts to mitigate the risk by letting providers designate other trusted providers. It then orders transactions according to the resulting key provider trust graph.
The path to encrypted mempools on Ethereum
Encrypted mempools gain ground on Ethereum’s roadmap. The ecosystem actively seeks protocol-level ways to reduce harmful MEV. Sandwich attacks, front-run extractions, and other forms of value extraction erode user trust. Out-of-protocol solutions have proven insufficient. Patches and reactive measures do not solve the root problem.
EIP-8105 no longer appears as a headliner for the first 2027 hard fork. Nevertheless, the proposal remains an open draft. Its ideas continue to inform the broader effort to prepare a leading encrypted-mempool proposal for the next upgrade. Developers are not abandoning the concept. They refine it, discuss it, and adapt it.
The key question: how much longer will the community wait? Each year, $60 million leaves the ecosystem for MEV bots. Each month, thousands of users suffer unfavorable executions without even knowing it. Each day, the public mempool continues showing transactions to the highest bidder.
Mempool encryption is not a luxury option. It is a structural necessity. Ethereum promotes itself as a decentralized and neutral settlement layer. However, full mempool transparency creates an uneven playing field. Bots with better reordering capabilities always win. Regular users always lose.
EIP-8105 offers a flexible and agnostic path. It does not force a single encryption technology. It allows competition among key providers. It establishes clear rules about block ordering and timeliness committees. The proposal does not solve all MEV problems, but it attacks one of its most direct sources: pre-inclusion visibility.
While developers debate technical details, money continues flowing to extractors. The industry needs less discussion and more implementation. Users need private transactions by default, not as an optional feature for those paying higher gas fees. Ethereum’s roadmap includes encrypted mempools. Now execution remains the only missing piece.
The cost of inaction is measurable: $60 million per year from sandwich attacks alone, excluding other MEV forms. Every block mined with a public mempool represents a missed opportunity to protect users. EIP-8105 is not the final solution, but it constitutes a concrete step in the right direction. The upcoming hard forks will determine whether Ethereum embraces transactional privacy or continues tolerating value extraction as a necessary evil.
