Ethereum FOCIL Upgrade In-Depth Analysis: How Is Censorship Resistance Directly Embedded into the Consensus Layer?

The Ethereum block construction ecosystem has undergone a significant process of centralization over the past two years. Data shows that currently more than 80% of Ethereum blocks are produced by a small number of block builders, and block-building rights are gradually concentrating among higher-level participants who can extract maximum value by optimizing transaction ordering. This centralization trend is driven by MEV economics—builders gain excess profits through complex ordering algorithms, creating natural barriers to entry. Meanwhile, although the proposer-builder separation mechanism is intended to prevent centralization at the staking layer, it inadvertently creates a new set of centralization risks at the block construction layer. Vitalik Buterin has clearly stated that while ePBS can prevent block-building rights from concentrating in a small number of staking pools, block construction itself may still concentrate among a small number of higher-level participants due to specialization and MEV maximization.

The core issue brought about by this structural shift is the explicitization of censorship risk. When a small number of block builders control the vast majority of block production, whether transactions get included is no longer a natural outcome of an open market, but may instead be influenced by builders’ subjective preferences. For DeFi protocols, stablecoin issuers, and Layer 2 networks that rely on Ethereum as a neutral settlement layer, this uncertainty directly challenges Ethereum’s core promise of being a trusted, neutral platform.

How does FOCIL solve the transaction censorship problem at the protocol layer?

FOCIL (Fork-Choice Enforced Inclusion Lists, i.e., EIP-7805) transfers the transaction mandatory inclusion right from block builders to a decentralized validator committee through a set of precise protocol-layer mechanisms. Its core process consists of three steps: in each Ethereum slot, the system randomly selects 16 validators to form a temporary committee; each committee member, based on their own independent observation of the mempool, publishes a local inclusion list indicating which valid transactions they believe should be included in the block; after aggregating all lists, the block proposer constructs a candidate block, and validators will vote against any block that does not include transactions from the valid lists.

The key to this mechanism is that anti-censorship is directly encoded into the fork-choice rules. If a block ignores valid transactions in the committee lists—even if those transactions come from sanctioned addresses—the network will fork starting from that block, forcing it out of the canonical chain. Compared with earlier inclusion-list approaches, the random committee mechanism significantly reduces the risk of bribery and extortion attacks, because an attacker cannot predict which validators will be selected and cannot bribe 16 randomly chosen validators at once.

Another important feature of FOCIL is native support for the privacy ecosystem. The committee mechanism naturally fits account abstraction and privacy protocols. Users can send transactions via smart accounts, and privacy-protocol users also need not worry about being identified and intercepted by censors. This lays the technical groundwork for Ethereum’s evolution toward a more “cypherpunk”-style direction.

Where is the cost of protocol-level anti-censorship reflected?

Encoding anti-censorship into the consensus layer does not come without costs. The first major criticism of FOCIL comes from the legal-risk dimension. Critics point out that forcing validators to include all valid transactions—including transactions sent to OFAC-sanctioned addresses—could expose validators located within the United States to the risk of regulatory sanctions. The founder of the privacy pool, Ameen Soleimani, previously noted that after Tornado Cash was added to the sanctions list, about 90% of validators chose not to include transactions related to that privacy protocol. If those validators were forced to include such transactions, it could trigger a direct conflict at the regulatory level.

At the protocol complexity level, FOCIL must complete multiple stages in every slot, including random committee selection, inclusion-list generation, list aggregation, and vote verification. Inevitably, this increases the computational burden on the consensus layer. Developers are optimizing proof size and Gas efficiency to support future “GigaGas”-level scalability. In addition, FOCIL was previously excluded from the Glamsterdam upgrade, partly due to the development community’s concerns about its complexity and potential latency risks.

