FOCIL: Fork-Choice Enforced Inclusion Lists Explained

By DeFi Intel Research · Reviewed 2026-07-02 · 10 min read · advanced

FOCIL inclusion list Ethereum introduces a novel mechanism to combat transaction censorship by altering how the network's fork-choice rule evaluates blocks. In the current PBS design, proposers (or their chosen builders) can selectively exclude transactions, enabling censorship. FOCIL shifts power to attesters—validators responsible for voting on the canonical chain—by letting them publish inclusion lists of pending transactions. The fork-choice rule then assigns higher weight to blocks that include these transactions, economically compelling proposers to include them or risk losing their block reward and finality.

This guide provides an advanced deep dive into FOCIL's architecture, its modification of the LMD-GHOST fork-choice function, concrete examples of thwarted censorship attacks, and comparisons with alternative approaches like canonical inclusion lists and crLists. Understanding FOCIL is essential for anyone seeking to grasp Ethereum's evolving censorship resistance landscape.

What Is FOCIL and Why Does Ethereum Need It?

FOCIL stands for Fork-Choice Enforced Inclusion Lists. It addresses a critical vulnerability in Ethereum's current proposer-builder separation (PBS): the ability of proposers or builders to censor transactions. In the classic PBS model (e.g., MEV-Boost), a proposer selects a block from a builder; the builder can choose which transactions to include, potentially excluding those from certain addresses or smart contracts. This threatens the neutrality of the network.

FOCIL introduces a counterweight: attesters (validators in the committee for that slot) broadcast a short list of transaction hashes they have seen in their mempool. The fork-choice rule is then adjusted so that blocks that include a superset of these transaction hashes receive a higher weight. Proposers who ignore the inclusion risk having their block orphaned by attesters who prefer an alternative block that includes those transactions. This creates a powerful economic incentive to include all legitimately pending transactions, preserving censorship resistance without sacrificing the efficiency gains of PBS.

How FOCIL Modifies the Fork-Choice Rule: The Core Mechanism

At the heart of FOCIL is a modification to the LMD-GHOST (Latest Message Driven Greediest Heaviest Observed SubTree) fork-choice rule, the algorithm that determines which block becomes canonical. In vanilla Ethereum, each block’s weight is determined solely by the number of attestations it receives, regardless of which transactions it includes.

Under FOCIL, attesters periodically (e.g., every 1/3 of a slot) publish an inclusion list—a compact set of transaction hashes they consider valid and pending. The fork-choice rule then tracks, for each competing block, how many of these attester-claimed transaction hashes are included in that block. A block’s total weight is computed as: attestation_weight + inclusion_bonus, where inclusion_bonus is proportional to the fraction of attester lists that the block satisfies. Attesters themselves are incentivized to vote for the block with the highest total weight, as that becomes the canonical chain.

“FOCIL makes the fork-choice rule ‘inclusion-aware’: blocks that omit certain transactions become structurally disadvantaged, even if they receive many attestations.” — Ethereum Research discourse

This modification requires a hard fork because it introduces backward-incompatible changes to the consensus block-validity rules, even though it does not change the block format or require new opcodes; the core change is to how attesters decide which block to vote for. The result is a game-theoretic shift where proposers must anticipate attester inclusion lists and include all likely transactions.

The Attester’s Role: Publishing Inclusion Lists

Every slot, a committee of attesters is selected. Under FOCIL, these attesters are expected to maintain a local view of the pending transaction pool (mempool). At predefined intervals (e.g., at 1/3 slot time), each attester constructs a signed inclusion list containing up to a few hundred transaction hashes (well within bandwidth limits). The list must be available to all other attesters and proposers via the gossip network.

• List composition: Attesters should include any transaction they believe is valid and that they have seen through gossip. They may prioritize based on gas price or fairness; however, the protocol does not dictate ordering, only inclusion.
• Authentication: Each list is signed by the attester to prevent spoofing. Attesters risk slashing if they include invalid transactions (e.g., ones with incorrect nonces or insufficient balance).
• Multiple rounds: To account for latency, FOCIL often uses a multi-round scheme (e.g., two windows) where attesters first share lists, then publish a final consolidated view. A proposer can then assemble a block that satisfies the majority of lists.

