Ethereum developers are pushing forward with plans to implement an Ethereum encrypted mempool to stop automated trading bots from exploiting users. Protocol researchers will meet on August 19 to debate proposals that would conceal pending transaction contents until they are firmly committed to the blockchain.
The shift aims to eradicate sandwich attacks, where predatory algorithms extract profit from ordinary swappers. But the proposed defenses create a new vulnerability, forcing users to trust third-party key publishers who could still leak or withhold transaction data before execution.
How an Ethereum encrypted mempool targets sandwich attacks
The root of the current vulnerability lies in the network’s public mempool. This acts as a transparent waiting room where all pending transactions sit before they are officially processed.
This open visibility allows automated traders to inspect orders and position their own transactions strategically. They extract value from regular network users before a trade ever settles on the ledger.
Sandwich attacks are the most common exploit derived from this transparency. A bot identifies a pending asset swap and instantly buys the same asset to drive the price unfavorably against the human user.
The bot then sells the asset immediately after the victim’s trade executes at the worsened price, pocketing the difference. While the overall volume of these exploits has cooled from historic peaks, high-profile targets remain vulnerable.
In April, Ethereum co-founder Vitalik Buterin fell victim to this exact mechanism. A notorious Maximal Extractable Value (MEV) bot known as Jaredfromsubway.eth successfully front-ran and back-ran a small swap executed from one of Buterin’s personal addresses.
The EIP-8184 LUCID framework and blind block building
To strip bots of their informational advantage, developers are evaluating a prominent draft proposal known as EIP-8184, or LUCID. The mechanism would fundamentally alter how block builders interact with user data.
Under LUCID, builders must commit to including sealed transactions in a block without knowing what the transactions actually do. Each sealed envelope contains a chargeable ticket and an encrypted payload.
The builder secures the transaction’s exact position in the block sequence first. Only after this irrevocable commitment is made can the transaction sender, or an assigned off-protocol key publisher, release the decryption information.
While this blind execution model solves the immediate problem of front-running bots, it introduces severe cryptographic friction. Enshrining a native encryption scheme that works at the network’s massive scale presents an unresolved technical challenge.
Technical hurdles and the ongoing decryption dilemma
A permanent, protocol-level encryption system requires satisfying an incredibly strict set of cryptographic constraints. The authors of EIP-8184 acknowledge that these demands push the limits of currently available technology.
The required parameters include small public keys, practical ciphertext sizes, and non-interactive decryption. The system must also operate without a trusted setup while providing strong chosen-ciphertext security and a credible pathway to post-quantum safety.
Protocol researchers admit that no known cryptographic construction currently fulfills all these requirements efficiently enough for Ethereum’s base layer. As a result, LUCID delegates the actual decryption architecture to systems outside the core protocol.
This structural compromise allows transaction senders to manage their own key releases or rely on a specialized key publisher. By keeping the decryption layer external, developers preserve the flexibility to integrate stronger, quantum-resistant cryptography later.
Financial liabilities tied to third-party key publishers
Externalizing the decryption process makes publisher selection a critical piece of the individual user’s security model. It also creates complex financial liabilities if the encryption process breaks down during block building.
If a decryption key is withheld or misses its scheduled arrival window, the initial LUCID draft applies a harsh protocol-level penalty. Crucially, this penalty for a failed multi-key reveal falls directly on the transaction sender.
The protocol does not automatically transfer the financial punishment to the third-party key provider responsible for the failure. To enforce an economic cost, LUCID mandates a reservation fee and caps the encrypted top-of-block segment at one-eighth of the block gas limit.
Users receive most of this reservation fee back after a successful decryption. However, if the reveal fails, the entire reservation is permanently lost, making selective releases exceptionally expensive for the network participant.
This penalty system fails to distinguish between an innocent network failure and malicious intent. The protocol cannot mathematically prove why a key failed to arrive, nor can it detect if a publisher deliberately leaked it to bots early.
EIP-8184 authors have suggested an off-protocol sponsorship arrangement to mitigate this risk. A trusted publisher could fund a transaction inside the bundle and absorb the financial loss if it remains sealed, though Ethereum consensus rules would not enforce this pledge.
Validator whitelists and alternative proposal EIP-8105
The August 19 developer agenda directly targets this enforcement blind spot. Researchers will debate how to prove whether members of a validator whitelist are actively withholding data or illegally selling keys early to trading desks.
A whitelist simply dictates who is technically authorized to publish keys. It offers no mechanism to determine if a missed deadline was caused by deliberate misconduct, software failure, or standard network latency.
This trust deficit has elevated an alternative draft known as EIP-8105. This proposal relies on a directed trust graph, allowing registered providers to explicitly identify other service providers they deem trustworthy.
EIP-8105 lets providers establish their own strict conditions for data withholding. It pushes the complex web of incentives, reliability scores, and potential slashing mechanisms entirely outside of Ethereum’s foundational consensus rules.
Other suggested approaches carry distinct operational costs. Implementing threshold decryption would distribute control among multiple validators but adds severe timing pressure to block production. Relying on trusted hardware introduces new operator dependencies and potential physical vulnerabilities.
Integration with FOCIL and the 2027 Hegotá upgrade
Any production-ready encrypted mempool deployment must align with the network’s established technical roadmap. Developers designed LUCID to explicitly extend the inclusion-list pipeline associated with FOCIL, formally known as EIP-7805.
FOCIL grants multiple validators the authority to identify specific transactions that a block builder is strictly required to include. This limits the power of central block builders to censor or exclude specific user operations.
Ethereum’s security roadmap currently positions FOCIL as a primary consensus-layer objective for the Hegotá upgrade, scheduled for 2027. More ambitious infrastructure milestones, particularly those requiring post-quantum cryptography, remain much further out on the timeline.
Wednesday’s call will force developers to decide if a temporary, non-quantum-resistant cryptographic solution is an acceptable bridge. As the network attempts to shield users from automated extraction, the tradeoffs between privacy, trust, and execution speed have never been clearer.