Ethereum’s next major protocol debate is not only about scaling the network. It is also about making the transaction pipeline fairer, harder to censor, and less vulnerable to harmful MEV.

Over the past few years, Ethereum has improved several parts of its infrastructure. Rollups increased execution capacity, blobs lowered data costs, proposer-builder separation created a more specialized block-building market, and ongoing upgrades such as Glamsterdam continue to refine performance and client coordination.

• Ethereum’s Fairness Problem
• FOCIL and the Inclusion Layer
• LUCID and Encrypted Mempools
• Current Development Progress
• Open Design Challenges
• Why Hegota Matters

Ethereum’s Fairness Problem

The one old problem remains visible to every user who sends a transaction through the public mempool, i.e., before a transaction is included, someone else can often see it. That visibility creates the foundation for front-running, sandwich attacks, transaction reordering, and selective censorship.

For regular users, this may show up as worse trade execution, failed transactions, or hidden costs. For Ethereum as a network, it creates a deeper neutrality 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 is why Ethereum’s Hegota discussions are becoming important. The upgrade is increasingly being framed around censorship resistance, validator efficiency, and transaction inclusion guarantees. In that context, two ideas stand out: Fork Choice Enforced Inclusion Lists, or FOCIL, and encrypted mempools through LUCID, also known as EIP-8184.

EtherWorld has already covered this direction in Hegotá Should Complete the Holy Trinity of Censorship Resistance and Ethereum Coalition Pushes for Encrypted Mempool in Upcoming Hardfork. This article builds on that foundation and examines how the latest LUCID progress, testing stack, and consensus-layer discussions fit into Ethereum’s broader roadmap.

FOCIL helps ensure that valid transactions cannot be excluded indefinitely. LUCID helps ensure that transaction contents remain hidden until ordering is finalized. Together, they could make Ethereum’s transaction pipeline more censorship-resistant and less exploitable.

FOCIL and the Inclusion Layer

FOCIL, or Fork Choice Enforced Inclusion Lists, is one of the strongest candidates for Hegota’s headline feature. It aims to address one of Ethereum’s most important censorship-resistance problems: builders should not be able to ignore valid transactions simply because those transactions are inconvenient, politically sensitive, or economically unattractive.

Today, Ethereum’s block production pipeline involves several actors. Users submit transactions, validators propose blocks, builders construct blocks, relays may sit between proposers and builders, 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. Instead of relying only on market incentives or goodwill from builders, inclusion lists make certain valid transactions harder to ignore. If a transaction meets the required conditions, the protocol can enforce its inclusion through consensus rules.

This matters because censorship resistance is not just a philosophical goal. It is a practical requirement for Ethereum’s role as a neutral settlement layer. If users cannot trust that valid transactions will eventually be included, Ethereum becomes less reliable as a financial and coordination system.

EtherWorld’s previous coverage of All Core Developers Consensus Call #180 highlighted how Hegota discussions are already moving toward early proposal evaluation.

LUCID and Encrypted Mempools

LUCID, proposed as EIP-8184, introduces an encrypted mempool design for Ethereum. Instead of broadcasting readable transactions into the public mempool, users submit sealed transactions. These transactions carry commitments to encrypted payloads. The actual transaction contents are revealed only after ordering decisions are finalized.

This commit-reveal design changes the information available to block builders. If builders cannot see transaction contents while deciding order, they lose much of the advantage that enables classic front-running and sandwich attacks. The transaction still enters Ethereum’s public inclusion pipeline, but the sensitive details remain concealed during the most exploitable phase.

The design includes several key components:

• A new sealed-ticket transaction type
• Sealed transaction commitments
• Key publication after commitment deadlines
• A top-of-block fee mechanism
• Reuse of the SLOTNUM opcode from EIP-7843
• Coordination between the execution layer and consensus layer

The sealed-ticket transaction type is especially important. It allows Ethereum to distinguish encrypted transactions from ordinary transactions and define special validation, ordering, and fee rules around them. LUCID does not attempt to privatize Ethereum’s mempool through trusted centralized relays. Instead, it tries to preserve Ethereum’s open transaction flow while reducing information leakage.

