Incorporating Anti-Censorship into Protocols: Who Decides Whether an Ethereum Transaction Can Be Included on the Chain?

Protocol-level anti-censorship ensures that any transaction that meets the criteria cannot be excluded for an extended period based solely on the preferences of a few block builders.

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

Many people's first reaction might be that it sounds like a politically charged slogan, even with a hint of anarchism. However, for a settlement network like Ethereum that is open to global users, anti-censorship is primarily not a political stance but a very specific technical capability.

Imagine you initiate a transaction in your imToken wallet.

The signature is correct, your account balance is sufficient, and the gas fees are not low, yet the transaction is still not written into a block, and the status in your wallet remains "Pending," while other transactions with similar or even lower fees continue to be included on the chain.

At this point, the question becomes: who has the authority to decide whether a transaction can enter a block? After all, if Ethereum ultimately still requires a few centralized participants to decide which transactions can be included on the chain, then it bears no essential difference from traditional financial systems.

Thus, in recent years, Ethereum has been exploring a series of anti-censorship mechanisms such as FOCIL and FairFIL, attempting to answer a seemingly simple yet critically important question: how to ensure that any transaction that meets the protocol rules has a fair chance of entering a block?

1. Where Does "Censorship" Come From?

To understand why Ethereum needs these mechanisms, we first need to clarify what happens after a transaction is sent from a wallet.

When a user signs and sends a transaction in their wallet, it typically first enters Ethereum's public transaction pool, also known as the mempool, which is more like a waiting area filled with numerous transactions that have not yet been written into a block.

However, entering the waiting area does not mean the transaction has been included on the chain; someone still needs to select transactions from it, decide their order, form a complete block, and then submit it to the network for confirmation.

The problem arises at this stage.

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

• Builder: Responsible for collecting transactions, arranging their order, seeking arbitrage and liquidation opportunities, and constructing a block with the highest possible profit;
• Proposer: Responsible for selecting one candidate block submitted by the Builder and submitting it to the network;

This division of labor has very practical benefits.

As we all know, MEV strategies have become increasingly complex in recent years. If every ordinary validator were required to independently complete transaction ordering and block optimization, it would undoubtedly give larger nodes with more funds, data, and technical capabilities an advantage.

Therefore, by assigning the complex task of block construction to specialized Builders, ordinary validating nodes can still participate in block proposing and earn corresponding rewards, thereby mitigating the impact of MEV on staking decentralization.

However, it has inadvertently brought about another side effect: the excessive concentration of block construction rights. For instance, currently, over 90% of Ethereum blocks are produced by only a few specialized Builders, and since these Builders often have clear operational backgrounds, they are easily subject to external pressures from specific national or regional legal compliance (e.g., OFAC sanction lists), thus posing a risk of centralization.

Because of this, if these mainstream Builders selectively filter out certain sensitive contracts (like Tornado Cash) or transactions from specific addresses, those transactions may face long periods of being unable to be packaged, or even risk being "silently censored."

In summary, from an ordinary user's perspective, Ethereum is an open network that anyone can connect to, transfer funds, and call smart contracts. However, from the perspective of protocol operation, sending a transaction is just the first step; whether the transaction can truly take effect depends on whether it is selected, ordered, and written into a block by a block builder.

Therefore, the discussion of "anti-censorship" in Ethereum is not just a grand concept related to politics, regulation, or sanctions; it is primarily a very specific technical issue:

When a transaction meets the protocol rules, can the network guarantee that it has the opportunity to enter a block within a reasonable time?

2. From FOCIL to FairFIL: How Ethereum Limits Block Builders

At this point, the issue is clear: Builders can improve block construction efficiency, but if the rights to include transactions remain concentrated in the hands of a few Builders, Ethereum will once again face new risks of centralized monopolies.

To address this, Ethereum researchers proposed Inclusion Lists, commonly referred to as "inclusion lists."

This name may sound somewhat abstract, but its core logic is not complicated—Builders are still responsible for creating blocks but cannot unilaterally decide the fate of all transactions; normal validating nodes participating in Ethereum staking also need to retain some power to list transactions that must be processed.

Using a bus station as an analogy, a block can be understood as a bus with limited seating.

Builders decide how most passengers queue and where they sit, thereby improving the overall revenue of the trip through more efficient arrangements; however, validating nodes can also submit a "must-board list"—as long as the transactions on the list are still valid, willing to pay reasonable fees, and there is enough space in the block, Builders cannot continuously reject them based solely on their preferences.

However, who exactly creates an inclusion list, and what happens if someone intentionally omits transactions, are still two issues that need to be resolved.

FOCIL and FairFIL are precisely developed along these two directions.

1. FOCIL: No Longer Allowing a Single Proposer to Unilaterally Create Inclusion Lists

FOCIL (Fork-Choice Enforced Inclusion Lists) shifts the power to decide whether a transaction must be included from a single proposer to a "validator committee" composed of multiple parties.

During each block production cycle, the network randomly selects a group of validating nodes to form a temporary committee. Each member of the committee independently observes the network's mempool and submits their own local inclusion list.

This means that even if 99% of Builders and proposers in the entire network attempt to censor a transaction, as long as there is one honest node in the committee that includes that transaction in the list, the transaction has a chance to enter the protocol's constraints. If the censor wants to continue excluding it, they will no longer just affect one person but need to bypass multiple independent participants.

Thus, its advantage lies in not needing to trust that every member of the committee remains neutral.

However, just having a list is not enough; if Builders receive the list and still choose not to execute it, the inclusion list will become a non-binding suggestion.

