Ethereum Researcher Proposes Adding FOCIL Censorship Resistance to the Hegota Upgrade

Jan 28, 2026

Ethereum Researcher Proposes Adding FOCIL Censorship Resistance to the Hegota Upgrade

On January 27, 2026, Ethereum researcher Thomas Thiery (aka “soispoke”) published a proposal positioning FOCIL as a potential “headliner” feature for the upcoming Hegota hard fork, framing it as a protocol-level step to strengthen Ethereum’s censorship resistance guarantees (Hegota headliner proposal thread). With Hegota widely discussed as Ethereum’s second major network upgrade in 2026, and broadly targeted for the second half of 2026, the timing of this proposal is notable as the community debates which changes deserve top priority in the next upgrade cycle.

This article explains what FOCIL is, why it matters now, what trade-offs it introduces, and what Ethereum users should watch as Hegota’s scope takes shape.

Why “censorship resistance” is back in focus in 2026

Censorship resistance is not an abstract ideology for blockchains—it’s a practical property: any valid transaction should be able to reach the chain in a predictable amount of time, even if powerful intermediaries would prefer otherwise.

In recent years, the Ethereum ecosystem has matured alongside:

Increasing reliance on specialized infrastructure (block builders, relays, RPC endpoints)
A more complex MEV supply chain
Heightened regulatory and compliance pressure on centralized operators
The continued growth of rollups and cross-chain bridging, which raises the value (and political sensitivity) of L1 settlement

Against that backdrop, proposals like FOCIL aim to harden Ethereum’s “credible neutrality” at the base layer—so inclusion isn’t merely “likely,” but systemically enforced.

What is FOCIL?

FOCIL stands for Fork-choice enforced Inclusion Lists and is currently specified as EIP-7805 (EIP-7805 on eips.ethereum.org).

At a high level, FOCIL is a protocol-layer transaction inclusion mechanism designed to ensure that any protocol-valid transaction gets included within a bounded timeframe, even in the presence of censorship pressure.

The core idea:

A committee of validators is selected to publish inclusion lists (sets of transactions they believe should be included).
The block proposer is expected to include transactions from these lists in the next block.
Fork choice / voting behavior is modified so that validators (attesters) only vote for blocks that satisfy the inclusion constraints, meaning blocks that ignore valid inclusion-list transactions are far less likely to become canonical.

This is the key distinction: FOCIL isn’t “please include these transactions.” It’s “if you don’t include them, the chain’s consensus participants will treat your block as non-competitive.”

For additional background and motivation from Ethereum researchers, see the Ethereum Foundation research write-up hosted by the Robust Incentives Group (FOCIL overview).

Why FOCIL is being discussed for Hegota specifically

In the Hegota headliner proposal, Thomas Thiery argues that FOCIL meaningfully improves Ethereum’s inclusion guarantees by letting multiple validators jointly enforce inclusion, rather than relying on a single proposer or a small set of professional builders (proposal thread).

Meanwhile, Ethereum core developers have been operating with a clearer, more frequent upgrade cadence, and public planning discussions around fork identity and timelines have continued in open forums such as All Core Devs – Execution call notes (ACDE #226 notes). In this environment, a “headliner” candidate like FOCIL benefits from:

Existing specification work (EIP-7805 is already drafted)
A concrete security goal that is easy to explain to users: timely inclusion
A direct connection to concerns about builder centralization and censorship

How FOCIL works (conceptually) without getting lost in the weeds

FOCIL introduces an additional consensus “constraint” around inclusion:

A small set of validators publishes inclusion lists for a given slot.
The next block should include those transactions (or prove they cannot be included due to validity or space constraints).
Validators then attest in a way that penalizes blocks that ignore includable transactions.

This is why sources often describe FOCIL as changing fork-choice behavior: it ties transaction inclusion to what the network considers the “best” chain, rather than treating inclusion as purely at the proposer/builder’s discretion.

If you want the full details—committee selection, propagation rules, equivocation handling, and validation logic—EIP-7805 is the best primary reference (EIP-7805 specification).

What problems FOCIL aims to solve

1) Builder or relay-level censorship

