What Ethereum’s FOCIL Upgrade Will Actually Guarantee Against Censorship

Ethereum’s planned FOCIL upgrade is meant to change a critical fact about transaction inclusion: a dominant builder, relay, or proposer should no longer be able to quietly keep a valid public transaction offchain forever. But the guarantee is narrower, more conditional, and more useful than the slogan suggests. FOCIL does not promise instant execution, private transaction protection, successful application outcomes, or immunity from a network level attack. It creates a protocol path through which randomly selected validators can make censorship costly and chain selection can punish blocks that ignore eligible transactions. For applications, that is a meaningful upgrade, provided they understand exactly where the guarantee begins and ends.

Ethereum developers have scheduled Fork Choice Enforced Inclusion Lists, or FOCIL, as the consensus layer headline feature for the Hegota upgrade, currently targeted for late 2026. The proposal, tracked as EIP-7805, was deferred from the earlier Glamsterdam upgrade but has now moved from a research topic into the protocol roadmap.

The big question is not whether FOCIL sounds good. It is whether a user facing a hostile transaction pipeline will actually get a transaction onto Ethereum.

Imagine a stablecoin transfer from a wallet that an influential builder, relay, compliance provider, or validator operator does not want to process. Today, the user may have technical alternatives, such as sending through a different RPC endpoint, raising the fee, broadcasting more widely, or building a block locally. Yet none of those workarounds is a protocol guarantee. If enough of the block production stack filters the transaction, the user can remain stuck.

FOCIL is designed to make that sort of coordinated filtering less durable. It does so by distributing part of the inclusion power to a randomly selected set of validators, then using Ethereum’s fork choice process to favor blocks that honor their inclusion requests.

That is a substantial change in who gets a say over a block’s contents. It is not a promise that every transaction lands in the next block, or even that every broadcast path becomes censorship resistant. The distinction matters for wallet teams, DeFi protocols, payment applications, rollups, and companies designing transaction infrastructure.

The current problem: one block, many gatekeepers

Ethereum’s post Merge block production path is not a simple user to validator pipeline. A transaction can travel through multiple intermediaries before it becomes part of the canonical chain.

A user signs a transaction and sends it through a wallet, RPC provider, private relay, public gossip network, intent solver, or other routing system. A specialized builder collects transactions and constructs a candidate block, often optimizing the order for maximal extractable value, or MEV. A relay may sit between the builder and proposer. The slot’s proposer chooses a block and publishes it. Other validators then attest to the chain head.

That specialization has benefits. Builders can optimize blocks, compete on value, and reduce the need for every validator to operate sophisticated infrastructure. But it also concentrates discretion. A small number of large block builders, relays, or integrated transaction pipelines can become the practical place where a transaction is accepted, delayed, reordered, or filtered.

Ethereum researchers have framed FOCIL as a response to that concentration, particularly as builder markets become more specialized and vertically integrated around MEV extraction.

The key issue is not that every intermediary must be malicious. It is that the protocol currently gives users no direct, enforceable route around coordinated offchain filters. A transaction can be technically valid, economically valuable, and visible to the sender, yet still have no guaranteed path into a block if the entities with block building power refuse it.

FOCIL changes that by introducing a second source of transaction inclusion pressure. Builders can still build blocks. Proposers can still propose. But an auxiliary committee of validators can flag eligible transactions that must be respected if a block is to remain competitive in Ethereum’s fork choice.

What FOCIL adds: auxiliary includers with protocol leverage

The simple version of FOCIL is this: for each slot, Ethereum randomly selects a small committee of validators. The initial design described publicly uses 16 randomly selected attesters. Their job is not to build the entire block. Their job is to identify transactions they have seen that satisfy the inclusion rules and place them on inclusion lists.

Those validators are often described as auxiliary includers. They are not replacing the proposer. They are not becoming 16 separate block builders. They are supplying a protocol recognized statement: this transaction was available, eligible for inclusion, and should not be silently discarded by the primary block production market.

The proposer still publishes a block. The builder may still do nearly all of the complex transaction ordering and MEV optimization. But if the block omits transactions that satisfy the FOCIL requirements, Ethereum’s fork choice rule can treat that block or its descendants unfavorably.