This difference matters. Private order-flow systems already exist in crypto, but they often create new trust assumptions. Users may have to rely on intermediaries, private relays, or specialized infrastructure. LUCID’s ambition is more protocol-native: build encrypted transaction flow into Ethereum’s own roadmap.

In practice, a LUCID transaction flow may look like this:

1. A user prepares a transaction.
2. The transaction is encrypted.
3. A sealed-ticket transaction is submitted.
4. The network sees a commitment, not the readable payload.
5. Ordering is determined.
6. Key material is published.
7. The payload is decrypted.
8. The transaction executes.

This does not remove all MEV. Some forms of MEV are structural and arise from legitimate market activity. But encrypted mempools can reduce harmful MEV that depends on seeing user intent before ordering is fixed.

This is why LUCID fits naturally beside FOCIL. FOCIL strengthens inclusion. LUCID strengthens pre-execution privacy. Together, they move Ethereum closer to a fairer transaction supply chain.

For readers tracking Ethereum’s protocol roadmap, this also connects with EtherWorld’s broader coverage of Ethereum ACD Monitor #1: Glamsterdam Devnet-6, Hegota Proposals, FOCIL Updates & EIP Activity, where Hegota-related discussions are increasingly being linked with censorship resistance and transaction guarantees.

Current Development Progress

LUCID is still unscheduled and has not been finalized for any hard fork. However, 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. Its purpose is to map where LUCID exists across Ethereum’s software-development lifecycle and what still needs to be built. This includes the EIP specification, execution-layer reference implementation, tests, execution APIs, consensus-layer specifications, client implementations, and project coordination.

The EIP exists in draft form. The execution-layer reference implementation exists as a draft PR. Partial execution-layer tests are available. Besu already has prerequisite SLOTNUM opcode support through EIP-7843. However, several major parts remain missing, including conformance fixtures, execution APIs, consensus-layer specs, and full production client implementations.

That distinction is important. Ethereum upgrades require more than an EIP and one reference implementation. They require multiple clients, test fixtures, interoperability work, security review, devnet cycles, and consensus across core developers.

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.

But the consensus layer remains one of the largest open areas. LUCID requires consensus-layer participation because the beacon chain must help coordinate commitment dissemination, key publication, scheduling, and possibly voting or penalties. Without a detailed consensus-layer specification, clients cannot fully implement or test the design.

Recent CL discussion has started to address this gap. Contributors are expected to begin drafting specification skeletons covering SSZ containers, inclusion lists, payload bid extensions, and LucidKey votes. Erigon developers have also shown interest in reviewing and potentially implementing draft pieces because Erigon 3 combines both execution and consensus functionality.

A separate Kurtosis-based testing stack has also been created for encrypted mempool prototyping. It uses Besu and Teku clients, MEV infrastructure, and Spamoor-generated Uniswap swap traffic to simulate sandwich-attack opportunities. The stack includes execution clients, consensus clients, relay-builder-boost infrastructure, monitoring tools, and high-throughput transaction generation.

Ethereum’s upgrade process is slow for good reason. But the presence of reference code, test infrastructure, coordination repositories, and CL discussion shows that LUCID is becoming a concrete engineering effort.

Open Design Challenges

Despite the progress, several hard problems remain unresolved.

The first is key publication. In LUCID, transactions are encrypted first and decrypted later. That means someone or something must publish the key material after ordering is finalized. The design must ensure that key publication happens reliably, without giving participants too much optionality to withhold keys or manipulate outcomes.

Recent discussions identified confusion around the key release fee. Developers noted that this fee reduces gas headroom but is not itself a normal gas fee. The current direction is to treat it as a separate object from gas, with wallet-layer responsibility for accounting. This could require new RPC methods so wallets can estimate fees correctly.

This may sound like a small technical detail, but wallet accounting is critical for user experience. If wallets cannot explain or estimate costs clearly, encrypted transactions may become difficult for regular users to adopt.

