FOCIL stands for fork-choice enforced inclusion lists. It is an Ethereum protocol design that aims to improve transaction inclusion guarantees when specialized block builders, relays, private order-flow systems, or centralized infrastructure become powerful enough to quietly exclude transactions.
The core idea is simple: Ethereum should not depend only on one block builder or one proposer deciding which public transactions make it into a block. FOCIL gives a committee of validators a protocol-level way to list transactions they see in the public mempool. Blocks that ignore those inclusion constraints can lose attester support through fork choice, which makes censorship harder to hide inside normal block production.
FOCIL is proposed through EIP-7805. It is not normal Ethereum mainnet behavior until an upgrade activates it. The design matters because Ethereum block construction has become more specialized, and specialization can improve efficiency while weakening credible neutrality if a few builders control most transaction ordering.
| Component | What It Does | Why It Matters |
|---|---|---|
| Inclusion list | A list of public mempool transactions selected by validators | Gives pending transactions a stronger path into blocks |
| IL committee | A small validator committee selected for a slot | Reduces reliance on one proposer or one builder |
| Builder | Constructs the execution payload | Must account for transactions in collected inclusion lists |
| Proposer | Broadcasts the block for the slot | Carries the payload that should satisfy inclusion constraints |
| Attesters | Vote on the block through fork choice | Can withhold support from blocks that ignore valid inclusion lists |
| Fork choice | Ethereum’s rule for choosing the canonical chain head | Turns inclusion from a suggestion into a consensus-enforced constraint |
Ethereum users submit transactions into a mempool, where pending transactions wait before they are included in blocks. In a simple model, the next validator would select transactions directly. In practice, Ethereum block production often involves specialized searchers, builders, relays, and proposers because MEV has made block construction highly competitive.
That market structure can improve efficiency, but it also creates chokepoints. If a small number of builders dominate block construction, they can choose which transactions to include, delay, or ignore. A user may pay a valid fee and still face exclusion if the dominant builder, relay path, or private infrastructure refuses to include the transaction.
FOCIL changes the power balance. Validators that are not building the whole block can still help enforce transaction inclusion. Instead of asking builders to behave neutrally, the protocol gives validators a way to constrain what builders can omit.
That is why FOCIL belongs in the same conversation as MEV, proposer-builder separation, public mempools, and censorship resistance. It does not remove MEV. It narrows the room for silent exclusion of valid public transactions.
FOCIL works across two consecutive slots. In one slot, a committee of validators builds inclusion lists from the public mempool. In the next slot, the block must satisfy those lists unless the listed transactions are invalid or cannot fit under the protocol’s conditions.
A simplified backend flow looks like this:
| Step | Backend Action |
|---|---|
| 1 | Validators in the inclusion-list committee observe pending public mempool transactions |
| 2 | Each committee member creates and broadcasts an inclusion list |
| 3 | Validators and builders store inclusion lists that pass basic consensus-layer checks |
| 4 | The builder or local proposer constructs a block payload that includes required listed transactions where valid and possible |
| 5 | The proposer broadcasts the block |
| 6 | Attesters check whether the block satisfies the inclusion-list constraints they observed |
| 7 | A block that fails the inclusion check can lose votes and fail to become canonical |
The important detail is that inclusion lists are not merely advice. Fork-choice enforcement gives them weight. Attesters do not simply hope the builder included the transactions. They evaluate the block against the lists they stored and vote accordingly.
FOCIL gives validators a stronger role without forcing every validator to build a full optimized block. A validator in the inclusion-list committee does not need to win a block-building auction or compete with professional MEV builders. It only needs to observe public mempool transactions, create a bounded list, sign it, and broadcast it.
That design is useful because Ethereum has a much broader validator set than its builder market. If builders become centralized, validators can still preserve some of Ethereum’s neutrality by forcing public transactions into the block-building process.
The security assumption is also different. FOCIL does not need every inclusion-list committee member to be honest. It improves censorship resistance if at least one committee member sees and includes the transaction in its list, and the rest of the consensus process enforces that list properly.
FOCIL does not mean every transaction in every list must always appear in the block no matter what. Ethereum transactions can become invalid before inclusion. A sender may run out of balance, a nonce may be replaced, a block may be full, or a transaction may no longer fit after other transactions execute.
That is why FOCIL uses conditional inclusion. Attesters check whether missing listed transactions could still be appended to the payload under validity and space constraints. If a transaction is no longer valid, the block should not be rejected simply because that transaction is absent.
This distinction matters for account abstraction, smart contract wallets, batched transactions, and high-activity mempool conditions. A rigid “include everything” rule would create liveness risk and transaction invalidation problems. Conditional inclusion makes the design more practical.
An inclusion list without enforcement is weak. A builder could ignore it if ignoring it produced more profit, preserved a private relationship, or satisfied an external filter. Fork-choice enforcement changes that incentive.
Under FOCIL, attesters use the inclusion-list constraints when deciding whether to support a block. If a block does not satisfy the lists they stored, it can fail to collect enough attestation weight. That makes censorship more expensive because a builder cannot quietly omit valid listed transactions while still expecting the block to be treated normally.
This turns validators into inclusion enforcers rather than passive recipients of builder output. Ethereum still gets specialized block construction, but builders face stronger protocol constraints around what valid public activity can be excluded.
FOCIL is mainly about public mempool transactions. If a transaction only travels through a private order-flow system, private relay, wallet-specific routing path, or direct builder connection, it may not be visible to the inclusion-list committee. This is why the public mempool remains important for censorship resistance.
A transaction that sits in the public mempool can be observed by committee members and added to an inclusion list. That gives users a stronger route into the canonical chain even when builders prefer other order flow.
This does not eliminate private order flow. Traders, wallets, searchers, and apps may still use private routing for MEV protection or better execution. FOCIL mainly protects the public path so ordinary valid transactions are harder to ignore.
MEV exists because block construction has economic value. Searchers find profitable opportunities. Builders assemble profitable blocks. Relays and proposers help route and sign those blocks. The process can improve block efficiency, but it can also concentrate power around sophisticated infrastructure.
FOCIL does not try to ban MEV or remove block builders. It keeps the builder market while adding an inclusion constraint. Builders can still optimize ordering, arbitrage, and block value, but they must respect valid listed transactions if they want their blocks to receive attester support.
That makes FOCIL a censorship-resistance upgrade rather than a full MEV redesign. It protects inclusion more than ordering. A transaction may be forced into a block, but FOCIL does not guarantee the user receives the best execution, avoids sandwiching, or gets a specific position inside the block.
The most direct benefit is stronger confidence that valid public transactions will not be silently excluded by a small set of dominant builders. A user should have a better chance of timely inclusion when the transaction is valid, visible, and paying enough to be considered under normal block-space conditions.
FOCIL can also improve neutrality for apps that rely on public access. DeFi users, smart contract wallets, privacy tools, public mempool transactions, and censorship-sensitive applications all benefit when transaction inclusion is enforced by a broad validator process rather than by builder discretion alone.
The user experience should not require a new wallet button. FOCIL works at the protocol level. If activated, it would change how Ethereum enforces transaction inclusion behind the scenes rather than asking users to manually choose an inclusion-list mode.
FOCIL does not make Ethereum free. Users still need gas, valid nonces, enough balance, and transactions that fit within block-space conditions. A transaction can still be pending, invalid, failed, or delayed for ordinary technical reasons. A crypto transaction confirmation still depends on the transaction reaching a block and becoming part of accepted chain history.
FOCIL also does not protect users from every kind of MEV. It is focused on inclusion, not perfect ordering. A transaction included in a block can still face poor execution if the trade has loose slippage, thin liquidity, or bad routing.
It does not guarantee private transactions, either. Public mempool visibility helps inclusion lists, but it can also expose users to searchers. Privacy tools and MEV protection systems still matter for execution quality and user safety.
FOCIL adds consensus complexity. Validators need to gossip, store, and verify inclusion lists. Builders need to collect them and update payload construction. Attesters need to evaluate whether a block satisfies the inclusion constraints. Clients need compatible consensus-layer, execution-layer, networking, and API changes.
Bandwidth and denial-of-service risk also matter. Inclusion lists must be bounded so they do not overload the network. EIP-7805 uses a small committee and byte-size limits to keep propagation manageable. The proposal also deals with inclusion-list equivocation, where a committee member might send conflicting lists.
Liveness is the biggest design pressure. Ethereum should not reject blocks unnecessarily because of missing, invalid, late, or impossible transactions. FOCIL therefore needs careful timing, view-freeze rules, conditional inclusion, and reliable propagation between committee members, builders, proposers, and attesters.
FOCIL is designed to make Ethereum transaction inclusion more neutral and harder to censor. It gives validator committees the power to list public mempool transactions, then uses fork-choice rules so attesters can enforce whether blocks respect those lists.
The design does not remove builders, MEV, gas fees, or transaction-ordering competition. It adds a protocol-level check against silent exclusion. Builders can still optimize blocks, but they cannot ignore valid listed transactions without risking attester support. If activated, FOCIL would strengthen Ethereum’s censorship resistance by moving transaction inclusion guarantees closer to the validator set and further away from centralized block-building chokepoints.
The post FOCIL Explained: How Fork-Choice Enforced Inclusion Lists Improve Ethereum Transaction Inclusion appeared first on Crypto Adventure.