The enforcement mechanism is the important part. An inclusion list that is merely advisory would not solve much. Builders could ignore it, and proposers could keep selecting the highest paying censored block. FOCIL’s purpose is to attach chain selection consequences to that decision.

The broad result is that a hostile builder cannot achieve lasting censorship just by refusing to include a transaction. If an honest selected includer has received the transaction through the public transaction network and places it on an eligible list, the block production pipeline must account for it.

That should not be read as “any one validator can force any transaction into the next block.” FOCIL is not a unilateral veto held by a single staker. It is a committee based protocol mechanism with eligibility rules, list construction rules, propagation assumptions, and capacity limits.

The validators that matter are the particular randomly selected auxiliary includers for the relevant slot or inclusion window. A validator outside that set may gossip the transaction, attest to blocks, or operate a builder, but it does not gain the special FOCIL inclusion role for that period. Conversely, a selected includer cannot force a transaction it never received, cannot compel a malformed transaction, and cannot make an execution layer invalid transaction valid.

The randomness is essential. If the same well known entities always controlled inclusion, a censor could simply pressure or exclude them. A rotating committee means the censor must either persuade, control, or disable the relevant inclusion participants repeatedly.

The actual guarantee: bounded inclusion, not immediate execution

The most accurate description of FOCIL’s goal is bounded inclusion for eligible public transactions.

Ethereum researchers describe the proposal as aiming to guarantee that transactions valid under Ethereum’s rules are included onchain within a bounded time frame. The Block’s reporting has also characterized the guarantee as applying to valid public mempool transactions within a bounded number of slots.

Each phrase carries weight.

Bounded means the protocol is trying to limit how long censorship can persist. It does not mean the transaction is included at the instant it is signed. The transaction must be received, propagated, noticed by an eligible includer, listed, and processed through the normal slot and fork choice machinery.

Inclusion means the transaction appears in a canonical Ethereum block. It does not promise that the transaction produces the business result the user expected. A swap can be included and still revert because its slippage limit is no longer met. A mint can be included after an allocation is exhausted. A liquidation transaction can be included after the position has already been closed. An onchain action can land too late for an application’s real time objective.

Eligible means the transaction must satisfy the protocol’s rules at the time the inclusion obligation is evaluated. A transaction with an invalid signature, insufficient funds, a stale nonce, an inadequate fee, or a conflict with another transaction cannot be rescued by FOCIL. Nor can FOCIL make room for unlimited transaction demand when Ethereum blockspace is constrained.

Public means the transaction needs to reach the network path visible to FOCIL includers. This is arguably the design’s most consequential application level condition.

A private transaction delivered only to a trusted relay, solver, market maker, or builder can be excellent for protecting a trade from frontrunning. But if that private recipient withholds it, the FOCIL committee may never learn the transaction exists. The mechanism cannot list what it cannot see.

Vitalik Buterin has highlighted the public mempool connection directly, arguing that native account abstraction could allow transactions from smart wallets and privacy tools to reach a public mempool and be received directly by a FOCIL includer, without relying on wrappers, public broadcasters, or other transaction intermediaries.

That creates an important product design tradeoff. Public propagation can improve censorship resistance, while private submission can reduce MEV exposure. FOCIL strengthens the former. It does not, on its own, solve the latter.

A concrete censorship scenario

Consider a user trying to move USDC from a self custodial wallet to an exchange. The user has a valid signature, enough ETH for gas, enough USDC, and an appropriate nonce. The user broadcasts the transaction across public Ethereum peers.

Now assume a major block builder does not want to include the transaction. Perhaps the builder is following a restrictive compliance policy. Perhaps it is protecting a commercial relationship. Perhaps a cartel of builders sees no value in including ordinary user flow unless it comes through preferred routes.

Without FOCIL, the builder can ignore the transaction. If the same builders dominate a large enough share of blocks and the remaining producers also filter or fail to see the transaction, the user’s practical options can narrow dramatically.

With FOCIL, the transaction can reach one or more of the randomly selected includers. An honest includer that sees an eligible transaction can place it on an inclusion list. A later block that omits the transaction when it is required to include it faces fork choice consequences.