Attesters have no direct reward for publishing lists, but their primary incentive is to support the healthy chain; if they fail to publish, they may inadvertently enable censorship, decreasing the chain’s value. In practice, staking infrastructure providers will likely enable FOCIL automatically.

The Proposer’s Dilemma: Incentives Under FOCIL

A proposer in slot N sees multiple signed inclusion lists from attesters. The proposer must choose a set of transactions to include in their block. Under the vanilla fork-choice, they could ignore these lists. Under FOCIL, they face a clear dilemma: include enough transactions to satisfy a quorum of attester lists, or risk that attesters will instead vote for a competing block (if one exists) that does include them.

Consider an illustrative scenario: A proposer has built a block worth 0.05 ETH in MEV by excluding a transaction from address A. Attester lists collectively contain address A’s transaction (assume it’s valid and high-paying). If the proposer omits it, each attester’s fork-choice calculation will see that the proposer’s block includes, say, only 70% of the listed transactions, while a hypothetical empty block would include 0%. However, if another proposer (e.g., from a previous slot that was missed) builds a block including those transactions, attesters will shift their votes. The original proposer loses attestations and may even have their block orphaned, forfeiting the entire block reward plus the MEV. The economic calculus shifts: the cost of censorship exceeds any MEV gain.

To maximize revenue, proposers will include all transactions from all attester lists, potentially overfilling the block gas limit. In such cases, they may include the smallest transactions first or act after the block is built by asking builders to incorporate the lists. FOCIL does not mandate a specific ordering or full inclusion—it only weights based on a scalar matching fraction.

FOCIL vs. Other Censorship Resistance Proposals: A Comparison

FOCIL strikes a balance: it does not force proposers to include a rigid list (unlike canonical inclusion lists), which could conflict with block building efficiency, but it applies strong economic pressure. It works seamlessly with ePBS and MEV-Boost, making it a practical upgrade path.

Concrete Example: A Censorship Attack Thwarted by FOCIL

Imagine a targeted censorship attack: a powerful builder wants to exclude all transactions from a specific DeFi protocol (e.g., a tornado-like contract). Normally, the builder would simply omit those transactions, and the proposer would approve the block without penalty.

Under FOCIL:

