Ethereum FOCIL Explained: How Inclusion Lists Resist Transaction Censorship

Ethereum transactions can be valid, properly funded, and visible in the public mempool—and still depend on a block builder choosing them. That gap matters when a small set of sophisticated builders produces much of the network's blocks. Blockchain basics tells us that consensus decides which history wins; FOCIL asks who gets a meaningful say in which pending transactions enter that history.

FOCIL, short for fork-choice enforced inclusion lists, is the mechanism proposed in EIP-7805. It would let a randomly selected committee of validators publish bounded lists of pending transactions. The next block must satisfy the lists, and attesters withhold votes when it does not. FOCIL is an active proposal, not a feature users can rely on today, and its specification or upgrade target can change.

Why Ethereum Is Considering FOCIL

Ethereum separates several jobs. A proposer is selected for a slot, while specialized builders can assemble blocks and compete to offer the proposer valuable payloads. This market can improve block construction, but it also concentrates transaction-selection power. A builder, relay, or proposer may omit a transaction because of policy, regulation, private incentives, or simple preference.

The problem is not that every delayed transaction proves censorship. Low fees, invalid nonces, insufficient balances, congestion, and network propagation can all cause delay. The deeper concern is structural: if one party has the final transaction list, that party becomes a chokepoint.

Think of a block builder as an editor preparing one newspaper edition. Today, the editor largely chooses what fits. FOCIL gives a rotating committee several small “must consider” slips. The editor still arranges the paper and fills most pages, but cannot silently discard every valid item on those slips and expect the edition to be accepted.

How FOCIL Works Step by Step

EIP-7805 currently describes a 16-member inclusion-list committee and an 8 KiB maximum list per member. Those parameters belong to a proposal and may change before any mainnet deployment.

1. A committee observes the mempool. During slot N, randomly selected validators independently build inclusion lists from pending transactions they can see.
2. Members sign and broadcast their lists. Validators forward valid committee messages through the consensus network. Different members may see different mempool contents.
3. The builder collects the constraints. The builder for slot N+1 receives the lists while constructing its payload.
4. The next block satisfies valid list entries. Listed transactions can be placed anywhere in the block. A transaction can be omitted when it is invalid against the resulting state or the block lacks enough remaining gas.
5. Attesters enforce the rule. Attesters compare the block with the non-equivocating lists they stored. If an includable listed transaction is missing, they do not vote for that block.

That last step explains “fork-choice enforced.” Compliance is not merely a polite request to builders. It affects whether validators support the block through Ethereum's fork-choice process.

What FOCIL Changes—and What It Does Not

FOCIL distributes transaction-inclusion influence without removing builders. Builders can still optimize ordering, capture available value, and fill the rest of a block. The committee supplies constraints rather than an entire canonical ordering.

The proposal uses a one-out-of-N honesty intuition: if at least one non-equivocating committee member sees and lists a valid transaction, the builder should not be able to suppress it while producing a block that attesters accept. In 2026, an independent Lean 4 formalization examined the safety claim under Ethereum's broader honest-validator assumptions. That research is useful scrutiny, not proof that every implementation and network condition is solved.

FOCIL also does not promise instant inclusion. A user's transaction must propagate to a committee member, pass ordinary validity conditions, and fit the protocol's conditional-inclusion rules. Private transactions that never reach the public mempool may not be observed. Nor does FOCIL force a specific ordering, eliminate front-running, or make MEV disappear.

Why Conditional Inclusion Matters

A naive rule saying “include every listed transaction no matter what” would be unsafe. Transactions interact. One transaction may spend a balance or consume a nonce that makes another invalid. Lists could also exceed the remaining capacity of a block.

FOCIL therefore asks whether a missing list transaction could validly be appended after the block's existing transactions. The execution layer checks practical conditions such as nonce, balance, and remaining gas. If the transaction could still fit and execute, omission makes the inclusion-list condition unsatisfied. If it cannot, attesters do not reject the block merely because the transaction appeared on a list.

This design preserves builder flexibility, but it creates implementation work. Builders need list data in time, consensus clients must agree on what they observed, and execution clients must evaluate omissions consistently.

Risks, Limits, and Open Questions

• Network timing and liveness: builders need timely access to the lists. Poor connectivity or inconsistent views must not cause honest validators to reject otherwise usable blocks at scale.
• Committee equivocation: a member could send conflicting lists. The proposal tells validators to identify the equivocator and ignore that member's lists, adding protocol and networking complexity.
• Spam and resource use: list sizes are bounded, but nodes still spend bandwidth and verification work. List-building policy is partly left to implementations.
• Includer pressure: known committee members could face coercion or bribery. Research such as zkFOCIL explores hiding includer identity, but that is separate experimental work.
• Public-mempool dependence: a transaction hidden through private order flow cannot benefit from a committee that never sees it.
• Proposal uncertainty: EIP-7805 is not final mainnet behavior. Fork scope, parameters, interactions with native account abstraction, and deployment timing remain subject to testing and governance.

The Ethereum Foundation's 2026 protocol priorities place FOCIL within the “Harden the L1” censorship-resistance workstream. That establishes active research priority, not a guaranteed release date. Treat roadmap mentions as direction, not a promise.

What Users and Developers Should Do Today

Regular wallet users do not need to migrate funds, change addresses, or enable a FOCIL setting. There is no user-side upgrade. If a pending transaction is delayed today, first check its nonce, fee settings, balance, RPC provider, and network status using the pending Ethereum transaction guide.

Developers and node operators can follow the canonical EIP, client test implementations, and Ethereum protocol announcements. Applications should continue handling delayed inclusion and reorgs rather than assuming a proposed mechanism guarantees immediate settlement. Inclusion and blockchain finality are separate stages.

FAQ

Is FOCIL live on Ethereum mainnet?

No. As of August 11, 2026, EIP-7805 is a proposal under active research and specification work. Do not describe its committee size, timing, or upgrade placement as finalized mainnet behavior.

Does FOCIL prevent all censorship?

No. It raises the difficulty of sustained omission for valid transactions observed by honest committee members. It does not guarantee that every transaction propagates, remains valid, or fits immediately.

Does FOCIL replace block builders or MEV markets?

No. Builders still construct blocks. FOCIL constrains omission of listed transactions; it does not prescribe a complete transaction order or remove all extractable value.

Can a listed transaction still be excluded?

Yes. Conditional inclusion allows omission when the transaction would be invalid after the block's execution or cannot fit in the remaining gas. Exact rules remain part of the evolving specification.

Primary Sources

• EIP-7805: Fork-choice enforced Inclusion Lists — canonical proposal, mechanics, parameters, and security considerations.
• Ethereum Foundation: Protocol Priorities Update for 2026 — FOCIL's place in the L1 hardening and censorship-resistance workstream.
• Ethereum Research: Formalizing FOCIL in Lean 4 — May 2026 formal analysis of the inclusion safety claim and its assumptions.
• Ethereum Research: zkFOCIL implementation and benchmarking — research into privacy and coercion risks for inclusion-list committee members.

FOCIL is best understood as a proposed check on concentrated block-building power: several validators can constrain one builder, and fork choice gives that constraint weight. It is promising infrastructure work, not an investment signal or a live guarantee. Verify changing details in the primary sources, stay skeptical of token claims built around upgrade narratives, and do your own research (DYOR). This article is educational and not financial advice (NFA).