Even if Ethereum remains decentralized at the validator set level, block construction can become concentrated. If a small number of builders dominate block production, policy or business constraints can translate into transaction filtering.

FOCIL aims to make censorship less effective by ensuring a committee of validators can force the inclusion of transactions—reducing the chance that any single actor (or small clique) can filter indefinitely.

2) “Soft censorship” via delay

In practice, censorship often looks like delay rather than permanent exclusion. A transaction might be valid yet fails to land for many blocks due to filtering, risk controls, or private mempool dynamics.

FOCIL’s goal is to give Ethereum stronger guarantees that delay cannot be extended arbitrarily.

Trade-offs and open questions the community will debate

FOCIL is not free. If it becomes a serious candidate for Hegota, expect debates in at least these areas:

Network overhead & complexity: Inclusion lists must propagate reliably, and validators must verify constraints under tight slot timing.
Liveness considerations: Any mechanism that adds constraints to what counts as an acceptable block must be designed so the chain doesn’t stall during adverse network conditions.
Incentive design: EIP-7805 explicitly notes that it does not introduce a dedicated incentive mechanism for inclusion-list publishers, leaning on assumptions about validator behavior (EIP-7805 rationale). Separately, academic work has explored fee mechanisms and incentives for multi-proposer inclusion systems (arXiv paper by Stouka, Ma, Thiery).
Policy and jurisdictional risk: If inclusion becomes harder to avoid, some operators may worry about legal exposure in certain jurisdictions. This is less a purely technical objection and more a reality of operating infrastructure in 2026.

What this means for everyday Ethereum users

If FOCIL (or a FOCIL-like design) eventually ships, the user-facing change is subtle but important:

Your valid transaction should have a stronger path to inclusion, even when certain infrastructure providers would prefer it not land.
Over time, that can reduce reliance on “special routes” (exclusive relays, private submission channels, or ad-hoc relationships with builders) just to get normal transactions confirmed.

That said, users will still care about:

Fees (inclusion is not the same as cheap inclusion)
Privacy (FOCIL does not magically make transactions private)
Front-running / MEV (FOCIL is about inclusion guarantees, not MEV elimination)

Where OneKey fits in: censorship resistance starts with self-custody

Protocol-level censorship resistance is only one layer of the stack. The other layer is who controls the keys.

If your assets sit in custodial accounts, censorship can happen before you ever reach Ethereum—at the account level, withdrawal level, or API level. In contrast, self-custody ensures you can always sign and broadcast transactions through the route you choose.

This is where a hardware wallet like OneKey is a practical complement to Ethereum’s roadmap goals: by keeping private keys offline and enabling on-device transaction confirmation, OneKey helps reduce the risk that malware, compromised browsers, or unsafe signing flows undermine your security—especially during major network upgrade cycles when phishing and fake “upgrade” prompts often increase.

What to watch next (from now through Hegota)

As of January 2026, FOCIL’s push toward Hegota is best viewed as a serious proposal entering the fork-scoping process, not a guaranteed inclusion.

To follow the most relevant primary discussions:

The proposal discussion framing FOCIL as a Hegota headliner: Ethereum Magicians thread
The specification itself: EIP-7805
Core developer planning context and timelines: ACDE #226 notes

Takeaway

FOCIL represents a clear direction: moving censorship resistance from “best effort” norms to consensus-enforced inclusion guarantees. If the community converges around it for Hegota, it would be one of the most direct protocol changes aimed at preserving Ethereum’s neutrality in an era of increasingly professionalized block production and real-world compliance constraints.

For users, the message is simple: keep an eye on Hegota’s scope, but also control what you can today—use self-custody, verify what you sign, and reduce dependency on any single intermediary.