EIP-8105: Ethereum's New Encrypted Mempool Design

EIP-8105 — the Universal Enshrined Encrypted Mempool — is Ethereum's most ambitious attempt yet to solve a problem that has drained hundreds of millions from ordinary users: MEV bots reading your transactions before they land in a block. The proposal introduces a flexible, scheme-agnostic encrypted mempool that hides transaction payloads until after inclusion, and it's still quietly influencing how Ethereum developers think about the protocol's 2027 upgrade path.

The $60 Million Problem EIP-8105 Is Trying to Fix

Sandwich attacks cost Ethereum users an estimated $60 million per year, according to MEV sandwich attacks tracked on-chain by EigenPhi. The mechanics are simple and brutal: MEV bots watch the public mempool, spot a pending swap or trade, insert their own transaction before and after yours, and pocket the difference. The victim pays a worse price. The bot profits. The network looks the other way.

This isn't a new grievance. Ethereum researchers have been circling the problem since at least 2019, with dozens of proposals attempted and abandoned at the protocol level. The core issue is that transactions broadcast to Ethereum's mempool are fully transparent before a block builder ever touches them — which is exactly the window MEV bots need.

Earlier research explored threshold-encryption-based proposals like Shutter, Batched Threshold Encryption, and Flash Freezing Flash Boys. Each had merit, but none crossed the line from research to enshrined protocol feature. EIP-8105 takes a different approach: instead of picking one encryption scheme and betting on it, the proposal is built to work with any of them.

What Is EIP-8105 and How Does the Encrypted Mempool Work?

A scheme-agnostic architecture that any key provider can plug into

The encrypted mempool design at the heart of EIP-8105 is best understood through its single defining feature: scheme-agnosticism. Rather than hardcoding a particular cryptographic method, the proposal creates a registry-based system that lets multiple encryption technologies coexist. Supported approaches include threshold encryption, MPC committees, TEEs (trusted execution environments), delay encryption, and fully homomorphic encryption.

At the execution layer, a new system contract called the key provider registry is the infrastructure backbone. Any Ethereum account can register as a key provider in this registry, commit to an encryption method, and start issuing and later revealing decryption keys. The flexibility is deliberate — no single encryption primitive dominates, and the system can evolve as cryptographic research matures.

EIP-8105 introduces two new transaction types under the EIP-2718 framework. Type 0x05 is the encrypted transaction — an envelope carrying a hidden payload alongside a public section that includes the envelope nonce, gas amount, gas price parameters, key provider ID, key ID, and a signature. Type 0x06 is the decrypted transaction, produced once the key provider reveals the decryption key. That two-type structure is not cosmetic: it ensures the network can process gas payments and validate inclusion even before the actual transaction intent is known.

Two Blocks, One Reveal: How EIP-8105 Executes Transactions

EIP-8105 runs on a two-step execution flow. In the first step, an encrypted transaction envelope gets included in a block — payload hidden. Key providers watch the chain for transactions referencing their key IDs. Once the block builder publishes the execution payload, the relevant key provider either releases the decryption key or issues a withhold notice. Timing is everything here.

A body called the Payload Timeliness Committee (PTC) monitors whether decryption keys are published on schedule. The PTC validates each key and attests to its presence or absence. If decryption succeeds, the resulting plaintext transaction executes at the top of the next block. If the key is missing, withheld, or decryption fails for any reason, the encrypted envelope remains included — and the transaction fee is still collected — but the payload is skipped entirely. Users pay regardless. That design choice discourages spam without compromising liveness.

Block structure itself is also enforced. Decrypted transactions must appear at the beginning of a block. Plaintext transactions go in the middle. Encrypted transactions sit at the end. This ordering is not arbitrary — it closes a specific window where MEV bots could otherwise insert themselves between the moment of decryption and the moment of execution.

Does EIP-8105 Actually Eliminate MEV?

Not entirely — and the proposal's authors don't claim it does. Earlier key providers in the block still retain a limited ability to extract MEV from later transactions by choosing when to reveal their decryption keys. A key provider could theoretically observe what decrypted transactions look like once they're committed and withhold its own key to create a more favorable ordering.

EIP-8105 tries to address this with a trust graph system: key providers can designate other trusted providers, and transactions get ordered according to the resulting trust relationships. It's a patch on a residual vulnerability, not a total fix. Honest analysis says this is a hard problem — the proposal reduces MEV surface area dramatically but doesn't collapse it to zero.

What's more consequential for Ethereum's near-term timeline is where EIP-8105 sits on the roadmap. The proposal is no longer expected to headline the first 2027 hard fork. It remains an open draft. But encrypted mempools are very much on Ethereum's formal agenda, and EIP-8105's architecture — particularly the key provider registry and the scheme-agnostic approach — is actively shaping how the broader research community thinks about which proposal should eventually get enshrined. The fact that it's an open draft doesn't mean it's dead. Sometimes the proposals that take the longest to land are the ones that end up mattering most.