Ethereum Explores FOCIL and FairFIL to Enhance Anti-Censorship Mechanisms

In the world of blockchain, we often hear the term: "censorship-resistant."

Many people’s first reaction might be to hear it as a politically charged slogan, even one with anarchist overtones, but for Ethereum—a settlement network open to users worldwide—censorship resistance is not first and foremost a political stance, but a very specific technical capability.

Imagine you initiate a transaction in your imToken wallet.

The signature is correct, the account balance is sufficient, and the gas fee is not low, but the transaction has not been included in a block for a long time—the wallet status remains stuck at "Pending," while other transactions with similar or even lower fees continue to be confirmed on-chain.

The question then becomes: who has the authority to decide whether a transaction can be included in a block? After all, if Ethereum ultimately still relies on a few centralized participants to determine which transactions can be added to the chain, then there is no fundamental difference between it and traditional financial systems.

Therefore, in recent years, Ethereum has been exploring a series of censorship-resistant mechanisms, such as FOCIL and FairFIL, in an attempt to answer a question that appears simple but is in fact critically important: How can we ensure that any transaction complying with protocol rules has a fair chance of being included in a block?

To understand why Ethereum needs these mechanisms, first consider what happens after a transaction is sent from a wallet.

When a user signs and sends a transaction from their wallet, the transaction typically enters Ethereum’s public transaction pool, known as the mempool—a holding area containing numerous transactions waiting to be included in a block.

However, entering the mempool does not mean the transaction has been confirmed on the blockchain; it still requires someone to select transactions, determine their order, assemble them into a complete block, and submit it to the network for confirmation.

The issue arises precisely at this stage.

After Ethereum upgraded to the PoS (Proof of Stake) mechanism, to prevent large staking pools from gaining economic monopolies through MEV (Maximal Extractable Value), Ethereum introduced the PBS (Proposer-Builder Separation) system. Under this architecture, the processing of each Ethereum transaction is divided between two distinct roles:

• Builder: Responsible for collecting transactions, ordering them, identifying arbitrage and liquidation opportunities, and constructing a block with maximum possible profit;
• Proposer: Responsible for selecting one candidate block from those submitted by Builders and proposing it to the network;

This division of labor offers very practical benefits.

It is well known that in recent years, MEV strategies have become increasingly complex; requiring every ordinary validator to independently handle transaction ordering and block optimization would inevitably give an advantage to large nodes with more capital, data, and technical capabilities.

Therefore, by delegating the complex block-building tasks to professional builders, ordinary validation nodes—even without advanced arbitrage capabilities—can still participate in block proposal and earn corresponding rewards, thereby mitigating the impact of MEV on the decentralization of staking.

However, it has also inadvertently led to excessive centralization of block building rights. For instance, over 90% of Ethereum blocks on the network are currently produced by only a few professional builders. Since these builders typically have well-defined business entities, they are highly susceptible to external pressures from legal and regulatory requirements in specific countries or regions—such as OFAC sanctions lists—thereby posing a real risk of centralization.

Precisely because of this, once these major builders selectively filter out transactions from certain sensitive contracts (such as Tornado Cash) or specific addresses, those transactions may become stuck in a prolonged state of being unpacked and could even face the risk of "implicit banning."

In summary, to the average user, Ethereum appears as an open network where anyone can connect, transfer funds, and interact with smart contracts. However, from the perspective of protocol operation, sending a transaction is only the first step—whether the transaction actually takes effect depends on whether it is selected, ordered, and included in a block by a block builder.

Therefore, the "censorship resistance" discussed in Ethereum is not merely a broad concept related to politics, regulation, or sanctions; it is first and foremost a very specific technical issue:

When a transaction meets the protocol rules, can the network guarantee it an opportunity to be included in a block within a reasonable time?

At this point, the issue is clear: while builders can improve block construction efficiency, if the authority to include transactions remains concentrated in the hands of a few builders over the long term, Ethereum risks re-establishing a new centralized monopoly.

To this end, Ethereum researchers proposed Inclusion Lists, commonly known as "inclusion lists."

The name may sound abstract, but its core logic is straightforward—the Builder still constructs blocks, but cannot unilaterally decide which transactions to include; normally participating Ethereum staking validators must retain some authority to designate certain transactions that must be processed.

Using a bus stop as an example, you can think of a block as a bus ride with a limited number of seats.

The Builder determines how most passengers line up and where they sit, thereby increasing the train’s overall revenue through more efficient arrangements; however, validation nodes may submit a “mandatory boarding list”—as long as the transactions on the list remain valid, are willing to pay reasonable fees, and there is sufficient space in the block, the Builder cannot indefinitely exclude them based solely on personal preference.

However, determining who should create the list and how to handle cases where someone intentionally omits transactions remain two issues that need to be addressed.

FOCIL and FairFIL are precisely developed along these two directions.

1. FOCIL: No longer allow a single Proposer to propose a block alone

Fork-Choice Enforced Inclusion Lists (FECIL) transfer the power to determine which transactions must be included from individual proposers to a committee of multiple validators.

Within each block production cycle, the network randomly selects a group of validation nodes to form a temporary committee. Each member of the committee independently monitors the network mempool and submits their own local inclusion list.

This means that even if 99% of builders and proposers on the network attempt to censor a transaction, as long as one honest node in the committee includes the transaction in the list, the transaction has a chance to be included in the protocol. If censors wish to continue excluding it, they must no longer just bypass a single participant, but must simultaneously circumvent multiple independent participants.

So its advantage is that you don't need to trust every member of the committee to remain neutral.

But a list alone is not enough; if the Builder receives the list and still chooses not to act, the list becomes a non-binding suggestion.

