Ethereum developers are weighing a new defense against predatory trading bots that exploit pending transactions before they reach the blockchain.
The problem stems from Ethereum’s public mempool, a transparent waiting room where transactions can be inspected before execution. That visibility lets automated traders spot profitable orders and place their own transactions around them, extracting value from users before a trade settles.
The practice has become most closely associated with sandwich attacks. A bot spots a pending swap, buys the same asset first to move the price against the user, then sells immediately after the victim’s trade executes at the worse price.
While estimates suggest losses from such attacks have declined from earlier peaks, the problem has not disappeared. In April, Ethereum co-founder Vitalik Buterin was himself targeted when the notorious Jaredfromsubway.eth bot front-ran and back-ran a small swap from one of his addresses.
Developers are now exploring whether encryption can remove the informational advantage that makes those attacks possible.
Protocol researchers are scheduled to discuss the issue during an Aug. 19 “Encrypt the Mempool” call, where they will examine proposals designed to conceal transaction contents until their position in a block has already been committed.
The effort targets a long-running tradeoff for Ethereum users. Traders can already bypass the public mempool by routing transactions through private relays, reducing their exposure to front-running. But that protection comes with dependence on intermediaries that control transaction inclusion and availability.
An encrypted public mempool would attempt to preserve permissionless access to blockspace while preventing builders and bots from seeing the underlying trade before its ordering is fixed.
One leading proposal is EIP-8184, known as LUCID. The draft would require block builders to commit to sealed transactions containing a chargeable ticket and encrypted payload without knowing what the transaction does. Only after the commitment is made would the sender, or an off-protocol key publisher, release the information needed to decrypt it.
While that design closes one avenue for exploitation, it also creates another problem Ethereum developers have yet to solve.
The decryption dilemma
A fully enshrined encryption scheme would need to satisfy a difficult set of constraints at Ethereum’s scale.
EIP-8184’s 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 among the requirements.
They say no known cryptographic construction currently satisfies the entire set at Ethereum’s scale.
LUCID therefore leaves the decryption construction outside the core protocol, allowing senders to manage their own key release or follow instructions from a key publisher. That preserves flexibility for stronger cryptography later, but EIP-8184’s security considerations explicitly make publisher selection part of the user’s security model.
The design also creates financial liabilities.
If a key is withheld or fails to arrive on schedule, LUCID’s initial draft leaves the protocol-level penalty for a failed multi-key reveal with the transaction sender rather than automatically transferring it to the third-party key provider.
To put an economic cost on failed reveals, LUCID caps its encrypted top-of-block segment at one-eighth of the block gas limit and uses a reservation fee. Most of that amount can be returned after successful decryption, while the full reservation can be lost when the reveal fails.
That makes failed or selective releases expensive, but it cannot establish why a key failed to arrive or determine whether a publisher deliberately leaked it early.
The authors have described an off-protocol sponsorship arrangement where a publisher funds a transaction inside the bundle and absorbs the loss if it remains sealed. Ethereum itself would not enforce that pledge.
Trading intermediaries and network scaling
Wednesday’s agenda will ask developers whether a temporary, non-post-quantum cryptographic solution is acceptable.
It also targets the deeper enforcement problem: how withholding or early key selling by members of a validator whitelist could be proved and whether those proofs could be automated.
A whitelist can establish who is authorized to publish keys. It cannot by itself distinguish deliberate misconduct from software failure, network latency, or a missed deadline.
An alternative proposal, EIP-8105, uses a directed trust graph where registered providers identify other providers they trust. Providers can establish their own withholding conditions, leaving incentives, reliability systems, and potential punishment mechanisms outside Ethereum’s consensus rules.
Other approaches introduce their own costs. Threshold decryption distributes control among multiple participants but adds timing pressure. Trusted hardware can shorten the path to a key while introducing new hardware and operator dependencies.
Any production deployment would also need to coordinate with Ethereum’s broader roadmap. LUCID is designed to extend the inclusion-list pipeline associated with FOCIL, or EIP-7805, which gives multiple validators a role in identifying transactions a builder must include.
Ethereum’s security roadmap currently targets FOCIL as a consensus-layer priority for the Hegotá upgrade in 2027, while broader post-quantum infrastructure milestones sit further out.