The second challenge is builder optionality. LUCID reduces the ability to exploit visible transaction contents, but it does not fully remove all possible timing or withholding strategies. Developers have acknowledged that probabilistic front-running through self-key withholding cannot be completely solved without threshold encryption. Current mitigations include top-of-block fees and bundling, while further penalties may be explored for equivocating votes.

This leads to the third challenge: threshold encryption is not ready. In theory, threshold encryption could allow a committee to collectively decrypt transactions only after ordering is fixed, without relying on a single key publisher. That would be a stronger design.

But Ethereum’s requirements are demanding. A suitable system would need to support post-quantum security, low setup costs, scalable committee sizes, and bulk decryption. Current research has not yet delivered a scheme that satisfies all of these constraints.

This is why LUCID should be understood as a practical near-term design rather than the final form of encrypted mempools forever. It may not solve every theoretical problem, but it could deliver meaningful protection earlier than waiting for threshold encryption to mature.

The fourth challenge is cross-layer complexity. LUCID touches both the execution layer and consensus layer. It also affects wallets, JSON-RPC APIs, Engine API communication, client testing, block-building infrastructure, and validator behavior. This makes it more complex than a narrowly scoped execution-layer change.

The fifth challenge is scheduling. Hegota already has multiple candidate areas, including FOCIL, validator improvements, attestation batching, and deposit or withdrawal-related changes. Ethereum developers will need to decide whether LUCID is mature enough for Hegota, whether it should be developed alongside Hegota, or whether it belongs in a later fork.

This is where EtherWorld’s earlier argument in Hegotá Should Complete the Holy Trinity of Censorship Resistance becomes relevant. If Hegota ships only inclusion guarantees, Ethereum improves censorship resistance but leaves transaction visibility largely unchanged. If it ships inclusion guarantees alongside encrypted mempools, it moves closer to system-level defense.

Why Hegota Matters

Glamsterdam is focused heavily on performance, execution improvements, and protocol cleanup. Hegota, by contrast, increasingly appears to be where Ethereum developers can address the fairness of transaction inclusion itself. That includes who gets included, when they get included, and whether their transaction can be exploited before execution.

This makes Hegota important for several groups.

1. For users, encrypted mempools could reduce the risk of being sandwiched or front-run.
2. For DeFi traders, it could improve execution quality. 3. For validators, FOCIL and related changes may clarify inclusion responsibilities.
3. For builders, it may reduce the ability to extract value from privileged visibility.

For Ethereum as a whole, it strengthens the claim that the network is a neutral settlement layer. The bigger vision can be understood as a three-part model:

1. First: Inclusion guarantees. FOCIL makes it harder for builders to exclude valid transactions.
2. Second: Pre-execution privacy. LUCID makes it harder for builders and searchers to exploit transaction contents before ordering.
3. Third: Trust-minimized decryption. Future threshold encryption could eventually remove remaining key-publisher trust assumptions.

This is the “holy trinity” framing: inclusion, concealment, and trust-minimized reveal. Ethereum may not be able to complete all three immediately, but the direction is clear.

The most realistic path may be incremental. FOCIL could remain the core Hegota headliner while LUCID continues maturing through specs, APIs, tests, devnets, and client implementations. If enough progress happens quickly, encrypted mempools could become part of the Hegota discussion more formally. If not, Hegota may still set the foundation for a later encrypted mempool upgrade.

The network is no longer only asking how to process more transactions. It is asking how to process transactions more fairly. That shift matters because Ethereum’s long-term credibility depends not only on throughput but also on neutrality.

To promote your Web3 articles, events, and projects, you may reach out anytime via EtherWorld PR for submissions and collaboration.

Related Articles

1. Hegotá Should Complete the Holy Trinity of Censorship Resistance
2. Ethereum Coalition Pushes for Encrypted Mempool in Upcoming Hardfork
3. Highlights from the All Core Developers Consensus (ACDC) Call #180
4. Ethereum ACD Monitor #1: Glamsterdam Devnet-6, Hegota Proposals, FOCIL Updates & EIP Activity
5. Highlights from the All Core Developers Execution (ACDE) Call #239

To follow blockchain news, track Ethereum protocol progress, and read our latest stories, subscribe to our weekly today.