Incorporating anti-censorship into the agreement: Who decides whether an Ethereum transaction can be on-chain?

Author: imToken

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

Many people's first reaction might be that it sounds like a politicized slogan, even carrying some anarchist connotations. However, for a settlement network like Ethereum that is open to global users, anti-censorship is not primarily 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 written into a block for a long time, and the status in the wallet remains "Pending." Meanwhile, other transactions with similar or even lower fees are continuously being added to the blockchain.

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 added to the blockchain, then it has no essential difference from traditional financial systems.

Therefore, 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 very critical 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 the wallet, this transaction typically first enters Ethereum's public transaction pool, also known as the mempool, which is more like a waiting area containing a large number of transactions that have not yet been written into a block.

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

The problem arises at this stage.

After Ethereum upgraded to the PoS (Proof of Stake) mechanism, in order to prevent large staking pools from forming economic monopolies through MEV (Maximal Extractable Value), Ethereum introduced the PBS (Proposer-Builder Separation) system. Under this architecture, the processing flow of each Ethereum transaction is actually split 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 is well known, MEV strategies have become increasingly complex in recent years. If every ordinary validator were required to independently complete transaction sorting and block optimization, it would undoubtedly give large nodes with more funds, data, and technical capabilities an advantage.

Therefore, by assigning the complex task of block construction to professional Builders, ordinary validating nodes, even without advanced arbitrage capabilities, can participate in block proposals 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 example, currently over 90% of Ethereum blocks are produced by only a few professional Builders, and since these Builders usually have clear operational backgrounds, they are easily subject to external pressures from specific national or regional legal compliance (e.g., OFAC sanction lists), thus constituting a risk of centralization.

Because of this, once these mainstream Builders selectively filter out certain sensitive contracts (such as Tornado Cash) or transactions from specific addresses, these transactions may fall into a prolonged state of being unable to be packaged, even facing the risk of being "silently banned."

In summary, from the perspective of ordinary users, 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.

Thus, the "anti-censorship" discussed 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 it an 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 a few Builders, Ethereum will once again face new risks of centralized monopoly.

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

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

Taking a bus station as an example, 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," and 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 solely based on their preferences.

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

FOCIL and FairFIL are developed along these two directions.

1. FOCIL: No longer allowing a single Proposer to unilaterally create the inclusion list

FOCIL (Fork-Choice Enforced Inclusion Lists) transfers the power to decide which transactions 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 mempool and submits their own local inclusion list.

This means that even if 99% of Builders and proposers in the network attempt to censor a transaction, as long as there is one honest node in the committee that includes the transaction in its list, that 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 will need to bypass multiple independent participants.

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

But having just a list is not enough; if Builders choose not to execute after receiving the list, the inclusion list becomes 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 a Builder is found 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 invalid by the protocol, and the Builder will incur significant costs for block production failure.

2. FairFIL: Not only filling gaps but also ensuring omissions can be verified

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 certain censorship behaviors 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, verifiable reference rules to determine which transactions in the public transaction pool meet the conditions for entering the current block under normal circumstances. If certain transactions that were originally qualified to enter the block according to the reference rules are ultimately not processed, Builders will need to publicly list them in FairFIL;
• Subsequently, validators will check whether this list is complete. If Builders clearly omitted qualifying transactions but did not include them in the list, this behavior may be discovered and affect whether validating nodes support that block;
• Finally, valid transactions that enter 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 continue to 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 through the introduction of tiered economic penalties, Builders that continuously censor transactions will face the risk of being deprived of the entire block reward and even having their staking deposits confiscated.

This is also the direction in which Ethereum's anti-censorship mechanisms are gradually deepening, aiming to establish a more realistic constraint. Even if a few participants have censorship intentions, it is difficult to control transaction entry in the long term; even if someone intentionally omits transactions, they must leave traces and pay increasingly high costs for continued censorship.

3. What does this mean for ordinary users?

For ordinary users who transfer funds, exchange, or use DeFi through wallets every day, these underlying mechanisms, even if implemented in the future, do not require changing existing operational habits.

Users will still fill in the amount in the wallet, confirm Gas, complete the signature, and then wait for the transaction to be added to the blockchain. However, at the invisible protocol level, the logic of whether a transaction can enter a block may undergo significant changes.

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 the choice of a single Builder: 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 rights to include transactions and the rights to order transactions may gradually separate: Builders can still use professional algorithms to arrange transaction order and increase block revenue, and can still compete around arbitrage and liquidation, but their power to decide "who is qualified to enter the market" will be limited;

Looking further, 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 remain neutral. Validating nodes will check blocks 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 vaguely display "Pending," but may further inform users whether it has entered the inclusion list, whether it has obtained the obligation of inclusion in subsequent blocks, and whether the continued wait is due to insufficient Gas, the transaction has expired, or there was an anomaly in the block construction process.

However, the anti-censorship mechanism does not mean that every transaction will succeed immediately.

Transactions with insufficient balance, nonce conflicts, low Gas, or expired contract execution conditions may still fail to enter a block. When the network is congested and block space is insufficient, users will still need to wait for confirmation through fee competition.

But it primarily improves the situation where a transaction that is valid, reasonably priced, and has already propagated 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 EIP-7805 corresponding to FOCIL 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 that 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 Ethereum's 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 be subject to 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 FOCIL, which jointly constrains Builders through distributed committees, and then to FairFIL, which requires omission behaviors 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, moving from a value declaration to a concrete implementation.

It is worth looking forward to.