Ethereum developers meet Aug. 19 to weigh encrypting the network's public mempool, hiding pending trades from bots that front-run and sandwich them. The leading proposal, EIP-8184 ("LUCID"), seals transactions until their block position is fixed, but its authors say no known cryptographic design meets Ethereum's scale requirements, and proving that a key was wrongly withheld remains unresolved.
Ethereum developers are weighing a new defense against trading bots that exploit pending transactions before they reach the blockchain, and they will discuss encrypting the network's mempool during an Aug. 19 call.
The mempool is a public, transparent waiting room where pending transactions sit before execution. That visibility lets automated traders spot profitable orders and place transactions around them, extracting value from users before a trade settles.
A sandwich attack is the clearest example: a bot spots a pending swap, buys the same asset first to push the price against the user, then sells immediately after the victim's trade executes at the worse price. Estimates suggest losses from such attacks have declined from earlier peaks, but the problem has not disappeared. In April, Ethereum co-founder Vitalik Buterin was himself targeted when the Jaredfromsubway.eth bot front-ran and back-ran a small swap from one of his addresses.
A sealed mempool, not a private one
Traders can already dodge front-running by routing orders through private relays, but that trades exposure for dependence on intermediaries that control inclusion. Developers instead want an encrypted public mempool that keeps blockspace permissionless while hiding trade contents from builders and bots until ordering is locked in.
The leading design is EIP-8184, known as LUCID, which would require block builders to commit to sealed transactions carrying a chargeable ticket and an encrypted payload without knowing what the transaction does. Only after that commitment would the sender, or an off-protocol key publisher, release the information needed to decrypt it.
No construction fits Ethereum's scale yet
LUCID's own authors list small public keys, non-interactive decryption, no trusted setup, practical ciphertext sizes, strong chosen-ciphertext security, and a credible route to quantum safety as requirements, and they say no known cryptographic construction currently satisfies the full set at Ethereum's scale. The proposal therefore leaves decryption outside the core protocol, meaning publisher selection becomes part of a user's own security model.
That flexibility creates financial risk: if a key is withheld or fails to arrive on schedule, LUCID's initial draft leaves the protocol-level penalty with the sender rather than the third-party key provider. To price that risk, LUCID caps its encrypted top-of-block segment at one-eighth of the block gas limit and charges a reservation fee that is mostly refunded on success but fully lost on a failed reveal — though it still cannot prove whether a publisher deliberately leaked a key early.
Wednesday's agenda will also ask whether a temporary, non-post-quantum solution is acceptable, alongside an alternative proposal, EIP-8105, which uses a directed trust graph of registered providers. LUCID is designed to extend the inclusion-list pipeline behind FOCIL (EIP-7805), which Ethereum's roadmap currently targets for the Hegotá upgrade in 2027, while broader post-quantum milestones sit further out still.
Source: CryptoSlate
Trading involves risk.
Risk Disclaimer
