Ethereum's Next MEV Fix: How EIP-8105 Plans to Lock Down the Mempool

Sandwich attacks drain Ethereum users of roughly $60 million annually. The culprit? A wide-open mempool where every transaction sits exposed before landing on-chain, handing MEV bots a free pass to reorder transactions and slip in their own profitable moves. It's a systemic problem that's haunted Ethereum despite years of debate and various band-aid solutions. EIP-8105 targets the root issue by encrypting transactions until after they're included in a block.

The Encrypted Mempool Problem (and Why It Matters)

We've covered threshold-encryption proposals like Shutter and Flash Boys in previous crypto analysis, but EIP-8105 takes a different angle. It's scheme-agnostic—meaning it can work with multiple encryption methods simultaneously, from threshold encryption to MPC committees, TEEs, delay encryption, and fully homomorphic encryption. The design hinges on a new system contract called the key provider registry, letting any account register as a key provider using their preferred encryption tech.

How the Two-Transaction System Works

EIP-8105 introduces two new transaction types under the EIP-2718 framework: 0x05 for encrypted transactions and 0x06 for decrypted transactions. An encrypted transaction packages an encrypted payload with publicly visible metadata—envelope nonce, gas amount, gas price parameters, key provider ID, key ID, and signature. This structure ties the transaction to its key provider, assigns a nonce, and ensures gas fees are covered.

The execution flow unfolds in two stages. First, the encrypted envelope gets included in a block with its payload still hidden. Key providers watch for transactions referencing their encrypted payloads, then publish either decryption keys or withhold notices once the block builder reveals the data. A Payload Timeliness Committee monitors whether keys surface on schedule, validates them, and attests to their presence or absence.

If decryption succeeds, the transaction executes in the following block. If the key is missing, withheld, or decryption fails, the payload gets skipped—but the envelope stays included and the fee is still paid.

Preventing Secondary MEV Through Block Structure

Here's where it gets clever: EIP-8105 enforces a strict block ordering that blocks secondary MEV extraction. Decrypted transactions must appear first, plaintext transactions in the middle, encrypted transactions at the end. This prevents MEV-extractors from sandwiching between decryption and execution.

That said, the proposal isn't perfect. Earlier key providers retain limited MEV extraction ability by selectively revealing or withholding decryption keys. EIP-8105 attempts to mitigate this by allowing providers to designate trusted peers and order transactions through a key provider trust graph.

Where EIP-8105 Sits on Ethereum's Roadmap

Encrypted mempools increasingly matter to Ethereum's long-term MEV strategy. While EIP-8105 isn't headlining the first 2027 hard fork, it remains an open draft actively shaping the conversation around protocol-level MEV reduction. The ideas embedded here are informing work on a leading encrypted-mempool proposal for future upgrades.