The builder then has a choice. It can include the transaction, perhaps sacrificing a small amount of flexibility in block construction. Or it can keep censoring and build a block that other validators have reason to reject as the chain head.

The mechanism changes the economics. Censorship ceases to be a passive omission made invisible inside an offchain builder market. It becomes a protocol relevant act that risks producing a block with weaker chain support.

The chart does not mean 16 validators are guaranteed to be honest, online, or aware of every transaction. It shows why the design is different. The ability to put a transaction onto the protocol’s enforcement path is no longer concentrated solely in the actor that chooses the block.

What must be true for the guarantee to hold

FOCIL is strongest under a specific set of network, protocol, and economic assumptions.

First, the transaction must be widely propagated. A user who submits only to one private endpoint has not created an independent path to the committee. Wallets and applications that want FOCIL protection need public broadcast strategies that reliably reach multiple network peers and potential includers.

Second, at least some relevant FOCIL participants must be honest and available. They need to see the transaction, recognize that it meets inclusion conditions, publish the appropriate list data, and remain connected enough for the rest of the network to receive it. A network partition, targeted denial of service attack, or coordinated isolation of includers can degrade the guarantee.

Third, the transaction must remain executable. Ethereum transaction validity is state dependent. If another transaction consumes the sender’s nonce first, drains the account, changes a contract’s state, or makes a trade’s slippage condition fail, the original transaction may no longer execute in the way the user intended.

Fourth, the chain must retain its broader honest consensus assumptions. FOCIL is not a remedy for an adversary that can control Ethereum’s consensus process at a scale sufficient to dictate chain history, prevent honest blocks from propagating, or sustain a deep network level attack. It is an anti censorship tool inside Ethereum’s normal security model, not a replacement for that model.

Fifth, transaction demand must remain within the protocol’s capacity and fee constraints. Ethereum cannot offer unconditional inclusion to an unlimited number of transactions in finite blockspace. Any implementation needs rules that limit list size, determine which transactions can claim protected capacity, and prevent an attacker from filling inclusion lists with low value spam.

This is where implementation choices become central. A useful inclusion guarantee must avoid creating an easy griefing tool. If any party can force arbitrary transactions into every block at minimal cost, a spammer could use FOCIL to crowd out ordinary transactions or raise networking costs for validators. If the requirements are too narrow, a censor can exploit the exclusions.

The eventual balance will involve caps, fee rules, transaction eligibility criteria, and carefully defined treatment of conflicts. Those details determine the practical meaning of “bounded.”

The paths where a censored transaction can still fail

FOCIL does not eliminate every failure mode. It makes some forms of censorship harder, while leaving several transaction path dependencies intact.

The clearest gap is private order flow. A private relay can offer users protection from public mempool extraction. It can also become a single point of censorship. If the transaction remains visible only to that relay and the relay refuses to forward it, FOCIL cannot force inclusion because the selected includers never received the payload.

This is not a small edge case. High value DeFi flow often avoids the public mempool precisely because public visibility creates opportunities for sandwiching, frontrunning, and other harmful MEV strategies. Ethereum’s own discussion has connected FOCIL with future encrypted mempool designs because encrypted transactions could potentially provide a path to both discoverability for inclusion and reduced information leakage before execution.

A second gap is blob transactions. The current FOCIL proposal does not support blobs, according to reporting on the Hegota discussion. That matters for rollups, which use blobs to publish data to Ethereum. A rollup may gain better guarantees for ordinary execution transactions while its blob based data publication route remains outside FOCIL’s initial protection.

A third gap is transaction replacement and nonce conflict. If a user submits transaction A with nonce 12, then submits transaction B with the same nonce and a higher fee, the network cannot execute both. An application cannot call the eventual selection censorship resistance if the user’s own transaction strategy creates ambiguity. Wallets will need to make replacement behavior clear.

A fourth is application level timing. A transaction included within a protocol bound might still be commercially late. For an auction, arbitrage, liquidation, NFT mint, token launch, or high frequency trading strategy, the next few slots can be the entire opportunity. FOCIL is better understood as an anti exclusion guarantee, not a latency service or priority execution product.

A fifth is reorganization risk. Inclusion in a block is not identical to irreversible finality. Ethereum can experience short reorgs as competing blocks appear. FOCIL changes fork choice incentives around inclusion, but applications must still apply their normal confirmation and finality policies before treating a transaction as settled.

