Ethereum is tackling one of its oldest and most exploitable problems: the ability for privileged observers to see pending transactions before they're ordered, enabling front-running and sandwich attacks that cost regular users money. Two major proposals, Fork Choice Enforced Inclusion Lists (FOCIL) and encrypted mempools through LUCID (EIP-8184), are now being seriously evaluated for the Hegota upgrade cycle as core solutions to make Ethereum's transaction pipeline fairer, harder to censor, and less vulnerable to harmful MEV (maximal extractable value).

What Is the Mempool Problem, and Why Should You Care?

When you send a transaction on Ethereum, it enters the public mempool before being included in a block. During this window, the transaction's contents are visible to block builders, searchers, and other network participants. This transparency creates an opportunity for exploitation. Someone watching the mempool can see your pending trade, place their own transaction ahead of yours to profit from the price movement you're about to trigger, and then place another transaction behind yours to sell at the higher price. This is called a sandwich attack, and it's one of the most common ways users lose money on Ethereum without realizing it.

For individual users, this might show up as worse trade execution, failed transactions, or hidden costs. For Ethereum as a network, it creates a deeper problem: a public blockchain should not allow privileged observers to systematically exploit users simply because they can see order flow earlier than everyone else. This undermines Ethereum's role as a neutral settlement layer.

How Do FOCIL and LUCID Work Together?

The two proposals address different parts of the problem. FOCIL, or Fork Choice Enforced Inclusion Lists, ensures that valid transactions cannot be indefinitely excluded from blocks. Today, Ethereum's block production involves multiple actors: users submit transactions, validators propose blocks, builders construct blocks, and searchers compete for MEV opportunities. This structure has made Ethereum more efficient in some ways, but it has also introduced new points where transaction inclusion can be influenced. FOCIL attempts to create stronger guarantees at the fork-choice level, making certain valid transactions harder to ignore through consensus rules.

LUCID, proposed as EIP-8184, introduces a commit-reveal design for encrypted transactions. Instead of broadcasting readable transactions into the public mempool, users submit sealed transactions carrying commitments to encrypted payloads. The actual transaction contents are revealed only after ordering decisions are finalized. If builders cannot see transaction contents while deciding order, they lose much of the advantage that enables classic front-running and sandwich attacks.

What Are the Key Components of the LUCID Design?

• Sealed-Ticket Transaction Type: Allows Ethereum to distinguish encrypted transactions from ordinary transactions and define special validation, ordering, and fee rules around them.
• Sealed Transaction Commitments: Users submit commitments to encrypted payloads rather than readable transaction data, hiding sensitive details during the most exploitable phase.
• Key Publication After Commitment Deadlines: Key material is published only after ordering is determined, ensuring that decryption happens after the transaction's position in the block is fixed.
• Top-of-Block Fee Mechanism: A specialized fee structure for encrypted transactions that accounts for the different ordering and validation rules.
• Execution and Consensus Layer Coordination: LUCID requires coordination between Ethereum's execution layer (where transactions run) and consensus layer (where validators agree on blocks).

The sealed-ticket transaction type is especially important because it preserves Ethereum's open transaction flow while reducing information leakage. LUCID does not attempt to privatize Ethereum's mempool through trusted centralized relays, which would create new trust assumptions. Instead, it tries to build encrypted transaction flow into Ethereum's own protocol.

Where Is LUCID in the Development Process?

LUCID is still unscheduled and has not been finalized for any hard fork, but recent project-management updates show that the work has moved beyond a purely conceptual stage. The LUCID project-management repository is now being used as a central coordination hub to map where LUCID exists across Ethereum's software-development lifecycle and what still needs to be built.

The execution-layer side appears to be the most mature part of LUCID right now. It includes work around sealed-ticket transactions, sealed transaction context, ordering and validation logic, top-of-block fee computation, and error handling. This gives developers a working model for how encrypted transactions may behave inside the execution environment. However, several major parts remain missing, including conformance fixtures, execution APIs, consensus-layer specifications, and full production client implementations.

Ethereum upgrades require more than an EIP (Ethereum Improvement Proposal) and one reference implementation. They require multiple clients, test fixtures, interoperability work, security review, devnet cycles, and consensus across core developers. The EIP exists in draft form, and the execution-layer reference implementation exists as a draft pull request. Partial execution-layer tests are available, and Besu already has prerequisite SLOTNUM opcode support through EIP-7843. However, the consensus-layer specifications and full production client implementations are still in early stages.

How to Understand Ethereum's Broader Upgrade Strategy

• Scaling Through Rollups: Ethereum has improved execution capacity through rollups, which bundle multiple transactions into a single transaction on the main chain, reducing costs and increasing throughput.
• Data Cost Reduction: Blobs lowered data costs for rollups by creating a temporary, cheaper storage layer that expires after a set period, making it more economical to post transaction data on-chain.
• Specialized Block Building: Proposer-builder separation created a more specialized block-building market, allowing validators to focus on consensus while builders optimize block construction.
• Fairness and Censorship Resistance: Ongoing upgrades such as Glamsterdam continue to refine performance and client coordination, while FOCIL and LUCID specifically target transaction fairness and censorship resistance.

Together, FOCIL and LUCID move Ethereum closer to a fairer transaction supply chain. FOCIL strengthens inclusion guarantees, ensuring valid transactions eventually get included. LUCID strengthens pre-execution privacy, reducing harmful MEV that depends on seeing user intent before ordering is fixed. Neither proposal removes all MEV, some forms of MEV are structural and arise from legitimate market activity. But encrypted mempools can significantly reduce the harmful MEV that depends on information asymmetry.

For readers tracking Ethereum's protocol roadmap, this also connects with broader coverage of Ethereum's All Core Developers discussions, where Hegota-related discussions are increasingly being linked with censorship resistance and transaction guarantees. The upgrade represents a shift in how Ethereum thinks about its core mission: not just scaling transaction volume, but ensuring that the transaction pipeline itself is fair, transparent, and resistant to exploitation.