FOCIL on Ethereum: How Inclusion Lists Would Constrain Block Builders

FOCIL stands for fork-choice enforced inclusion lists. It is an Ethereum proposal, EIP-7805, intended to give a committee of validators a way to insist that eligible transactions seen in the public mempool appear in a block. A builder could still assemble most of the block, but attesters would withhold votes from a block that improperly omits listed transactions. As of September 16, 2026, the EIP is marked Draft; priority for an upgrade is not the same as activation on mainnet.

Why a builder’s choices matter

An Ethereum user broadcasts a transaction and expects it to be considered for a block. Specialized block builders may choose which pending transactions to include and in what order, often because block construction is outsourced by the proposer. If a small set of builders dominates that process, one builder’s decision to exclude an otherwise valid transaction can affect many blocks. Censorship resistance asks whether a user has another route to inclusion without depending on that builder’s goodwill.

The EIP-7805 specification describes FOCIL as a committee-based mechanism. It does not replace builders with a single new gatekeeper. Instead, selected validators each form an inclusion list from their own view of pending public transactions. The lists constrain the block that a proposer or builder assembles. Multiple observers reduce the chance that one actor alone can quietly suppress a transaction.

Follow one transaction through the proposal

Imagine a valid payment entering the public mempool while a builder would prefer to ignore it. Under the draft design, an inclusion-list committee member may place the transaction on a list and gossip that list to the network. Other committee members can produce their own lists. The proposer and attesters for the following slot collect the lists they have seen. The builder or proposer then prepares a block containing transactions from the collected lists where the inclusion conditions are satisfied.

Attesters check the block against the lists they stored. If an eligible listed transaction has been left out while it could still be included, the attesters should not vote for that block under the FOCIL fork-choice rule. That is the enforcement step: the builder may physically publish a block, but an improperly omitting block should fail to gain the votes needed to become the accepted chain head. “Fork choice” is about which competing blocks validators support, not about moving a transaction from a user’s wallet by force.

The current EIP preset describes a sixteen-validator inclusion-list committee for each slot. It also limits list size, because unrestricted lists could overwhelm block construction. These are draft specification details that may change before any hard fork. An explainer should therefore cite the EIP version rather than present every parameter as a permanent Ethereum rule.

The rule is conditional, not unlimited priority

FOCIL is designed for eligible transactions, not every string submitted to a node. The EIP’s execution check considers whether a listed transaction remains valid after the block’s other transactions and whether enough gas remains to append it. A transaction with an unusable nonce, insufficient balance or no fitting gas space can be absent without automatically making the block fail the list check. Public-mempool visibility itself is also a condition; a private transaction that committee members never see cannot be put on their lists.

These details matter for the phrase “guaranteed inclusion.” The mechanism aims to make censorship more difficult and timely inclusion more reliable for eligible, observed transactions. It cannot promise that any arbitrary transaction lands instantly regardless of validity, fee, network visibility or block capacity. A user whose transaction is pending should still examine nonce, gas and broadcast reach rather than attributing every delay to censorship.

Priority for Hegotá is not a live feature

The Ethereum Foundation’s September 7 Hegotá EIP priority post placed FOCIL in its top tier as a consensus-layer headliner. That shows strong planning support among the reviewers for the proposed upgrade. The EIP page, however, still labels EIP-7805 Draft. Until the changes are finalized, implemented across clients, tested and activated through a network upgrade, a mainnet user should not assume FOCIL already governs block votes.

Bit.Fan’s FOCIL news collection groups reports on the Hegotá priorities and related Ethereum planning. It is useful for seeing how the discussion develops, but individual headlines about “must ship” or “selected” refer to roadmap decisions. They do not replace the proposal’s technical status or announce a completed fork.

What must be tested before activation

A proposer needs to receive inclusion lists in time to build its block, and attesters need a consistent view of which lists count. Late or conflicting lists can create coordination problems. The EIP includes handling for a committee member who publishes conflicting lists and discusses liveness risk if builders cannot gather lists promptly. Client teams must also test the execution check, network gossip and fork-choice behavior together; a rule that is good on paper can harm block production if its timing assumptions fail in practice.

FOCIL is therefore a specific design for limiting block-builder censorship through validator-produced lists and attester votes. Its value would be measured by whether eligible public transactions gain a dependable path into blocks without undermining network operation. As of September 16, 2026, it remains a draft proposal prioritized for Hegotá. That date-and-status distinction is the crucial answer for anyone reading FOCIL headlines today.