EIP-7805, formally titled "Fork-choice enforced Inclusion Lists (FOCIL)," is a Core Ethereum Improvement Proposal designed to enhance the censorship resistance of the Ethereum network. ^{[1] [2]} The proposal, which was in "Draft" status as of its creation, introduces a mechanism to ensure that valid transactions submitted to the public mempool are included on-chain in a timely manner. It achieves this by creating a committee of validators to propose "inclusion lists" (ILs) of transactions, which are then enforced through modifications to the protocol's core fork-choice rule. This system is intended to counteract the centralizing effects of Proposer-Builder Separation (PBS) and reinforce the network's credible neutrality. ^[1]​

Overview

The primary motivation for EIP-7805 stems from the evolution of Ethereum's block production market after the implementation of Proposer-Builder Separation (PBS). PBS was introduced to separate the role of a block's proposer (a validator) from the complex and resource-intensive role of the block's builder. While successful in its aims, this led to the emergence of a small, highly specialized group of "builders" who construct the majority of blocks on the network. This concentration of power created a potential vector for transaction censorship, where a few colluding or coerced builders could systematically delay or exclude specific transactions from the blockchain. ^[2]​

EIP-7805 addresses this risk by re-empowering the broader set of decentralized validators. It gives them a tool to collectively impose constraints on block builders, guaranteeing that any valid transaction can eventually be included on-chain. The core principle is that validators who attest to new blocks will only vote for blocks that comply with the inclusion lists generated by a randomly selected committee of their peers. This makes it economically non-viable for a builder to produce a censoring block, as it would be ignored by honest attesters and ultimately orphaned from the canonical chain. The proposal aims to provide robust inclusion guarantees without re-introducing the complexities that PBS was designed to solve. ^{[1] [2]}​

History and Development

The proposal for EIP-7805 was formally created on November 1, 2024, by a team of researchers and developers including Thomas Thiery, Francesco D'Amato, Julian Ma, Barnabé Monnot, Terence Tsao, Jacob Kaufmann, and Jihoon Song. ^[1] A public discussion thread was initiated on the Fellowship of Ethereum Magicians forum on November 4, 2024, to gather community feedback and debate the design. ^[2]​

From its introduction, the proposal was classified as a "Standards Track: Core" EIP in "Draft" status, indicating it proposes changes to Ethereum's core consensus rules and requires a network-wide hard fork to be implemented. The discussions on the forum quickly began to explore potential challenges and future enhancements. A key topic was the attributability of transactions to specific validators, which led to a proposal for an anonymity-preserving extension called "FOCILIS" later that month. ^{[1] [2]}​

Technical Mechanism

FOCIL introduces a new set of rules and responsibilities for validators, builders, and clients, which are integrated into Ethereum's slot-based consensus cycle. The entire process for enforcing inclusions for a block in slot N+1 occurs concurrently during slot N. ^[1]

Core Concepts

The mechanism is built upon several key ideas:

• Inclusion List (IL): A list of transactions compiled by a committee member from their view of the public mempool. These are transactions that the member believes should be included in the next block.
• IL Committee: In each slot, a group of 16 validators is randomly selected to form the IL committee. Their sole responsibility is to create and broadcast ILs to the network.
• Fork-Choice Enforcement: The power of the proposal comes from modifying the fork-choice rule, the set of rules validators use to decide which chain is the canonical one. Under FOCIL, attesting validators will reject blocks that do not correctly satisfy the IL inclusion requirements, effectively preventing non-compliant blocks from being finalized.
• Conditional Inclusion: Enforcement is not absolute. A builder is only required to include transactions from an IL if those transactions are valid at the point of inclusion (e.g., correct nonce, sufficient sender balance) and if there is enough gas remaining in the block. Transactions that become invalid or do not fit are not required.

These core concepts are implemented through a coordinated workflow involving multiple network participants. ^[1]

Roles and Workflow

The FOCIL process involves a precise timeline within each 12-second slot, coordinating the actions of the IL committee, general validators, block builders, and the next block's proposer. The process for generating ILs for the block in slot N+1 unfolds during slot N.

