Ethereum proposal would encrypt mempool to block front-running

Ethereum developers are proposing to encrypt the public mempool to prevent automated traders from inspecting and acting on pending transactions. The protocol community will discuss EIP-8184, called LUCID, during an Aug. 19 “Encrypt the Mempool” call.

The public mempool currently exposes pending transactions so anyone can see them before inclusion in a block. Automated trading programs use that visibility to place orders around large or profitable swaps, a practice known as front-running and sandwich attacks. Those tactics have affected regular users and high-profile addresses.

EIP-8184 would require senders to submit sealed transactions that carry a chargeable ticket and an encrypted payload. Block builders would commit to the sealed entries without decrypting them. After builders lock in an ordering, the sender or an authorized key publisher would release decryption material so the transaction can be executed. The proposal uses a commit-then-reveal pattern to keep the mempool public while limiting access to transaction details until ordering is fixed.

The authors of LUCID list several cryptographic requirements for a system at Ethereum’s scale: small public keys, non-interactive decryption, no trusted setup, compact ciphertexts, strong chosen-ciphertext security and a path toward quantum-resistant algorithms. The draft says no single encryption construction currently meets all those constraints at global blockchain scale.

To preserve flexibility, LUCID leaves the specific decryption method outside the core protocol. Users could manage key release themselves or follow instructions from an off-chain key publisher. The proposal treats publisher selection as part of the user’s security model.

LUCID also includes economic measures to discourage withheld or late reveals. The proposal would limit the encrypted top-of-block area to one-eighth of the block gas limit and require a reservation fee. Most of the reserved fee would return after a successful reveal; the full reservation could be lost if a reveal fails. The authors describe optional off-protocol sponsorships where a publisher funds a bundled transaction and absorbs a failed-reveal cost, but such sponsorships would not be enforced by the protocol.

Developers are considering different governance and technical models for key publication. A whitelist could name authorized publishers but would not itself prove whether a missing key resulted from deliberate withholding, software errors or network problems. An alternative, EIP-8105, proposes a directed trust graph in which providers register and vouch for one another and set their own withholding conditions. Other approaches under discussion include threshold decryption, which splits control among multiple parties, and trusted hardware, which would shorten key access but introduce hardware and operator dependencies.

Any deployment would need to coordinate with broader Ethereum upgrades. LUCID is designed to extend the inclusion-list pipeline tied to FOCIL (EIP-7805). FOCIL is scheduled as a consensus-layer priority for the Hegotá upgrade slated for 2027. On Aug. 19, developers plan to discuss whether a temporary non–post-quantum cryptographic solution is acceptable, how to detect and prove withheld keys, and what off-chain incentive systems and reliability standards should look like before a production rollout.