Ethereum is testing ways to write censorship resistance into the protocol itself, with one practical question at the center of the debate: when a transaction meets the rules, who decides whether it gets into a block?
The article, written by imToken, argues that for Ethereum as a settlement network open to global users, censorship resistance is not mainly a political slogan. It is a technical property. A user can send a transaction from a wallet, sign it correctly, keep enough balance in the account, and even attach a gas fee that is not low, yet still watch it sit in pending status while other transactions with similar or lower fees land on-chain.
Where censorship enters the transaction path
To explain why Ethereum is discussing these mechanisms, the article walks through what happens after a wallet sends a transaction. The transaction usually enters Ethereum’s public mempool, a waiting area that holds transfers not yet written into a block. That step alone does not put the transaction on-chain. Someone still has to pick transactions from the mempool, decide their order, assemble a block, and hand it to the network for confirmation.
That is where the problem appears.
After Ethereum moved to proof-of-stake, the network adopted proposer-builder separation, or PBS, to reduce the chance that large staking pools would turn MEV, or maximal extractable value, into an economic monopoly. Under PBS, transaction handling is split between two roles:
- Builders, which collect transactions, arrange ordering, search for arbitrage and liquidation opportunities, and construct blocks designed to maximize value.
- Proposers, which choose one candidate block submitted by builders and send it to the network.
The article says this split has an obvious benefit. MEV strategies have become increasingly complex, and forcing every ordinary validator to optimize transaction ordering on its own would favor large operators with more capital, data, and technical capacity. Letting specialized builders handle block construction allows regular validators to keep proposing blocks and earning rewards even without advanced MEV capabilities, easing the pressure MEV can place on staking decentralization.
But the same structure introduces another effect: block building becomes concentrated. According to the article, more than 90% of Ethereum blocks across the network are produced by only a small group of professional builders. Because those builders usually operate through identifiable business entities, they can be exposed to legal and compliance pressure from particular countries or regions, including pressure linked to the OFAC sanctions list. In the article’s framing, that has already become a centralization risk.
If a few major builders choose to filter transactions tied to sensitive contracts such as Tornado Cash, or tied to specific addresses, those transactions can end up waiting for a long time without being packed into a block. The article describes this as a risk of quiet exclusion.
From a user’s point of view, Ethereum is an open network where anyone can connect, transfer value, and call smart contracts. From the protocol’s point of view, sending a transaction is only the first step. Whether it actually takes effect depends on whether some block builder selects it, orders it, and writes it into a block.
That is why Ethereum’s censorship-resistance debate is framed here not as a broad political argument but as a narrow protocol question: can the network guarantee that a transaction which satisfies the rules gets a fair chance to enter a block within a reasonable time?
Inclusion lists as a limit on builder discretion
From there, the article turns to inclusion lists, a line of research meant to stop builders from holding complete control over transaction admission. Builders would still make blocks, but they would no longer be the only parties deciding which transactions stay out. Validators staking on Ethereum would retain a defined amount of authority and could identify transactions that must be handled.
The article compares a block to a bus with limited seats. Builders still decide how most passengers line up and where they sit, using that flexibility to improve the economics of the trip. Validators, though, can also hand over a list of passengers who must be allowed on board. If the listed transactions remain valid, are willing to pay reasonable fees, and there is enough block space, the builder cannot keep rejecting them based only on its own preferences.
That still leaves two unresolved questions: who should create the list, and what happens when someone deliberately leaves transactions off it. FOCIL and FairFIL are presented as two answers built around those two points.
FOCIL moves inclusion power to a validator committee
FOCIL, short for Fork-Choice Enforced Inclusion Lists, shifts the power to determine which transactions must be included away from a single proposer and into a validator committee made up of multiple parties.
During each block production cycle, the network would randomly select a temporary committee of validators. Each committee member independently watches the mempool and submits a local inclusion list. The article gives a stark example of the intended effect: even if 99% of builders and proposers across the network tried to censor a transaction, that transaction could still enter the protocol’s required set as long as one honest committee member placed it on the list. A censor would then need to bypass multiple independent participants rather than influence only one actor.
That is the appeal of FOCIL in the article’s telling. It does not require every member of the committee to stay neutral.
A list on its own, however, would not be enough if builders could simply ignore it. FOCIL adds a second layer by tying inclusion duties to fork choice. Validators responsible for attesting to blocks would check whether builders followed the committee’s merged inclusion list. If a builder submitted a block that violated that list, the network would refuse to vote for it.
In practical terms, the article says, the protocol would treat such a block as invalid, and the builder would pay a steep price through a failed block.
FairFIL focuses on public accountability for omissions
Where FOCIL leans on consensus rules to stop censorship directly, FairFIL, or Fair Forward Inclusion Lists, takes a different path. The article describes it as an accountability system that tries to make censorship costly and hard to sustain by forcing omissions into the open.
Builders may need a very short buffer to optimize ordering and MEV opportunities, and FairFIL allows some flexibility under defined constraints. But if a builder tries to carry exclusion behavior into the next block, the protocol would start an accountability process.
The article breaks the logic into three steps.
- First, the protocol would define a public and verifiable reference rule set to determine which mempool transactions are eligible for inclusion in the current block under normal conditions. If a transaction should have qualified under those rules but was not processed, the builder would need to place it on a public FairFIL list.
- Second, validators would check whether that list is complete. If the builder omitted an eligible transaction and also failed to disclose it on the list, that omission could be detected and could affect validator support for the block.
- Third, valid transactions that enter FairFIL would become priority items for later blocks. The next builder could still choose their exact placement inside the block, but could no longer pretend not to have seen them.
If the same transaction keeps getting skipped, the article says the related block could lose validator support, and the builder could lose the revenue for the whole block. In that sense, FairFIL’s accountability model relies on escalating economic penalties. A builder that keeps censoring transactions could face the loss of full block rewards and even the possibility of stake-related penalties.
What this would change for users
For ordinary users sending transfers, making swaps, or using DeFi through a wallet, the article says these mechanisms would not require a change in day-to-day behavior if they are adopted. Users would still enter an amount, confirm gas, sign the transaction, and wait. The change would happen under the surface, in the protocol logic that governs entry into a block.
The first change would be more certainty around inclusion. A valid transaction would no longer depend entirely on one builder’s choice. Even if the current builder does not want to handle it, other validators could create a protocol-level inclusion requirement through an inclusion list.
The second change is a cleaner separation between inclusion rights and ordering rights. Builders could still use specialized algorithms to arrange transaction order and improve block revenue. They could still compete around arbitrage and liquidations. What would be narrowed is their ability to decide who gets through the door at all.
The article also links this to Ethereum’s claim of credible neutrality. In its view, neutrality could move from something users hope participants will honor into something clients enforce automatically. Users would not need to know which builder produced a given block or place trust in each builder separately. Validators would be checking blocks against the same rules, making it harder for blocks that ignore inclusion duties to gain acceptance.
That could eventually feed into wallet and explorer interfaces. Instead of showing only a generic pending label, a wallet might tell a user whether a transaction has entered an inclusion list, whether later blocks are obligated to include it, and whether the delay comes from low gas, an invalidated transaction, or an issue in the block construction pipeline.
These mechanisms do not guarantee instant success
The article is explicit on the limits. Anti-censorship rules would not make every transaction succeed immediately. Transactions can still fail to enter a block because of insufficient balance, nonce conflicts, gas fees that are too low, or smart contract execution conditions that are no longer valid. When the network is congested and block space is tight, users would still compete on fees and wait for confirmation.
The intended improvement is narrower: a transaction that is already valid, reasonably priced, and propagated to the public mempool should not be delayed indefinitely because a small set of block builders chooses not to include it.
Status of the proposals
On implementation progress, the article says that as of August 2026, EIP-7805, the proposal associated with FOCIL, remains in Draft status. Even so, Ethereum core developers have selected it as the consensus-layer headliner for the Hegotá upgrade and moved it into Scheduled for Inclusion. In the article’s description, that means client teams have agreed to move ahead with implementation work and development-network testing, though the final mainnet timeline has not been set.
FairFIL is at an earlier stage. The article describes it as a research proposal released in July 2026. Whether it will enter Ethereum’s roadmap still depends on broader discussion, implementation work, and security validation.
From a value claim to protocol rules
The article closes with a broader point. Ethereum cannot guarantee that every builder, validator, and infrastructure operator will stay neutral forever. Participants may face regulatory pressure, pursue their own interests, or respond to outside incentives. A resilient decentralized network cannot rest on the assumption that everyone will always do the right thing.
In that framing, real censorship resistance means something narrower and more mechanical. If some participants try to interfere with transactions, others should still be able to break that control. If someone departs from neutrality, the protocol should make that behavior visible, expensive, and difficult to sustain.
From the first inclusion-list ideas, to FOCIL’s distributed committee constraints on builders, to FairFIL’s demand that omissions be publicly verifiable, the direction described in the article is the same throughout: move from allowing anyone to send a transaction toward guaranteeing that anyone’s valid transaction can at least be seen by the system.
The original article also carries a disclaimer saying markets involve risk, investing should be approached with caution, and the piece does not constitute investment advice.