In the blockchain world, one term comes up often: censorship resistance.
At first glance, it may sound political, or even like a slogan tinged with anarchism. But for Ethereum, an open settlement network for users worldwide, censorship resistance is not primarily a political position. It is a concrete technical capability.
Imagine that you submit a transaction in your imToken wallet.
The signature is valid, your account has sufficient funds, and the gas fee is reasonable. Yet the transaction remains unconfirmed for a long time, with your wallet continuing to show it as “Pending.” Meanwhile, other transactions paying similar or even lower fees continue to be included in blocks.
At that point, the question becomes: Who actually gets to decide whether a transaction is included in a block?
After all, if Ethereum ultimately depends on a handful of centralized participants to decide which transactions can be included, there would be little fundamental difference between Ethereum and a traditional financial system.
This is why Ethereum has been exploring censorship-resistance mechanisms such as FOCIL and FairFIL. They are attempts to answer a question that sounds simple but is critical to the network’s design:
How can Ethereum ensure that every transaction that complies with protocol rules has a fair opportunity to be included in a block?
1. Where Does Censorship Come From?
To understand why Ethereum needs these mechanisms, we first need to look at what happens after a transaction is sent from your wallet.
When a user signs and broadcasts a transaction, it typically first enters Ethereum’s public transaction pool, commonly known as the mempool. Think of the mempool as a waiting area containing large numbers of transactions that have not yet been included in a block.
But entering the waiting area does not mean the transaction is already on-chain. Someone still needs to select transactions from the mempool, determine their ordering, assemble them into a complete block, and submit that block to the network for confirmation.
This is where the problem begins.
After Ethereum transitioned to proof of stake (PoS), it introduced the proposer-builder separation (PBS) model in part to reduce the risk that large staking pools could use MEV (maximal extractable value) to reinforce their economic dominance. Under this architecture, the block production process is effectively split between two roles:
- Builder: collects transactions, determines their ordering, identifies arbitrage and liquidation opportunities, and constructs a block designed to maximize revenue.
- Proposer: selects one of the candidate blocks submitted by builders and proposes it to the network.
This separation of responsibilities has clear practical advantages.
MEV strategies have become increasingly sophisticated in recent years. If every ordinary validator were expected to independently optimize transaction ordering and block construction, large operators with greater access to capital, data, infrastructure, and technical expertise would gain a significant advantage.
By leaving complex block construction to specialized builders, ordinary validators can still propose blocks and earn rewards without having to develop advanced MEV capabilities themselves. This helps reduce the centralizing pressure MEV could otherwise place on Ethereum staking.
But the model has also created another problem: block construction has become highly concentrated.
Today, more than 90% of Ethereum blocks are produced by only a small number of professional builders. Because many of these builders are identifiable businesses operating in specific jurisdictions, they may also face external compliance pressure arising from laws and sanctions regimes, including those administered by the U.S. Office of Foreign Assets Control (OFAC). This concentration creates a real centralization risk.
If several dominant builders decide to selectively filter transactions involving certain sensitive contracts, such as Tornado Cash, or particular addresses, those transactions may be delayed for a long time, or effectively censored.
From an everyday user’s perspective, Ethereum is an open network that anyone can connect to, transfer assets through, and use to interact with smart contracts. At the protocol level, however, broadcasting a transaction is only the first step. For the transaction to actually take effect, it still needs to be selected, ordered, and included in a block by a block builder.
This is why Ethereum’s discussion of “censorship resistance” is not merely a broad debate about politics, regulation, or sanctions. At its core, it is a very specific technical question:
If a transaction complies with protocol rules, can the network ensure that it has a fair opportunity to be included in a block within a reasonable period of time?
2. From FOCIL to FairFIL: How Ethereum Is Limiting Block Builders
At this point, the underlying problem is clear.
Builders can make block construction more efficient. But if the power to determine transaction inclusion remains concentrated among a small number of builders over the long term, Ethereum risks creating a new form of centralized control.
To address this, Ethereum researchers have proposed a mechanism known as Inclusion Lists.
The name may sound abstract, but the basic idea is straightforward.
Builders can continue constructing blocks, but they should not have unilateral control over which transactions get included. Validators participating in Ethereum staking should also retain some authority to identify transactions that must be included, provided they satisfy the relevant protocol conditions.
Think of a block as a bus with a limited number of seats.
The builder gets to decide how most passengers line up and where they sit, using more efficient arrangements to maximize the block’s overall revenue. But validators can also submit a list of “passengers who must be allowed to board.”
As long as those transactions remain valid, offer a reasonable fee, and there is sufficient space in the block, the builder should not be able to keep excluding them indefinitely simply because it prefers not to include them.
That still leaves two important questions:
Who should create the Inclusion List?
And what happens if someone deliberately leaves an eligible transaction off the list?
FOCIL and FairFIL approach these two problems from different directions.
1. FOCIL: No Longer Letting a Single Proposer Control the Inclusion List
FOCIL, or Fork-Choice Enforced Inclusion Lists, shifts the power to require transaction inclusion away from a single proposer and distributes it across a committee of validators.
During each block-production cycle, the network randomly selects a group of validators to form a temporary Inclusion List committee.
Each committee member independently observes its local view of the network mempool and submits its own Inclusion List.
This means that even if 99% of builders and proposers attempted to censor a particular transaction, a single honest committee member could still place that transaction on an Inclusion List and bring it under protocol-level inclusion requirements. To keep censoring the transaction, an adversary would then have to overcome multiple independent participants rather than a single decision-maker.
This is one of FOCIL’s key strengths: the mechanism does not require every committee member to remain neutral.
But producing an Inclusion List is not enough.
If a builder could simply receive the list and choose to ignore it, the list would amount to little more than a recommendation.
FOCIL therefore adds a second layer of enforcement through Ethereum’s fork-choice rule.
Validators responsible for attesting to blocks check whether the builder has complied with the committee’s Inclusion List requirements. If the builder violates those requirements, attesters can refuse to support the block.
As a result, a block that violates the relevant Inclusion List requirements would be rejected by the network’s fork-choice process and fail to become canonical.
For the builder, this creates a substantial economic cost: the block it constructed may ultimately fail to gain network support.
2. FairFIL: Not Just Filling Gaps, but Making Omissions Verifiable
If FOCIL uses consensus rules to constrain censorship, FairFIL, or Fair Forward Inclusion Lists, goes a step further by introducing accountability and economic consequences that make prolonged censorship far more expensive and difficult to sustain.
The idea is simple in principle:
If a transaction does not make it into a block, there should be, wherever possible, a publicly verifiable record explaining that omission.
In practice, builders may need a brief window to optimize transaction ordering and pursue MEV opportunities. FairFIL allows some flexibility within defined constraints. But if a builder attempts to carry censorship over into the next block, the protocol can immediately trigger its accountability mechanism.
The mechanism can be understood in three broad steps.
First, the protocol establishes a set of public, verifiable reference rules for determining which transactions in the public mempool would normally qualify for inclusion in the current block. If a transaction that should have qualified under those rules is ultimately not included, the builder must publicly add it to the FairFIL.
Second, validators check whether that disclosure is complete. If a builder omitted a qualifying transaction from the block and also failed to disclose it, the omission may be detected and could affect whether validators support that block.
Third, valid transactions added to the FairFIL become priority inclusion obligations for subsequent blocks. The next builder can still decide exactly where those transactions appear within the block, but it cannot continue pretending they do not exist.
If the same transaction continues to be omitted, the relevant block may lose validator support, potentially causing the builder to forfeit the revenue from an entire block.
In other words, FairFIL’s “accountability” relies on escalating economic penalties. Builders that persistently censor transactions could risk forfeiting an entire block reward and may even face penalties on staked collateral, making sustained censorship increasingly expensive.
This reflects the direction in which Ethereum’s censorship-resistance research is evolving: toward a more practical system of constraints.
Even if a small number of participants want to censor transactions, maintaining control over transaction inclusion over time becomes increasingly difficult. Even if someone deliberately excludes a transaction, that decision should leave a trace—and continued censorship should come at an increasingly high cost.
3. What This Means for Everyday Users
For everyday users who transfer assets, swap tokens, or interact with DeFi through wallets, these underlying mechanisms would not require any change in how they use Ethereum if they are eventually deployed.
Users would still enter an amount in their wallet, review the gas fee, sign the transaction, and wait for confirmation. What may change significantly is the invisible protocol logic determining whether that transaction makes it into a block.
The most important improvement would be greater certainty around transaction inclusion.
First, a valid transaction would no longer depend entirely on the decision of a particular builder. Even if the current builder does not want to process it, other validators could place the transaction on an Inclusion List, creating a protocol-level requirement for it to be considered for inclusion.
Second, the power to determine whether a transaction can enter a block could gradually become separated from the power to determine where that transaction appears within the block.
Builders could continue using sophisticated algorithms to optimize transaction ordering and block revenue. They could still compete for arbitrage, liquidations, and other MEV opportunities. But their ability to decide who is allowed to “enter the market” in the first place would become more constrained.
More broadly, Ethereum’s credible neutrality could gradually shift from a value proposition that depends on participants’ commitments to neutrality into a set of rules automatically enforced by client software.
Users would not need to know which builder constructed the current block, nor would they need to trust every builder to voluntarily remain neutral. Validators would check blocks against the same protocol rules, making it difficult for blocks that violate transaction-inclusion obligations to gain network support.
In the future, wallets and block explorers could even use these mechanisms to provide more detailed transaction statuses.
Instead of displaying only a generic “Pending” state, a wallet might eventually be able to tell users whether a transaction has already appeared on an Inclusion List, whether a subsequent block is obligated to include it, and why it is still waiting.
Is the gas fee too low?
Has the transaction become invalid?
Or is something unusual happening during block construction?
Censorship resistance, however, does not mean that every transaction will immediately succeed.
Transactions can still fail to make it into a block because of insufficient balances, nonce conflicts, gas fees that are too low, or contract execution conditions that are no longer valid.
When the network is congested and block space is scarce, users may still need to compete through transaction fees and wait for confirmation.
These mechanisms are primarily designed to address a different problem:
A transaction that is valid, pays a reasonable fee, and has already propagated through the public mempool should not be delayed indefinitely simply because a small number of block builders choose not to include it.
As of August 2026, EIP-7805, which specifies FOCIL, remains in Draft status.
However, it has already been selected by Ethereum core developers as a consensus-layer Headliner for the Hegotá upgrade and has reached the Scheduled for Inclusion stage. This means client teams have agreed to move forward with implementation work and development-network testing around the proposal, although a final mainnet activation date has not yet been determined.
FairFIL remains at a much earlier stage.
For now, it is primarily a research proposal published in July 2026. Whether it will eventually become part of Ethereum’s roadmap will depend on broader discussion, implementation work, and security validation.
Final Thoughts
Ethereum cannot guarantee that every builder, validator, and infrastructure operator will remain neutral forever.
Participants may face regulatory pressure. They may act in their own economic interests. They may also respond to external incentives.
A truly resilient decentralized network cannot be built on the ideal assumption that everyone will always do the right thing.
Real censorship resistance means that even if some participants attempt to interfere with transactions, others can still break that control.
It means that even when someone chooses to deviate from neutrality, the protocol can make that behavior visible, expensive, and difficult to sustain.
From the original idea of Inclusion Lists, to FOCIL distributing constraints across a committee of validators, and then to FairFIL making transaction omissions publicly verifiable, Ethereum is gradually moving from simply allowing anyone to submit a transaction toward ensuring that everyone’s transaction has a fair opportunity to be seen.
From this perspective, Ethereum is trying to take censorship resistance from a statement of values and, step by step, write that commitment into the protocol itself.
That is worth watching.