A new design for Ethereum’s encrypted mempool

Sponsored Content

Sandwich attacks cost Ethereum users an estimated $60 million per year. Transactions broadcast to the public mempool are publicly visible before inclusion, which gives MEV bots the ability to affect the order of transactions and insert their own for profit. This problem has persisted on some level in spite of years of discussion and various out-of-protocol mitigation attempts.

Encrypting mempool transactions would be one of the most compelling solutions to prevent MEV. While this idea has been actively discussed for years, it has not yet been implemented at the protocol level. In our earlier research, we examined several proposals based on threshold-encryption, including Shutter, Batched Threshold Encryption, and Flash Freezing Flash Boys. In this article, we turn to a meta proposal titled “Universal Enshrined Encrypted Mempool (EIP-8105)“.

How EIP-8105 approaches mempool encryption

Universal Enshrined Encrypted Mempool, also known as EIP-8105, is a scheme-agnostic encrypted mempool design, which means it can support a wide range of encryption methods, including threshold encryption, MPC committees, TEEs, delay encryption, and fully homomorphic encryption. A new system contract on the execution layer, called the key provider registry, is planned to facilitate this flexible design. It would allow any account to register as a key provider that holds and reveals decryption keys using their own preferred encryption technology. 

How transactions are executed in Universal Enshrined Encrypted Mempool

Universal Enshrined Encrypted Mempool introduces two new transaction types under the EIP-2718 framework: 0x05 for encrypted transactions and 0x06 for decrypted transactions. An encrypted transaction is an envelope with an encrypted payload and a public payload, which contains the envelope nonce, gas amount, gas price parameters, key provider ID, key ID, and a signature. This structure is required to associate the transaction with the chosen key provider, assign a nonce and ensure gas fees for the blockspace are covered.

EIP-8105 follows a two-step execution flow. In the first step, the encrypted transaction envelope is included in a block even though the payload itself remains hidden. Key providers monitor transactions with encrypted payloads, collect the relevant transaction key IDs, and publish either the corresponding decryption keys or a withhold notice once the block builder publishes the data. 

Once the block builder has published the execution payload, the relevant key provider reveals either the decryption key or a withhold notice. A Payload Timeliness Committee (PTC) monitors whether the decryption keys referenced by encrypted transactions are published on time, validates them, and attests to whether a valid key was present or missing. If the key is available and decryption succeeds, the resulting decrypted transaction is executed in the following block. If the key is missing, withheld, or decryption fails, the decrypted payload is skipped, while the envelope remains included, and the transaction fee is still paid.

The EIP also enforces a block structure that prevents MEV-extracting transactions from being inserted in the window between decryption and execution. Decrypted transactions must appear at the beginning of a block, plaintext transactions remain in the middle, and encrypted transactions are placed at the end. This ordering allows encrypted payloads to be revealed and executed only after inclusion, while preventing secondary MEV. 

While EIP-8105 significantly limits MEV exposure, earlier providers in the block retain a limited ability to extract MEV from later transactions by selectively revealing or withholding their decryption keys. The proposal attempts to mitigate this by letting key providers designate other trusted providers and ordering transactions according to the resulting key provider trust graph.

Encrypted Mempools and Ethereum’s Roadmap

Encrypted mempools are becoming an increasingly important part of Ethereum’s roadmap, as the ecosystem looks for protocol-level ways to reduce harmful MEV. While EIP-8105 is no longer being positioned as one of the headliners for the first 2027 hard fork, it remains an open draft, and its ideas continue to inform the broader effort to prepare a leading encrypted-mempool proposal for the upgrade.