Timeline in Slot N	Role	Responsibility
t=0s – 8s	IL Committee Members	After observing the block for slot N, each of the 16 committee members independently creates an inclusion list from their local mempool and broadcasts the signed list to the P2P network.
t=0s – 9s	All Validators	Listen for, validate, store, and forward all valid ILs they receive from committee members. They also monitor for evidence of equivocation (a single member sending multiple different ILs).
t=9s	All Validators	At the "view freeze" deadline, validators stop accepting new ILs for the current slot. This creates a stable, shared set of ILs that will be used to validate the next block in slot N+1.
t=0s – 11s	Block Builder	Collects all available ILs from the network. They use these lists to construct a compliant block payload for slot N+1.
t=11s	Block Builder	The builder freezes its view of the ILs and finalizes the execution payload, ensuring it contains all includable transactions from the collected lists.
t=0s (Slot N+1)	Block Proposer	The proposer for slot N+1 broadcasts the new block, which contains the builder's compliant execution payload.
t=0s – 4s (Slot N+1)	Attesters	Upon receiving the slot N+1 block, all attesters for that slot cross-reference it against their frozen view of ILs from slot N. They only cast a vote (attestation) for the block if it correctly includes all required IL transactions.

This tightly timed workflow ensures that inclusion lists are generated and disseminated in time for builders to construct a compliant block, which is then promptly validated by the wider network of attesters. ^[1]

Protocol-Level Changes

Implementation of EIP-7805 requires coordinated changes across the Consensus Layer (CL), Execution Layer (EL), and the Engine API that connects them.

Consensus Layer (CL) Modifications

• Fork-Choice Rule: The CL's fork-choice logic is updated to only consider a block valid for attestation if it satisfies the inclusion list conditions. Blocks that fail this check are ignored by attesters.
• New Data Structures: Two new containers are introduced: InclusionList, which holds the slot number, committee member index, and the list of transactions, and SignedInclusionList, which is the InclusionList signed by the committee member.
• P2P Network: A new global gossip topic is created for broadcasting SignedInclusionList objects, ensuring they can propagate quickly across the network. A new RPC method is also added to allow nodes to request specific ILs they might have missed. ^[1]

Execution Layer (EL) Modifications

• New Validity Check: The EL is given a new responsibility. When processing a new block payload, it must check if any transaction from the provided ILs was omitted despite being includable.
• Includability Definition: A transaction is defined as "includable" if it meets two conditions: (1) the block has sufficient gas remaining for it, and (2) the transaction is valid against the final state created by the block (i.e., the sender has the correct nonce and enough funds).
• New Error Status: If the EL finds an includable but un-included transaction, it returns a new status, INCLUSION_LIST_UNSATISFIED, to the CL. The CL then knows to reject the block. ^[1]

Engine API Enhancements

To facilitate communication between the CL and EL, the Engine API is extended with new methods:

• engine_getInclusionListV1: Allows the CL to request an IL from the EL.
• engine_updatePayloadWithInclusionListV1: Used by the CL to pass the builder's aggregated ILs to the EL during block construction.
• The existing engine_newPayload method is modified to accept IL transactions as a parameter and to handle the new INCLUSION_LIST_UNSATISFIED status. ^[1]

Key Parameters

The proposal defines several constants to govern the mechanism:

Parameter	Value	Description
IL_COMMITTEE_SIZE	16	The number of validators selected for the IL committee in each slot.
MAX_BYTES_PER_INCLUSION_LIST	8192 (8 KiB)	The maximum size of an individual IL, limiting network bandwidth and storage requirements.
DOMAIN_IL_COMMITTEE	0x0C000000	A unique signature domain used to prevent IL signatures from being replayed in other contexts.

These parameters are chosen to balance censorship resistance with network overhead and performance. ^[1]

Rationale and Design Principles

The design of FOCIL is guided by several key principles aimed at creating a robust and minimally complex solution.