Therefore, FOCIL added a second layer of design, introducing a fork-choice rule as a strict constraint, requiring all network nodes responsible for voting and validation to thoroughly check blocks submitted by Builders. If a Builder is found to have violated the inclusion list integrated by the committee, the entire network will immediately refuse to vote for that block.

This means that non-compliant blocks will be instantly deemed invalid by the protocol, and the Builder will incur significant block production failure penalties.

2. FairFIL: Not only fix gaps, but also ensure that omissions are verifiable

If FOCIL enforces censorship resistance through consensus rules, FairFIL (Fair Forward Inclusion Lists) and accountability mechanisms make censorship economically prohibitive and unsustainable.

In short, it calls for more stringent requirements, such as maintaining publicly verifiable records explaining why a transaction did not enter a block.

In actual network operation, Builders may require a brief buffer period to optimize transaction ordering and MEV arbitrage. FairFIL allows Builders to make flexible adjustments under specific constraints, but if a Builder attempts to extend any form of censorship to the next block, the protocol immediately initiates an accountability process.

Its general logic can be understood in three steps.

• First, the protocol establishes a set of public, verifiable rules to determine which transactions in the public mempool are eligible to be included in the current block under normal circumstances. If any transactions that meet these reference rules are ultimately not processed, the Builder must publicly list them in FairFIL;
• Subsequently, validators will check whether this list is complete; if a Builder omits eligible transactions from the list, such behavior may be detected and influence whether validators support the block.
• Finally, valid transactions in FairFIL become priority tasks that must be processed in subsequent blocks; the next Builder may still determine their exact placement within the block but cannot continue to ignore them.

If a transaction is repeatedly omitted, the associated block may lose validator support, and the builder could consequently lose the entire block reward.

In other words, FairFIL’s emphasis on “accountability” involves subjecting builders who continuously review transactions to tiered economic penalties, risking the loss of the entire block reward and even the forfeiture of their staked deposit.

This is also the direction in which Ethereum’s censorship resistance mechanism is evolving, aiming to establish more realistic constraints that make it difficult for a small group of participants to maintain long-term control over transaction entry; even if someone intentionally omits transactions, they must leave traces and pay an increasingly high cost for sustained censorship.

For everyday users who transfer, exchange, or use DeFi through their wallets daily, these underlying mechanisms will not require changes to their existing habits, even if implemented in the future.

Users still enter the amount in their wallet, confirm the gas fee, complete the signature, and wait for the transaction to be confirmed on-chain; however, beneath the surface, the logic determining whether a transaction can be included in a block may have changed significantly.

What it truly improves is the certainty of the transaction inclusion process.

• First, a transaction that complies with the rules will no longer rely entirely on a specific Builder’s selection: even if the current Builder is unwilling to process it, other validators can establish a protocol-level inclusion requirement for it through the inclusion list;
• Second, the right to include transactions and the right to order them may gradually separate: Builders can still leverage specialized algorithms to arrange transaction sequences and increase block rewards, and can still compete around arbitrage and liquidations, but their power to determine "who is eligible to enter the market" will be restricted;

Looking further, Ethereum’s trustless neutrality may gradually evolve from a value proposition based on participants’ commitments to protocol rules automatically enforced by clients.

Users do not need to know which builder constructed the current block, nor do they need to individually trust that these builders will actively remain neutral; validation nodes will check blocks according to the same set of rules, making it difficult for blocks that violate inclusion obligations to gain network acceptance.

In the future, wallets and block explorers may even provide more detailed transaction statuses based on this.

A transaction is no longer shown merely as "pending" but may provide users with more detailed information, such as whether it has entered the inclusion list, whether it has received commitment for inclusion in subsequent blocks, and whether the continued wait is due to insufficient gas, an expired transaction, or an issue during block construction.

However, censorship resistance does not mean that every transaction will succeed immediately.

Transactions with insufficient balance, nonce conflicts, insufficient gas, or expired contract execution conditions may still fail to be included in a block. During network congestion or when block space is limited, users must still wait for confirmation by competing with higher fees.

However, it primarily improves a transaction that was originally valid, had reasonable fees, and had already been propagated to the public mempool, and should not be indefinitely delayed due to the subjective choices of a minority of block builders.

As of August 2026, EIP-7805 for FOCIL remains in Draft status; however, it has been selected by Ethereum core developers as the consensus layer headliner for the Hegotá upgrade and has entered the Scheduled for Inclusion phase, indicating that client teams have agreed to proceed with implementation and network testing around it, though the exact mainnet deployment date has not yet been finalized.

FairFIL is even earlier-stage and currently represents a research proposal scheduled for release in July 2026. Whether it will be integrated into Ethereum’s roadmap will require further broad discussion, implementation, and security validation.

Objectively speaking, Ethereum cannot guarantee that every builder, validator, and infrastructure operator will remain neutral forever.

Participants may be subject to regulatory pressure, pursue their own interests, or respond to external incentives; a truly resilient decentralized network cannot be built on the idealistic assumption that everyone will always do the right thing.

True censorship resistance means that even if some participants attempt to interfere with transactions, others can still break free from such control; even if someone chooses to deviate from neutrality, the protocol ensures that such behavior becomes visible, costly, and unsustainable.

From the initial inclusion list, to FOCIL, where builders are jointly constrained by a distributed committee, to FairFIL, which requires that omissions be publicly verifiable—from allowing anyone to send transactions, to ensuring that everyone’s transactions have a chance to be seen.

From this perspective, Ethereum is indeed gradually turning this promise from a value statement into code within the protocol itself.

Looking forward to it.