1. Attester Alice sees a pending transaction from the target contract. She adds its hash to her inclusion list and broadcasts it.
2. Similarly, 60% of the attester committee also include that transaction hash in their lists.
3. Proposer Bob receives these lists. He has a builder offer a block paying 1.5 ETH but excluding the transaction. Bob also has a builder offering a block paying 1.3 ETH but including it.
4. Bob simulates both blocks under the FOCIL fork-choice: the first block will get a low inclusion bonus (e.g., only if it includes those tx? It doesn't, so bonus=0). The second block gets a high inclusion bonus. The total weight of the second block is higher, meaning attesters will vote for it.
5. Bob chooses the second block (or asks the first builder to include the transaction). The censorship fails.

This example highlights that FOCIL makes censorship economically irrational: Bob would lose more than the 0.2 ETH MEV difference.

Technical Deep Dive: Fork-Choice Weighting and Inclusion Proofs

The modified fork-choice rule requires attesters to verify inclusion of specific transactions in a candidate block. This verification uses Merkle proofs: each transaction has a unique hash commitment in the block’s transaction trie. Attesters, upon receiving a block, check for each hash in their inclusion list whether it appears in the block’s trie. The match count becomes the block’s inclusion score for that attester.

The final weight of a block in LMD-GHOST is computed as: W(block) = sum over attesters of (1 if attester voted for block else 0) + lambda * sum over attesters of (inclusion_score_of_block_from_attester's_list / max_possible_inclusion_score). The parameter lambda controls the strength of the inclusion incentive—too high and attesters may attack; too low and proposers may ignore.

To prevent attesters from lying, FOCIL introduces slashing conditions: if an attester signs an inclusion list containing a transaction that is not valid (e.g., uses wrong nonce or insufficient funds), they can be detected and penalized. Furthermore, the inclusion list itself must be available during the window; proposers who fail to include a transaction that is present in a widely-attested list may still produce a block, but will see reduced attestation support.

FOCIL in the Context of MEV and PBS

FOCIL is designed to complement, not replace, PBS and MEV-Boost. In the current MEV-Boost ecosystem, a proposer outsources block construction to a builder. FOCIL imposes a constraint on the builder: they must include the transactions from attester lists, or the proposer will lose support. Since builders want their blocks to be selected, they will update their algorithms to automatically include all attester-listed transactions.

However, FOCIL does not prevent builders from extracting MEV through ordering. The protocol only concerns itself with inclusion, not ordering. Thus, MEV extraction via transaction reordering (e.g., frontrunning) remains possible—this is a deliberate design choice to avoid overreach. FOCIL also integrates well with enshrined PBS (ePBS), where inclusion lists could be passed from attesters to the proposer during the slot.

One potential tension: if the inclusion list is large and the block gas limit is reached, the proposer must select a subset. FOCIL encourages the proposer to include the transactions that appear in the most attester lists, creating a “popularity contest” that is likely to align with legitimate demand.

Implementation Status and Challenges

FOCIL is currently an active research area within the Ethereum Foundation and client teams. An Ethereum Improvement Proposal (EIP) is being drafted (not yet finalized). Testnets have demonstrated basic functionality, but several challenges remain:

• Latency: Attesters must publish lists within tight timing constraints (e.g., 1/3 of slot) to be useful. Network delays could cause proposers to miss lists, reducing effectiveness.
• Overhead: Attesters must maintain an up-to-date mempool and compute inclusion scores; this adds computational load to validators, though it is expected to be modest.
• Game-theoretic stability: The lambda parameter must be tuned so that attesters are not incentivized to collude with proposers to exclude transactions (e.g., by not publishing lists). Ongoing analysis suggests that equilibrium exists under honest majority.
• Backward compatibility: FOCIL should not break existing MEV-Boost infrastructure; it requires clients to implement new fork-choice logic but does not change the block format.

If adopted, FOCIL could be deployed in a future hard fork after further testing.

The Future: FOCIL and Decentralized Censorship Resistance

FOCIL represents a paradigm shift from purely market-based censorship resistance (where users outrun censors through high fees) to a protocol-enforced mechanism. By involving attesters—the backbone of Ethereum’s security—FOCIL aligns the chain’s liveness with its neutrality. Long-term, FOCIL could become a standard component of Ethereum’s consensus layer, analogous to how slashing conditions protect against finality violations.

Combined with ePBS and other MEV mitigations, FOCIL paves the way for a censorship-resistant yet efficient block production ecosystem. It ensures that even if a cartel of builders emerges, attesters can force inclusion of any valid transaction. The ultimate impact is a stronger Ethereum that remains credibly neutral, a critical property for its role as global settlement layer.

Common mistakes to avoid

• Assuming FOCIL eliminates MEV entirely - it only ensures inclusion, not order fairness.
• Thinking attesters publish full blocks - they only publish short inclusion lists with tx hashes.
• Believing FOCIL is a standalone protocol - it's a modification to fork-choice that coexists with PBS.
• Overestimating proposer penalty - omission reduces block weight but doesn't necessarily cause immediate slashing.
• Confusing FOCIL with canonical inclusion lists that force proposer to include exactly the list - FOCIL only tilts fork-choice.
• Expecting FOCIL to work without a healthy mempool - attesters must see transactions; private mempools can undermine it.

Frequently asked questions

Related reading

• Account Abstraction Explained
• Blockchain Confirmations Finality Explained
• Consensus Mechanisms POW POS Explained
• Crypto Gas Fees Explained Save Money
• Curve Finance Explained
• Ethereum Layer 2 Networks
• EVM Vs Svm Explained
• Genius Act Us Stablecoin Law Explained