FOCIL, or Fork-choice enforced Inclusion Lists, is a draft Ethereum proposal that would make transaction inclusion part of the network’s fork-choice process. It aims to enable timely inclusion of valid transactions and reduce the censorship power of centralized block builders.
The design would give attesters a reason to withhold support from blocks that omit specified valid transactions, subject to defined exceptions such as the block being full.
FOCIL does not promise that every transaction will appear in the next block. Its proposed guarantee is limited by the transactions selected for inclusion lists, available block capacity and the proposal’s exceptions, and it is not a deployed Ethereum mainnet feature.
FOCIL’s inclusion guarantee is enforced by attesters, not just requested of builders
FOCIL turns an inclusion list—transactions a block is expected to account for—into an attester-enforced condition. Attesters withhold support from blocks that omit required transactions unless an exception applies, such as the block being full. The mechanism operates through fork choice, not merely through existing block-validity rules; Ethereum.org’s FOCIL explainer describes how attesters can assess a block differently when deciding which chain to support.
The result is a different balance between builders and attesters. A builder that ignores applicable inclusion-list transactions could still produce a block, but it would risk losing attester support. FOCIL is intended to constrain the discretion of centralized builders over transactions represented in committee-generated lists, shifting practical leverage toward the broader attesting set instead of leaving users dependent solely on a particular builder’s willingness to include them. The proposal is set out in EIP-7805.
The inclusion-list committee, builders and attesters each have a separate job
FOCIL separates transaction selection, block assembly and enforcement among different participants. That division is central to the design: the entity that creates a block does not alone determine whether the block receives attester support.
- Inclusion-list committee members: For each slot, selected committee members independently construct transaction lists from their own mempool views and gossip those lists to the network.
- Proposer or builder: The proposer or block builder collects the relevant lists and assembles the block, including transactions from them when required by the conditions.
- Attesters: Attesters evaluate whether a block satisfies those inclusion-list conditions and vote only for blocks that do, except where a specified exception permits an omission.
This arrangement does not assume that every committee member has the same mempool. A mempool is the set of transactions a participant has received and considers available; views can differ because transactions arrive at different times or through different network paths. FOCIL addresses that reality by having committee members independently form and gossip lists, rather than treating one participant’s transaction view as definitive.
Nor does the proposal eliminate builders. Builders or proposers still perform the task of aggregating information and creating blocks. FOCIL instead places a proposed protocol-level constraint around some of their inclusion choices. The EIP’s objective is to reduce censorship power, not to make block construction disappear.
How a same-slot FOCIL sequence reaches fork choice
A slot-level example shows the intended flow. At the start of a given slot, the inclusion-list committee members selected for that slot independently identify transactions from what they can see in their mempools. They sign and gossip their lists. A proposer or builder then gathers the available lists while constructing the block for that same slot.
Suppose a transaction appears on lists that trigger the proposal’s inclusion conditions. The builder is expected to include it if there is room and no other exception applies. When attesters assess the block, they check it against those conditions. If the block omits a required transaction without an applicable exception, the attesters are meant to reject it for fork-choice purposes rather than vote for it.
In simplified sequence:
- The slot’s committee members make signed inclusion lists from their respective mempool views.
- The lists are propagated, and a builder or proposer collects them while preparing a block.
- The block includes transactions needed to satisfy the relevant list conditions, subject to capacity and other specified exceptions.
- Attesters determine whether the block meets those conditions before supporting it in fork choice.
The same-slot timing distinguishes FOCIL from earlier forward inclusion-list approaches. Those earlier designs created a list for a future slot, producing a one-slot delay. FOCIL’s committee instead creates lists for the current slot, according to the Ethereum.org overview. The practical purpose is to bring list creation, block construction and enforcement into the same slot rather than require a transaction to wait for a list made one slot earlier to take effect.
Same-slot operation should not be confused with instantaneous universal visibility. Committee members still begin with their own received transaction sets, and builders need to obtain the relevant signed lists. The proposal’s networking rules are therefore part of the mechanism, not a peripheral implementation detail.
Required inclusion has capacity limits and explicit exceptions
A transaction can be pending without becoming a next-block obligation under FOCIL. The proposal makes it harder for block builders to arbitrarily leave out qualifying transactions, but it does not promise immediate inclusion for every submitted transaction or unconditional delivery for all pending transactions.
What enters the mechanism depends on the inclusion-list committee: its members independently use their mempool views to build and gossip lists, so a transaction must be visible to and selected by that process before it can appear in a FOCIL list.
Once a transaction is covered by an inclusion-list condition, capacity and specified exceptions still matter. Attesters may accept a block that omits required inclusion-list transactions when the block is full or another specified exception applies; an inclusion list cannot override a full block.
The specifications set the maximum inclusion-list transaction payload at 8,192 bytes and prescribe how signed lists are propagated, requested and recovered over the network. The Ethereum consensus specifications’ P2P interface consequently describes procedures for obtaining list data without assuming that every participant sees the same information at the same time.
FOCIL workflow showing the inclusion-list committee, gossip propagation, builder aggregation, and attester enforcement across adjacent slots. — Source: Ethereum Improvement Proposals — EIP-7805
FOCIL is a proposal under consideration, not Ethereum mainnet behavior
FOCIL is not a live Ethereum mainnet feature. EIP-7805 describes its mechanism and rationale, including fork-choice enforcement under which qualifying transaction inclusion can affect block acceptance, but publication as an EIP does not activate it.
The Ethereum Foundation said in January 2026 that FOCIL had been moved out of the Glamsterdam upgrade and placed in Considered status for the later Hegotá upgrade. That status reflects continued consideration rather than a finalized mainnet commitment or deployment; the relevant reference is the Foundation’s Checkpoint #8 update.
Until the proposal is finalized and deployed, its fork-choice rules remain a proposed change to Ethereum’s consensus-layer operation.
Frequently Asked Questions
Does FOCIL guarantee that every transaction enters the next Ethereum block?
No. It is intended to provide timely inclusion for valid transactions under its inclusion-list conditions, but blocks have capacity limits and the proposal allows specified exceptions, including when a block is full.
Would FOCIL remove Ethereum block builders?
No. Builders or proposers would still assemble blocks and collect relevant lists. The proposed change is that attesters would enforce inclusion-list conditions through fork-choice support.
How are same-slot FOCIL lists different from forward inclusion lists?
FOCIL has committee members create lists for the current slot. Earlier forward-list designs created lists for a later slot, introducing a one-slot delay.
What happens if an inclusion-list transaction is omitted because a block is full?
A full block is one of the stated exceptions to the proposed enforcement rule. In that circumstance, attesters can accept the omission rather than reject the block on that basis.
Is FOCIL active on Ethereum mainnet?
It is not a finalized mainnet feature. As of the Ethereum Foundation’s January 2026 update, it was in Considered status for the later Hegotá upgrade after being moved out of Glamsterdam.
