#PBS architecture upgrade#Censorship risk easing
Ethereum’s Anti-Censorship Evolution: FOCIL, FairFIL, and the End of Builder Monopoly
WooFun2026-08-06 22:46
Key Takeaways
Ethereum addresses builder centralization via FOCIL and FairFIL to ensure transaction inclusion. These mechanisms shift power from centralized builders to distributed validators, making censorship economically unviable and technically verifiable for globa
Woofun AI reports that Ethereum is actively dismantling the centralized control over transaction inclusion, a critical vulnerability exposed when users of wallets like imToken find their valid transactions stuck in 'pending' status despite adequate Gas fees. This phenomenon highlights a fundamental tension in the network: while Ethereum markets itself as an open settlement layer, the actual authority to decide which transactions enter a block has increasingly concentrated in the hands of a few centralized participants.
The core problem is no longer just about political ideology or anarchist slogans, but a specific technical capability—ensuring that any transaction meeting protocol rules has a fair, verifiable chance of being processed, regardless of external pressures or internal biases. If the network relies on a small group to curate blocks, it functionally mirrors traditional financial systems, undermining its foundational promise of neutrality.
The origin of this censorship risk lies in the architectural evolution of Ethereum’s consensus and execution layers. After the transition to Proof of Stake (PoS), the network introduced Proposer-Builder Separation (PBS) to mitigate the economic monopolies formed by Maximal Extractable Value (MEV). In this model, the mempool—the public waiting area for signed transactions—is no longer processed by a single entity. Instead, the workflow is split between two distinct roles: the Builder, who collects transactions, optimizes their order for maximum profit through arbitrage and liquidation, and constructs the block; and the Proposer, who selects one of these candidate blocks and submits it to the network. This division was designed to democratize block production, allowing ordinary validators to earn rewards without needing complex MEV extraction capabilities.
However, this structural change inadvertently created a new bottleneck: the Builders.
The risk stems from the extreme concentration of power among these professional Builders. Currently, over 90% of Ethereum blocks are produced by a handful of specialized entities. Because these Builders often operate with clear corporate structures and legal jurisdictions, they are highly susceptible to regulatory pressure, such as compliance with OFAC sanction lists. This creates a scenario where sensitive contracts, like Tornado Cash, or transactions from specific addresses can be silently banned. These transactions do not fail with an error message; instead, they languish in the mempool indefinitely, effectively censored by the economic and legal incentives of the Builders. For the average user, the network appears open, but the underlying mechanics reveal a gatekeeping system where the right to be included is granted by a centralized few, not guaranteed by the protocol.
To counter this, Ethereum researchers have proposed the concept of Inclusion Lists, a mechanism designed to redistribute power back to the validating nodes. The logic is straightforward: while Builders remain responsible for constructing efficient blocks, they cannot unilaterally decide the fate of every transaction. Validating nodes, which participate in staking, retain the authority to submit a 'must-board list' of transactions that must be included. Using a bus station analogy, the Builder decides the seating arrangement to maximize revenue, but the validators can mandate that certain passengers must board if the bus has space and the fare is paid. This ensures that even if a Builder prefers to exclude a transaction due to regulatory fears or competitive reasons, the protocol enforces its inclusion, provided the transaction is valid and fees are reasonable.
This shifts the dynamic from voluntary compliance to enforced obligation.
Woofun AI data shows that FOCIL, or Fork-Choice Enforced Inclusion Lists, operationalizes this concept by distributing the creation of these lists across a committee rather than relying on a single proposer. In each block production cycle, the network randomly selects a group of validating nodes to form a temporary committee. Each member independently observes the mempool and submits their own local inclusion list. This design ensures that even if 99% of Builders and proposers attempt to censor a transaction, a single honest node in the committee can trigger its inclusion.
To enforce this, FOCIL introduces a Fork-Choice Rule that acts as a hard constraint. All nodes in the network must verify that the blocks submitted by Builders adhere to the committee’s integrated inclusion list. If a Builder violates this list, the entire network refuses to vote for the block, rendering it invalid. This makes censorship not just a moral failing, but a technical error that results in immediate financial loss for the Builder.
FairFIL, or Fair Forward Inclusion Lists, complements FOCIL by introducing economic accountability and verifiable records for omissions. While FOCIL focuses on immediate inclusion, FairFIL addresses the scenario where a Builder might delay or omit transactions under the guise of optimization. It requires that any decision to exclude a qualifying transaction from a block must leave a public, verifiable record. The protocol establishes reference rules to determine which transactions in the mempool should normally enter the block. If a Builder omits these, they must list them in FairFIL. Validators then check the completeness of this list. If a Builder hides omissions, they risk losing validator support for the block.
Furthermore, transactions listed in FairFIL become prioritized tasks for subsequent blocks, ensuring they cannot be ignored indefinitely. This creates a trail of accountability that makes sustained censorship economically unsustainable.
The economic penalties under FairFIL are severe and tiered. If a Builder continuously omits transactions that should have been included, they face the risk of losing the entire block reward. In more extreme cases, repeated violations could lead to the confiscation of their staking deposits. This transforms censorship from a low-risk operational choice into a high-cost liability. The mechanism also allows for some flexibility, recognizing that Builders need a short buffer period to optimize MEV strategies.
However, if censorship behaviors extend beyond this buffer into subsequent blocks, the protocol initiates strict accountability procedures. This ensures that while Builders can still compete on efficiency and profit, they cannot abuse their position to suppress specific transactions without facing immediate and escalating financial consequences.
For ordinary users, these changes do not require altering their operational habits. They will still input amounts, confirm Gas fees, and sign transactions in their wallets.
However, the certainty of transaction inclusion will significantly improve. Instead of a vague 'Pending' status, block explorers and wallets may soon display detailed information on whether a transaction has entered an inclusion list, whether it has an obligation for future inclusion, or if the delay is due to insufficient Gas, nonce conflicts, or fee competition. This transparency demystifies the process, allowing users to understand why a transaction is delayed. It separates the right to order transactions, which remains with Builders for efficiency, from the right to include them, which is now protected by protocol rules.
The implementation timeline for these mechanisms is progressing steadily. As of August 2026, EIP-7805, which corresponds to FOCIL, is in Draft status but has been selected as a consensus layer Headliner for the Hegotá upgrade. It has entered the Scheduled for Inclusion phase, meaning client teams have agreed to advance its implementation and conduct network testing, although a specific mainnet launch date remains unfinalized. FairFIL is at an earlier stage, currently a research proposal released in July 2026. Its integration into the Ethereum roadmap requires further discussion, implementation, and security verification. These timelines reflect the careful, iterative approach Ethereum takes to modifying its core consensus rules, ensuring stability while addressing critical decentralization risks.
This evolution marks a philosophical shift from trusted neutrality to protocol enforcement. Ethereum can no longer rely on the ideal assumption that all participants will act neutrally. Builders and validators may face regulatory pressure, pursue self-interest, or accept external incentives. A resilient decentralized network must assume that some participants will attempt to interfere. True anti-censorship is achieved not by trusting individuals, but by making censorship visible, costly, and technically difficult to sustain. By moving from value declarations to concrete implementation through FOCIL and FairFIL, Ethereum is embedding its commitment to openness into the code itself, ensuring that the network remains accessible and fair for all users, regardless of external pressures.
Comments
No comments yet.