Anyone who has traded on a decentralized exchange has probably lost a little value to an invisible predator. Bots that watch Ethereum’s public mempool — the waiting room where transactions sit before they’re confirmed — can spot a pending trade, jump in front of it, and profit at the trader’s expense. It’s called a sandwich attack, and an Ethereum encrypted mempool is now the proposal developers are weighing to stop it for good.
How an Ethereum Encrypted Mempool Would Work
Ethereum developers are now weighing a proposal that goes after the root cause instead of patching around the symptoms. Known as EIP-8184, or LUCID, the design would keep transaction contents hidden from block builders until after they’ve already committed to including them — an Ethereum encrypted mempool in practice. Rather than submitting a transaction that anyone can read, a sender would submit a sealed payload alongside a “ticket” that proves it’s valid and pays its fees. Builders would agree to slot the transaction into a block without ever seeing what’s inside it. Only after that commitment is locked in would the decryption key be released — either by the sender or by a designated key-publishing service — revealing what the transaction actually does.
Why It Stops Front-Running
The elegance of this approach is that it removes the information bots rely on at the exact moment it matters most. A predatory actor can’t sandwich a trade it can’t read. Ethereum developers are set to discuss the proposal in a developer call today, and if it advances, it’s expected to be paired with FOCIL (EIP-7805), a related mechanism for guaranteeing transaction inclusion, as part of the network’s 2027 “Hegotá” upgrade. That would follow the earlier Glamsterdam upgrade, which is already rewriting how Ethereum charges gas, as the next major step in the network’s roadmap.
The Hard Problems Still Unsolved
Getting there isn’t trivial. The team working on LUCID has flagged a genuinely hard cryptography problem: no existing scheme fully satisfies Ethereum’s requirements for small public keys, non-interactive decryption, freedom from any trusted setup, manageable ciphertext sizes, robust security guarantees, and resistance to future quantum computers — all at once, and all at Ethereum-scale. There are also open governance questions, like how to tell the difference between a sender who maliciously withholds a decryption key and one who simply suffers a technical failure, and who should bear responsibility when a key publisher — rather than the sender — is the one that fails to reveal.
Why It Matters for the Ecosystem
Those unresolved details matter, but the direction is notable regardless of exactly how the cryptography shakes out. MEV extraction has already declined from its earlier peaks as tooling and awareness have improved, but bolting an Ethereum encrypted mempool onto the protocol itself would be a structural fix rather than a stopgap. It’s the difference between telling users to be careful in a bad neighborhood and redesigning the street so the neighborhood isn’t dangerous anymore. For an ecosystem that increasingly markets itself as ready for institutional-scale trading, closing off a well-known avenue for value extraction is exactly the kind of infrastructure work that determines whether that pitch holds up.
If LUCID or something like it clears the cryptographic and design hurdles, an Ethereum encrypted mempool would mark a meaningful step toward transaction privacy becoming a native property of Ethereum rather than something users have to seek out through third-party relays. You can read more on the proposal and the developers weighing it in CryptoSlate’s coverage.
Leave a Reply