From the perspective of priority trade-offs, in March 2026 Ethereum core developers voted to make FOCIL the only “headline” feature of the Hegota upgrade, while lowering the priority of framework transaction proposal(s) supported by Vitalik Buterin. Client developers stated that adding a second headline could lead to delays for Hegota, and the complexity of the framework transactions makes it difficult to commit to a fixed delivery timeline. This decision clearly reflects the value ordering within the Ethereum development community: between anti-censorship and user experience, the former is placed in the priority position.

What does this upgrade mean for Ethereum’s ecosystem landscape?

Implementing FOCIL will reshape Ethereum’s ecosystem landscape across multiple dimensions. In the economic layer, it changes the logic of MEV profit distribution. Previously, block builders earned MEV returns through transaction ordering and selective inclusion. FOCIL forces builders to include transactions from the committee lists, limiting builders’ ability to selectively exclude transactions from the mempool, thereby weakening builders’ market bargaining power. This change may push the MEV ecosystem to evolve in a more decentralized direction.

In the trust model layer, FOCIL brings Ethereum’s anti-censorship capability down from the level of social consensus to the protocol rules layer. Previously, Ethereum’s anti-censorship relied on validators’ moral commitments and community oversight—a soft constraint. FOCIL turns that into a hard requirement in fork rules, and no validator can technically bypass it. This greatly increases Ethereum’s credibility as a “most neutral block space.”

From a competitive landscape perspective, FOCIL’s deployment will further strengthen Ethereum’s differentiated advantage in anti-censorship—its core dimension. Compared with competing networks that pursue higher throughput or lower fees, Ethereum is building an uncensorable neutrality moat through protocol-layer design. Tim Clancy, a Layer 2 developer, once called FOCIL “the most important proposal for Ethereum” because it delivers the core capabilities Ethereum must have in order to continue fulfilling its mission.

Where does FOCIL sit in Ethereum’s 2026 roadmap?

The Ethereum Foundation’s published 2026 protocol roadmap clearly lays out three main tracks: “scaling,” “improving user experience,” and “strengthening L1.” FOCIL belongs to the “strengthening L1” track, alongside post-quantum cryptography research, focusing on security and anti-censorship. Ethereum’s 2026 plan includes two named upgrades: Glamsterdam in the first half of the year, introducing ePBS (in-protocol proposer-builder separation) and block-level access lists; Hegota in the second half of the year, where FOCIL will appear as a core feature.

Developers have confirmed that FOCIL is the Hegota upgrade’s “headline” feature, and most Ethereum client teams have already completed prototype implementations. At the core developers meeting on March 26, the community rejected the proposal to list the framework transaction(s) as a second headline, downgrading it to a non-mandatory function of “consideration for inclusion.” This decision ensures that FOCIL’s delivery timeline will not be delayed by other complex proposals, but it also means that account abstraction and user-experience improvements will, in the short term, give way to a development strategy prioritizing anti-censorship.

In terms of future evolution, the community is already discussing enhanced versions of FOCIL, such as EIP-8046 (FOCIL with transaction ordering, i.e., FOCILR). This approach provides stronger anti-censorship guarantees by not allowing builders to bypass inclusion lists that would otherwise be skipped when the block is full during propagation. In addition, the synergy between FOCIL and framework transactions has also been widely discussed—Vitalik Buterin believes that FOCIL will, together with framework transactions, drive the adoption of privacy protocols.

What potential risks and limitations does FOCIL’s implementation face?

Although FOCIL provides strong technical guarantees for anti-censorship, its implementation still faces multiple risks and limitations. Regulatory risk is the most direct external challenge. FOCIL forces validators to include all valid transactions, meaning validators operating in the United States may be required to process transactions from sanctioned addresses, exposing them to legal consequences. This risk could prompt some validators to exit the Ethereum network, or cause staking services to migrate to jurisdictions with more permissive regulatory environments—ironically resulting in centralization of validator geographic distribution.