Why builders and validators should care about the cost

FOCIL is not free protocol hardening. It adds data propagation, validation work, client logic, and new edge cases to Ethereum’s consensus layer.

Validators and clients need to receive inclusion lists, verify their contents, track whether a block has satisfied applicable obligations, and apply fork choice rules consistently. That can increase bandwidth demands, especially if transaction lists are large or frequently duplicated across participants. It can also complicate validator operations, client testing, and incident response.

The proposal’s critics have also raised legal concerns. If a protocol requires validators to participate in a mechanism that can force inclusion of transactions some operators would otherwise avoid, validators may face more visible tension between neutral protocol participation and external compliance expectations. The Block reported that these legal and complexity concerns were part of the controversy surrounding FOCIL’s path to Hegota.

There is also an MEV question. Builders earn value partly because they can select and order transactions precisely. Mandatory inclusion reduces some discretion. That is intentional when the discretion enables censorship, but it can also complicate builder optimization and create new strategic behavior around which transactions are listed, how they are ordered, and how scarce protected capacity is priced.

The upside is that FOCIL may let validators contribute to censorship resistance without requiring each of them to become a local block builder or abandon the economics of proposer builder separation. Researchers have presented that separation of roles as one of the proposal’s central advantages.

For Ethereum, this is the broader strategic wager: keep specialized block production because it can be efficient, but prevent specialization from becoming permissioned control over who gets to use the chain.

How applications should evaluate their own censorship resistance

Application teams should avoid saying they are censorship resistant merely because their smart contracts are deployed on Ethereum. The relevant question is whether users have an end to end transaction path that can reach Ethereum’s protected inclusion mechanism.

A useful review starts with five questions.

1. Does the application support a public broadcast route?
If the only submission path is a proprietary API, private relay, hosted wallet, or solver network, FOCIL may not protect users when that intermediary refuses the request.

2. Can users bypass the application’s preferred infrastructure?
A strong design lets users take a signed transaction and broadcast it independently. This is especially important for withdrawals, redemptions, governance actions, and other operations where the application operator could have an incentive to delay users.

3. Does the transaction remain valid if delayed?
A protected transaction that expires quickly, has a narrow slippage limit, or depends on a volatile state may be included but still fail the user’s goal. Applications should distinguish “must be included” from “must succeed.”

4. Does the application depend on blobs or offchain data publication?
If its critical route relies on blob transactions, sequencer submission, a bridge operator, or an oracle update, FOCIL coverage may apply only to one portion of the system.

5. Is privacy being traded for inclusion assurance?
A public transaction path reveals intent. For a user making a sensitive trade, the better architecture may require optional paths: a public route that can access FOCIL protection and a private or encrypted route that minimizes MEV, with candid disclosure that the latter has different censorship assumptions.

This is where wallet design becomes particularly important. A wallet should be able to explain whether a transaction was publicly propagated, sent exclusively to a private intermediary, listed by an eligible includer, included in a block, and confirmed. Those are different states, and users should not have to infer them from a spinning interface.

The real significance of Hegota

FOCIL’s significance is not that Ethereum will suddenly guarantee every user a perfect transaction experience. It will not.

Its significance is that Ethereum is trying to move censorship resistance from an aspiration into a protocol enforceable property of the transaction pipeline. The change says that builder market concentration may be acceptable as an efficiency layer only if it cannot become a durable veto over valid public user transactions.

The initial version will leave open work on private flow, encrypted mempools, blob support, spam resistance, implementation parameters, and the exact economics of mandatory inclusion. Those open questions are not flaws in the idea. They are the difficult engineering work required to make the promise credible.

For applications, the practical conclusion is clear. FOCIL can give meaningful protection against a builder, relay, proposer, or cartel refusing a valid public transaction, provided the transaction reaches an honest selected includer, remains eligible, fits the protocol’s capacity rules, and Ethereum’s normal network and consensus assumptions hold.

That is not instant execution. It is not private execution. It is not guaranteed commercial success.

It is something more foundational: a user who can reach Ethereum’s public transaction network should have a protocol level route that is harder for powerful intermediaries to close.