Therefore, FOCIL adds a second layer of design, introducing a Fork-Choice Rule for hard constraints, requiring all nodes responsible for voting verification in the network to strictly check the blocks submitted by Builders. Once they discover that a Builder dares to violate the committee's integrated inclusion list, the entire network will directly refuse to vote for that block.

This means that the violating block will be instantly deemed an invalid block by the protocol, and the Builder will pay a significant cost for block production failure.

2. FairFIL: Not Only Filling Gaps but Also Making Omissions Verifiable

If FOCIL is a hard prohibition against censorship from the consensus rules, then FairFIL (Fair Forward Inclusion Lists) and the accountability mechanism make censorship behavior extremely costly and unsustainable from an economic perspective.

In simple terms, it proposes further requirements, such as why a transaction did not enter a block should leave a publicly verifiable record whenever possible.

In the actual operation of the network, Builders may need a very short buffer period to optimize transaction ordering and MEV arbitrage. FairFIL allows Builders to make flexible adjustments under specific constraints, but if Builders attempt to extend a certain censorship behavior to the next block, the protocol will immediately initiate accountability procedures.

Its general logic can be understood in three steps.

• First, the protocol will establish a set of public and verifiable reference rules to determine which transactions in the public transaction pool qualify to enter the current block under normal circumstances. If certain transactions that originally qualified according to the reference rules are ultimately not processed, the Builder must publicly list them in FairFIL;
• Subsequently, validators will check whether this list is complete. If the Builder clearly omitted qualifying transactions but did not include them in the list, such behavior may be detected and affect whether the validating nodes support that block;
• Finally, valid transactions entering FairFIL will become tasks that need to be prioritized in subsequent blocks. The next Builder can still arrange their specific positions in the block but cannot pretend not to see them;

If a transaction is continuously omitted, the related block may lose validator support, and the Builder may thus lose the entire block's rewards.
In other words, the "accountability" emphasized by FairFIL is actually **achieved through the introduction of tiered economic penalties, where Builders who continuously review transactions may face the risk of being deprived of the entire block reward and even having their staked deposits confiscated.**
This is also the direction in which Ethereum's anti-censorship mechanism is gradually deepening, aiming to establish a more realistic constraint. Even if a few participants have censorship intentions, it will be difficult to control the transaction entry in the long term; even if someone intentionally omits transactions, they will need to leave traces and pay increasingly higher costs for continuous censorship.
### What Does This Mean for Ordinary Users? --------------
For ordinary users who transfer, exchange, or use DeFi through wallets daily, these underlying mechanisms, even if implemented in the future, will not require changes to existing operational habits.
Users will still fill in amounts in their wallets, confirm Gas, complete signatures, and then wait for transactions to be on-chain. However, the logic of whether a transaction can enter a block may undergo significant changes at the invisible protocol level.
What it truly improves is the certainty of the transaction inclusion process.
* **First, a transaction that meets the rules will no longer completely depend on a specific Builder's choice:** Even if the current Builder is unwilling to process it, other validators can establish a protocol-level inclusion requirement through the inclusion list; * **Second, the rights to include transactions and to order transactions may gradually separate:** Builders can still use professional algorithms to arrange transaction order and increase block rewards, and they can still compete around arbitrage and liquidation, but their power to decide "who qualifies to enter the market" will be restricted;
Furthermore, Ethereum's trusted neutrality may gradually shift from a value proposition reliant on participant commitments to protocol rules automatically executed by clients.
Users do not need to know which Builder constructed the current block, nor do they need to trust that these Builders will actively maintain neutrality. Validation nodes will check the block according to the same set of rules, making it difficult for blocks that violate inclusion obligations to gain network recognition.
In the future, wallets and block explorers may even provide more detailed transaction statuses based on this.
A transaction will no longer just generically display "pending" but may further inform users whether it has entered the inclusion list, whether it has obtained the inclusion obligation for subsequent blocks, and whether the continued wait is due to insufficient Gas, the transaction already being invalid, or an anomaly in the block construction process.
However, the anti-censorship mechanism does not mean that every transaction can succeed immediately.
Transactions with insufficient balance, nonce conflicts, low Gas, or expired contract execution conditions may still fail to enter blocks. When the network is congested and block space is limited, users will still need to compete for fees to wait for confirmation.
But it primarily improves the situation where a transaction that is originally valid, reasonably priced, and has already spread to the public transaction pool should not be indefinitely delayed due to the subjective choices of a few block builders.
In terms of progress, as of August 2026, the FOCIL corresponding to EIP-7805 is still 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, meaning the client team has agreed to advance its implementation and develop network testing around it, but the specific mainnet launch time has not yet been finalized.
FairFIL is even earlier, currently mainly a research proposal released in July 2026. Whether it will enter the Ethereum roadmap in the future still requires broader discussion, implementation, and security verification.
### In Conclusion ----
Objectively speaking, Ethereum cannot guarantee that every Builder, validator, and infrastructure operator will always remain neutral.
Participants may face regulatory pressure, pursue their own interests, or accept external incentives. **A truly resilient decentralized network cannot be built on the ideal assumption that "everyone will do the right thing."**
True anti-censorship means that even if some participants attempt to interfere with transactions, other participants still have the ability to break this control; even if someone chooses to deviate from neutrality principles, the protocol can make such behavior visible, costly, and difficult to sustain.
From the initial inclusion list to the FOCIL that jointly constrains Builders by a distributed committee, and then to FairFIL, which requires omission behavior to be publicly verifiable, from allowing anyone to send transactions to ensuring that anyone's transactions have a chance to be seen.
From this perspective, Ethereum is indeed trying to write this commitment step by step into the protocol itself, rather than just a value declaration.
It is worth looking forward to.