The increase in protocol complexity may introduce unforeseen vulnerabilities. FOCIL involves multiple new components, such as random committee selection, list generation and verification, and modifications to fork-choice rules. Any design flaw in any step could be exploited by attackers. For example, committee members could submit false or dishonest inclusion lists, and attackers might attempt to manipulate the committee election process. While the random selection mechanism is designed with anti-manipulation considerations, security after real-world deployment still needs time to be validated.

From the perspective of economic incentives, FOCIL’s impact on the MEV ecosystem has bidirectional uncertainty. On one hand, it limits builders’ selective exclusion power; on the other hand, it may give rise to new ways of extracting MEV—such as obtaining additional value by manipulating the ordering of transactions within inclusion lists. EIP-8046 proposed by the community is a direct response to this issue, but any adjustment to economic mechanisms will require repeated iteration to work smoothly in practice.

Additionally, FOCIL cannot solve all forms of censorship. It ensures transactions are included in blocks, but it does not guarantee that transactions are processed in a timely manner or ordered appropriately. Builders can still indirectly affect user experience through Gas pricing strategies or transaction ordering methods. Anti-censorship is a multi-layer systems engineering effort: FOCIL addresses the fundamental question of “whether to be included,” while “how to be included” still requires subsequent upgrades and further optimization.

Summary

The deterministic inclusion of Ethereum FOCIL (EIP-7805) marks a paradigm shift in blockchain anti-censorship design. It upgrades anti-censorship from a soft promise at the social consensus layer to a hard enforcement mechanism in fork rules. Through the random validator committee mechanism, it transfers the transaction inclusion right from a small number of block builders to decentralized network validators. While this upgrade strengthens Ethereum’s core positioning as a most neutral block space, it also brings multidimensional challenges such as validator legal risk, protocol complexity, and the reconfiguration of the MEV ecosystem. As a core feature of the Hegota upgrade in the second half of 2026, FOCIL’s rollout will enable Ethereum to establish structural advantages that are difficult to replicate in the anti-censorship dimension. However, its long-term effectiveness will still depend on the regulatory environment, community consensus, and the effectiveness of risk-mitigation mechanisms in subsequent iterations.

FAQ

What is the full name of FOCIL? What is its relationship to EIP-7805?

FOCIL’s full name is Fork-Choice Enforced Inclusion Lists, which is Ethereum Improvement Proposal EIP-7805. Both refer to the same set of anti-censorship mechanisms. FOCIL is the popular name for the mechanism, and EIP-7805 is its official number within the Ethereum improvement proposal framework.

How does FOCIL differ from ePBS?

ePBS (in-protocol proposer-builder separation) aims to prevent block proposal power from concentrating in a small number of staking pools by outsourcing block construction to an open market, reducing the risk of centralization at the staking layer. FOCIL, on the other hand, focuses on preventing block builders from censoring transactions. By using a forced inclusion list from a validator committee, it ensures that all valid transactions are eventually included in blocks. The two address different layers of centralization problems, and both are part of the “strengthening L1” track in Ethereum’s 2026 roadmap.

Will FOCIL delay Ethereum’s upgrade schedule?

Developers have confirmed that FOCIL will be the only headline feature of the Hegota upgrade and have lowered the priority of the framework transaction proposal(s) for this reason. This decision is exactly to ensure the upgrade is not delayed due to feature overload. Most clients have already completed prototype implementations, and development progress is moving forward according to plan.

Will FOCIL affect ordinary users’ transaction experience?

For ordinary users, the direct impact of FOCIL is positive—users do not need to trust any single builder, and the probability that their transactions get censored is significantly reduced. However, in terms of Gas costs and block processing time, the additional computational steps introduced by FOCIL may cause some efficiency loss. The exact impact depends on the network load after formal mainnet launch.

Does FOCIL force all validators to participate?

In each slot, FOCIL randomly selects 16 validators to form a temporary committee, and not all validators are required to generate inclusion lists in every slot. This design keeps the system decentralized while controlling the computational burden on each validator. Validators’ core responsibility is to vote against blocks that ignore valid transactions on the committee lists, rather than actively generating the lists.