FOCIL (EIP-7805): Enshrining Censorship Resistance in Ethereum

FOCIL (EIP-7805) just got SFI'd as the CL headliner for Hegota. With this inclusion, Ethereum is enshrining censorship resistance guarantees directly into fork-choice rules. This is a big deal. Let me break down what FOCIL does, how it interacts with PBS, and why it matters.

The Problem with Current PBS

Currently under PBS (Proposer-Builder Separation), builders construct blocks and proposers pick the highest bid. That works for keeping validators simple, but there's a catch. Builders can exclude transactions and currently there's nothing in the protocol that stops them.

Think about it. A builder receives thousands of transactions from the mempool, orders them for maximum MEV extraction, and creates a block. But what if they decide to just... not include certain transactions? Maybe they're being paid to censor. Maybe they're complying with some off-chain requirement. The protocol doesn't care. It just sees a valid block.

Although the censorship numbers are lower right now, this vulnerability exists. Censorship resistance right now depends on at least some builders being altruistic. That's not a great security assumption for a protocol that's supposed to be credibly neutral.

We've seen this play out. During the OFAC sanctions situation, a significant percentage of blocks were OFAC-compliant, meaning certain transactions were being filtered out. The network eventually processed them, but only because some builders chose not to censor. "Eventually" isn't good enough when you're building global financial infrastructure.

How FOCIL Works

FOCIL fixes this by adding an inclusion mechanism in the block building process. The idea is simple: create a committee that watches the mempool and makes sure transactions actually get included.

Every slot, 16 validators are randomly selected to form an inclusion list (IL) committee. Each committee member looks at the public mempool, builds a list of valid pending transactions, and gossips it across the network. These inclusion lists are essentially saying "hey, these transactions are valid and waiting, they should be in the next block."

The builder for the next slot is then required to include transactions from all the inclusion lists they've received. If they don't, attesters won't vote for the block. No attestation votes means the block can't become canonical.

Let's walk through the flow:

1. IL Committee Selection: At the start of each slot, 16 validators are randomly chosen from the active validator set
2. IL Construction: Each committee member scans the mempool, validates transactions, and creates their inclusion list
3. IL Gossip: These lists are broadcast across the p2p network
4. Builder Constraint: The builder constructing the next block must include transactions from the ILs they've seen
5. Attester Enforcement: Attesters check if the block respects the ILs. If not, no attestation

The beauty here is that the builder still builds the block. They still extract MEV. They still order transactions however they want. But they can't just drop transactions that are clearly valid and waiting.

Fork-Choice Enforcement

The key design decision is fork-choice enforcement. Previous inclusion list proposals tried to enforce inclusion at the proposer level. FOCIL moves the enforcement to the attesters. This is a subtle but important shift.

Attesters check whether the block includes the transactions from the ILs that they saw. If not, they don't attest.

Why does this matter? Think about the attack surface. Under proposer enforcement, you'd need to corrupt the proposer to censor. That's one entity. But under attester enforcement, a censoring builder would need to corrupt not just the proposer, but the entire attesting committee. That's thousands of validators. That's a much harder task.

That's why the EIP mentions: FOCIL requires only a 1-out-of-N honesty assumption from IL committee members. As long as one committee member is honest and their IL propagates, the censoring builder is caught. One honest validator out of 16. That's a pretty robust guarantee.

The game theory here is interesting too. Even if a builder wants to censor, they now face a choice: include the transaction and lose whatever they were being paid to censor, or exclude it and lose the entire block reward when attesters don't vote. The economics heavily favor inclusion.

FOCIL and PBS: Working Together

An important thing here is, FOCIL doesn't replace PBS. It works alongside it. This was a deliberate design choice.

Builders still run MEV auctions and optimize block ordering for maximum value. FOCIL only constrains what must be included, not how the block is ordered. The builder has full freedom to place IL transactions anywhere in the block. Front, back, middle, wherever makes sense for their MEV strategy.

FOCIL doesn't interfere with MEV extraction or the builder's ordering strategy. It just makes sure the builder can't drop transactions entirely. You can still sandwich, you can still arbitrage, you can still do all the MEV things. You just can't refuse to include a transaction that's sitting in the mempool with sufficient gas.

This separation of concerns is important. PBS exists because we want sophisticated actors handling block construction. We don't want to force every validator to run complex MEV strategies. FOCIL preserves this while adding the inclusion guarantee that PBS alone couldn't provide.

Handling Edge Cases

FOCIL also handles edge cases cleanly. The spec authors thought through the weird scenarios.

Invalid Transactions: If a transaction from an inclusion list becomes invalid by the time the block is built (maybe the nonce was used in another transaction, maybe the account balance dropped), the builder isn't forced to include that transaction. This is "conditional inclusion." The builder only needs to include IL transactions if they are still valid at the time of block construction.

Full Blocks: If the block is genuinely full (hit the gas limit), the builder has some flexibility. The protocol doesn't force builders to leave space for IL transactions if doing so would mean building a smaller block. But there are limits here to prevent gaming.

Late ILs: What if an IL arrives late, after the builder already constructed their block? The protocol has timing constraints. ILs need to arrive within a certain window to be enforceable. This prevents DoS attacks where someone floods late ILs to invalidate blocks.

Committee Failures: What if IL committee members go offline? The protocol degrades gracefully. If fewer ILs are available, the constraint is weaker, but the block can still proceed. You don't halt the chain because some committee members are offline.

Implementation Considerations

From a client implementation perspective, FOCIL adds new responsibilities across the stack.

Consensus clients need to:

• Implement IL committee selection logic
• Handle IL gossip and validation
• Modify fork-choice to check IL satisfaction
• Update attestation logic

Execution clients need to:

• Provide mempool access for IL construction
• Validate IL transactions
• Support conditional inclusion checks

The gossip layer sees new message types. IL construction adds some computational overhead for committee members. Attesters need to track which ILs they've seen. It's not trivial, but it's manageable.

The good news is that FOCIL doesn't require any changes to existing transaction formats or the EVM. It's purely a consensus layer change. Your smart contracts don't care. Your transactions don't care. The change is invisible to users except that their transactions are now guaranteed to be included (eventually, within reason).

The Bigger Picture

This is one of those protocol changes that impacts Ethereum's security and censorship resistance guarantees at a fundamental level.

Hegota with FOCIL, combined with Glamsterdam's ePBS (EIP-7732), gives Ethereum:

• Protocol-enforced builder markets: No more relying on off-chain relays
• Inclusion guarantees: Transactions can't be indefinitely censored
• Maintained efficiency: Builders still optimize, MEV still flows, validators stay simple

The roadmap is coming together. We've been talking about credible neutrality and censorship resistance for years. FOCIL is the protocol actually enforcing it. Not through social consensus, not through altruistic actors, but through fork-choice rules that make censorship economically irrational.

That's the kind of guarantee you want from base layer infrastructure.