• Committee-Based Sourcing: Using a committee of 16 validators rather than a single entity (like the proposer) to source transactions makes the system more resilient. Bribing or attacking a single committee member is ineffective, as only one honest member is needed to get a transaction into an IL. Attacking the entire committee is significantly more difficult and expensive.
• Fork-Choice Enforcement: Tying enforcement directly to the fork-choice rule is the strongest possible guarantee. It makes compliance a core part of the consensus protocol, meaning builders cannot bypass it without their blocks being rejected by the network.
• Flexibility for Builders: The EIP gives builders flexibility in two ways. First, through conditional inclusion, builders are not punished for omitting transactions that have become invalid. Second, the "anywhere-in-block" rule means builders can place IL transactions anywhere in the block, allowing them to continue optimizing for MEV without interference, which avoids creating complex off-chain ordering markets for ILs.
• No Direct Incentives: The proposal deliberately omits a new fee market or direct financial rewards for IL committee members. It relies on the 1-out-of-N honesty assumption (at least one of N committee members will be honest) and the general altruism of validators who want to maintain the health and neutrality of the network. This avoids the significant complexity of designing a new, un-gameable incentive system.

This collection of design choices aims to deliver strong censorship resistance while minimizing disruption to the existing block production ecosystem. ^[1]

Security Considerations and Challenges

The FOCIL proposal introduces new consensus interactions and dependencies, which come with potential security considerations.

• Consensus Liveness: The mechanism's primary liveness risk is that delays in IL propagation could cause delays in block production. If a builder does not receive the ILs before its deadline, it might produce a non-compliant block, which would then be rejected, potentially leading to an empty or missed slot. The timeline includes a buffer between the validator view freeze (t=9s) and the builder's deadline (t=11s) to mitigate this.
• IL Equivocation: A malicious committee member could attempt to disrupt the network by broadcasting multiple different ILs for the same slot. The specified mitigation is for nodes to forward up to two distinct ILs from a single member but to ignore all ILs from that member if more than two are detected. This contains the potential bandwidth impact and confusion caused by an equivocating validator.
• Payload Construction Complexity: A naive builder algorithm for satisfying IL constraints could be computationally intensive. For a large number of transactions in the ILs, repeatedly checking their validity while building a block could be slow. The EIP's authors suggest a more efficient strategy where builders track the nonce and balance changes of accounts involved in ILs as they add transactions to the block, allowing for faster validity checks.
• Validator Attributability: A significant challenge discussed in the community is that FOCIL creates a public, on-chain link between a validator's identity and the transactions they choose to include in their IL. This could have a "chilling effect," where validators grow hesitant to include transactions from controversial or sanctioned entities for fear of legal or social repercussions. This could ironically undermine the system's anti-censorship goals. ^{[1] [2]}

Proposed Extensions and Future Directions

In response to the validator attributability challenge, the community began discussing privacy-preserving enhancements.

FOCILIS

The most prominent extension proposed was FOCILIS (FOCIL with Indistinguishable Submissions). This concept, raised in the Ethereum Magicians forum in late November 2024, aims to allow a committee member to submit an IL anonymously.

• Mechanism: Instead of signing an IL with their private key, a validator would generate a zero-knowledge proof (ZKP). This proof would demonstrate that they are a legitimate member of the current slot's IL committee without revealing their specific identity. The proposed construction was described as being similar to Semaphore, a privacy-focused signaling protocol.
• Equivocation Resistance: To prevent an anonymous validator from submitting multiple ILs, FOCILIS would use a nullifier system. Each committee member would commit to a unique, one-time-use ID, ensuring that each member can only generate one valid proof (and thus one valid IL) per slot.

The consensus in the discussion thread leaned towards a pragmatic, two-stage implementation. The simpler, fully attributed FOCIL would be deployed first to provide immediate censorship resistance. Meanwhile, research on FOCILIS and other "anonymous inclusion lists (anon-ILs)" would continue, with the goal of deploying a privacy-preserving version in a future network upgrade. ^[2]

Backwards Compatibility

EIP-7805 is a backward-incompatible proposal that can only be activated through a planned network-wide hard fork. The changes fundamentally alter block validation rules at the consensus layer, requiring all client software (both CL and EL) to be updated. However, the changes are contained within the protocol's backend and do not alter the structure of user transactions or the functionality of existing smart contracts. Therefore, the upgrade is not expected to break user-facing applications or require action from end-users or contract developers. ^[1]