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 it’s been one of the most persistent problems in decentralized finance since the earliest days of automated market makers.
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. 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.
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.
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.
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 privacy 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, it 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