EIP-7805 FOCIL Explained: Ethereum Inclusion Lists and Censorship Resistance

For prerequisite reading on Ethereum's consensus, execution, and scaling architecture, start with the TokenToolHub Blockchain Advanced Guides. The economic reason transaction inclusion has become a protocol issue is closely tied to specialized block construction, private orderflow, and maximum extractable value, so the MEV in Crypto guide is useful background before examining the fork-choice rules in detail.

Why specialized Ethereum builders create an inclusion problem

Ethereum's consensus protocol chooses a validator to propose each block, but modern block construction increasingly separates the validator that proposes the block from the specialized infrastructure that decides which transactions are placed inside the execution payload. Builders aggregate public mempool transactions, private orderflow, searcher bundles, arbitrage opportunities, liquidation transactions, wallet flows, and other sources of execution value.

This specialization can protect validator decentralization. A validator does not need world-class search infrastructure or privileged private orderflow simply to remain economically competitive. Instead, specialized builders can perform complex payload optimization while ordinary validators concentrate on proof-of-stake consensus duties.

The tradeoff is that transaction-selection power can become concentrated even while the validator set remains broad. If only a small number of builders consistently construct the most valuable blocks, those builders gain significant influence over which transactions are included, delayed, reordered, or ignored.

A builder that does not want to include a transaction can simply omit it. If the next few profitable builders apply the same policy, a valid user's transaction can remain pending even though many independent validators may have seen it and would personally be willing to include it.

Builder concentration and validator decentralization are different measurements

A network can have hundreds of thousands of validators while depending on a much smaller number of entities for block construction. Validator count therefore does not automatically describe transaction-inclusion diversity.

FOCIL addresses this mismatch by returning part of the inclusion decision to a rotating validator committee. Builders retain freedom to construct efficient blocks and optimize ordering, but they receive transaction constraints from validators that independently observe the public mempool.

Why proposer choice alone is not enough

A proposer can theoretically build locally or choose a different builder when censorship is suspected. In practice, builders compete through payments and MEV extraction. If censoring builders consistently produce more valuable blocks, validators face an economic cost for routing around them.

A censorship-resistance mechanism is stronger when honest inclusion does not depend on every proposer voluntarily sacrificing revenue or detecting censorship in real time. FOCIL therefore makes inclusion constraints part of attestation and fork-choice behavior.

Persistent censorship is more serious than one missed block

One block can omit a transaction for harmless reasons. The transaction may arrive too late, have a low fee, become invalid, depend on a missing nonce, or simply lose competition for limited blockspace. Censorship becomes more concerning when a valid, economically competitive transaction remains excluded across repeated opportunities despite broad public propagation.

FOCIL does not try to force every mempool transaction into the immediate next block. It creates a bounded committee-based path through which publicly observed transactions can receive stronger inclusion pressure.

What FOCIL actually does

FOCIL is a committee-based inclusion-list mechanism enforced by Ethereum fork choice. Each slot selects multiple validators to act as inclusion-list committee members. Those validators independently observe their local mempool and publish signed lists containing transactions they want the next block builder to respect.

The lists are not themselves blocks. Committee members do not decide the complete transaction ordering, fee recipient, MEV bundles, execution payload, or block structure. They impose a bounded set of constraints on whoever builds the next block.

The builder can still place listed transactions anywhere inside its payload. It can still include thousands of other transactions. It can still optimize bundles and ordering around them, subject to ordinary Ethereum validity rules and any other protocol constraints.

The enforcement mechanism comes later. Attesters remember the valid inclusion lists they saw before a defined view-freeze deadline. When the next block arrives, they check whether that block satisfies the inclusion conditions implied by those lists. If it does not, they withhold their attestation from that block.

This formula is intentionally conditional. FOCIL does not say every byte signed by an inclusion-list committee member must appear regardless of validity or block capacity. That distinction protects liveness and prevents a committee member from breaking Ethereum merely by listing impossible transactions.

The five important roles in the FOCIL workflow

FOCIL is easier to understand when the responsibilities are separated. Committee members create constraints. Builders construct payloads. Proposers publish blocks. Attesters enforce their local view of those constraints. Execution clients determine whether missing listed transactions remained valid and includable.

Inclusion-list committee members

The current EIP defines a committee size of 16 validators. Each member can construct its own inclusion list based on its subjective mempool view. There is no requirement for all committee members to agree on one master list.

This matters because Ethereum's mempool is not globally synchronized. A transaction can reach one validator before another. Network latency, peer topology, geography, node policy, replacement rules, and local transaction pools all create different views.

FOCIL accepts that reality instead of pretending every validator sees an identical mempool. Attesters enforce the signed lists they actually received before the view freeze.

The builder

The builder may be the proposer building locally or a specialized external builder. During slot N, builders monitor inclusion-list gossip, forward valid messages, cache them, and prepare the execution payload for slot N+1.

The builder's job is not to concatenate every list blindly. Duplicate transactions can occur across lists. Some listed transactions may already have been included by ordinary payload construction. Some may become invalid because earlier transactions changed their sender's nonce or balance. Others may no longer fit within remaining block gas.

The proposer

At the beginning of slot N+1, the assigned proposer broadcasts the block with an execution payload that should satisfy the inclusion-list constraints known to the block-building process.

FOCIL therefore does not replace normal block proposal. It adds conditions under which attesters consider the proposed block worthy of fork-choice support.

The attesters

Attesters are the enforcement layer. They have their own frozen set of valid inclusion lists from the previous slot. When they see the new block, they inspect whether required transactions are present or whether any omissions are conditionally justified.

If a missing transaction could still have been validly appended to the end of the block and there was enough remaining gas, the execution layer reports that the inclusion-list condition was unsatisfied. The consensus client then refrains from attesting to that block.

The execution layer

The execution client helps distinguish censorship from legitimate omission. After the block's included transactions have executed, the client examines missing IL transactions against the resulting post-block state.

The current EIP's check focuses on whether remaining gas could accommodate the transaction and whether nonce and balance conditions for its origin permit valid inclusion. This keeps invalid or impossible transactions from becoming a weapon that forces attesters to reject otherwise healthy blocks.

Two-slot FOCIL timeline: from public mempool to fork-choice enforcement

FOCIL's most important design feature is its timing. Inclusion lists are created during slot N while the block for slot N+1 is being prepared. The proposer of slot N+1 then publishes a payload that must satisfy the inclusion conditions accumulated during slot N.

Step by step: one complete FOCIL cycle

The timing numbers in EIP-7805 make clear that FOCIL is not a generic eventually include this transaction rule. It coordinates specific observations during one slot with enforcement against the next block.

Committee members process the current head

During slot N, inclusion-list committee members first need a coherent view of the chain head. They observe and process the slot N block, then construct their lists from transactions pending relative to that head.

The current honest-validator guidance gives committee members until roughly eight seconds into slot N to create and release their ILs. If they have not received the expected block by roughly seven seconds, they can query their local fork-choice head and construct an IL based on that state instead of waiting indefinitely.

Each committee member independently selects transactions

The protocol does not currently prescribe one mandatory ranking algorithm for inclusion-list construction. An implementation could prioritize high-fee transactions, long-pending transactions, random eligible transactions, or another local policy consistent with future client guidance.

This is an intentional design choice. FOCIL's core consensus property is that committee members can place inclusion constraints on builders. It does not turn the protocol into a centralized mempool scheduler.

Validators store lists until the view-freeze deadline

Validators receive signed inclusion lists over a new global P2P gossip topic. Before storing and forwarding them, the consensus client checks basic properties such as the relevant slot, expected committee root, membership of the signer in the IL committee, BLS signature correctness, and size limits.

Importantly, this gossip-stage validation does not execute every listed transaction. That would increase computational load and complicate rapid propagation. As a result, an inclusion list can contain a transaction that later turns out to be invalid.

The validator view freezes

At approximately nine seconds into slot N, validators stop adding newly received ILs to the set that will determine their slot N+1 attestation. This establishes a bounded view for fork-choice enforcement.

They can still forward valid late messages and record equivocation evidence, but a late IL does not suddenly expand the transactions that a validator will require from a block that is already close to being proposed.

The builder receives slightly more time

The current draft allows the builder to continue receiving lists beyond the validator view freeze, with a planned builder freeze near the end of slot N. This gives the builder time to gather the constraints visible across the network and modify its payload before the next proposal.

A builder that failed to receive an IL known to many attesters risks constructing a block those attesters will not support. Connectivity to the IL gossip network is therefore economically and operationally important.

The proposer publishes the next block

At slot N+1, the proposer broadcasts the block containing the updated execution payload. The block is still an ordinary Ethereum execution payload in the sense that transactions must satisfy the normal state-transition rules. FOCIL adds another question on top: were the relevant inclusion-list conditions satisfied?

Attesters check their own frozen evidence

Attesters do not need to reconstruct one globally canonical master IL. They check the proposed payload against the non-equivocating lists they personally stored before their view freeze.

If all required listed transactions are present, the inclusion condition succeeds. When a transaction is missing, the execution client determines whether the omission was justified by invalidity or insufficient remaining capacity.

Conditional inclusion is the core liveness safeguard

The phrase force inclusion can sound absolute, but FOCIL is deliberately conditional. A block should not become un-attestable because a committee member listed a transaction that could not actually be appended to the block.

After executing the block's transactions, the execution client considers each listed transaction that is missing from the payload. If the transaction's declared gas exceeds the remaining block gas, the omission does not violate the IL condition. There was not enough capacity to append it.

If enough gas remains, the client checks whether the transaction is still valid against the post-block execution state, particularly the sender's nonce and balance under the current draft specification. If the transaction is no longer valid, omission is permitted.

If sufficient gas remains and the transaction is still valid, its absence means the block failed to satisfy the inclusion-list requirement.

Why validity is tested after block execution

The block itself can change whether a listed transaction remains valid. Suppose an inclusion list contains a transaction from Alice with nonce 12. The builder includes another transaction from Alice using nonce 12 earlier in the payload. The listed transaction can no longer be appended at the end because its nonce is now stale.

Likewise, an earlier transaction can reduce an account's balance enough that a listed payment can no longer cover value and gas. Conversely, another transaction can fund an address and make a previously impossible transaction executable.

Evaluating the missing IL transaction against the post-block state therefore gives the enforcement mechanism a concrete end-of-block question: could the builder still have appended this transaction?

Why inclusion lists may contain invalid transactions

FOCIL intentionally keeps consensus gossip validation lightweight. When a node receives an inclusion list, it validates the signed list structure and committee authorization without running full execution-layer transaction validity checks on every entry.

This means an inclusion-list committee member can include malformed, stale, underfunded, nonce-conflicting, or otherwise unusable transactions in the list. Those entries are not automatically dangerous because the later conditional-inclusion check prevents invalid transactions from forcing rejection of the next block.

Why not validate everything before gossip?

Execution validation would add latency and computational load to a gossip path that should remain quick and bounded. Every receiving validator would need to evaluate transaction state against a potentially changing head before deciding whether to forward the list.

The current design instead protects the network primarily through bounded list size, committee membership, signature verification, and limited gossip opportunities. Execution relevance is resolved when the builder constructs the next payload and when attesters validate that payload.

Invalid IL transactions are still operational noise

The fact that invalid transactions cannot force permanent rejection does not make them free. They consume part of the list's byte allowance, use P2P bandwidth, and create work for builders and execution clients.

Committee implementations therefore still benefit from constructing useful lists. A validator that fills its list with obviously stale or invalid transactions contributes less to censorship resistance than one selecting transactions that have a realistic chance of remaining valid.

Block capacity is a real boundary on the inclusion guarantee

FOCIL cannot require a transaction to fit inside blockspace that does not exist. If the proposed block has insufficient gas remaining to append a missing IL transaction, the block can still satisfy FOCIL even though that transaction is absent.

This property preserves liveness but creates an important censorship-resistance boundary. A builder has significant control over block composition before the final capacity check. In principle, filling blockspace with other valid activity can reduce room available for listed transactions.

Whether such behavior is economically rational depends on the fee market, available transactions, block resource rules, MEV opportunities, and the cost of consuming capacity. FOCIL should therefore be evaluated together with Ethereum's evolving block-resource and fee-market design.

Full block and censoring block are not automatically the same

A block can legitimately be full because demand is high. It would be incorrect to call every omitted IL transaction censorship simply because there was no remaining gas.

Censorship analysis needs context. Researchers should compare transaction fee competitiveness, when the transaction reached committee members, competing block demand, whether the same sender had conflicting transactions, and whether suspicious omission patterns repeat across blocks or builders.

Committee disagreement and inclusion-list equivocation

Multiple committee members improve censorship resistance, but committee-based designs must handle disagreement. Two different members are expected to publish different transaction sets because their mempools can differ. That is not equivocation.

Equivocation occurs when the same committee member signs conflicting inclusion lists for the same responsibility. One network region might receive list A while another receives list B, creating inconsistent constraints.

The current FOCIL P2P design allows nodes to propagate evidence of up to two lists from the same committee member. Once a proposer or attester detects conflicting lists from that member, it treats the member as an equivocator and ignores that member's ILs for enforcement.

Why ignoring the equivocator protects liveness

If validators were required to satisfy whichever contradictory list they happened to see first, a malicious committee member could intentionally split the network's enforcement view. Ignoring the equivocator removes that committee member's ability to impose divergent mandatory constraints.

The cost is that the network loses one censorship-resistance contributor for the slot. With a multi-member committee, the mechanism does not depend on one member remaining honest or available.

The security assumption is intentionally distributed

The EIP's rationale emphasizes a one-out-of-N honesty intuition. The mechanism can provide useful inclusion pressure when at least one committee member sees and lists a censored public transaction and that list propagates to the relevant enforcement participants.

That is very different from assigning one proposer sole responsibility for creating the inclusion list. Bribing or compromising one committee member cannot by itself suppress a transaction observed and listed by another honest member.

FOCIL's main liveness challenge is information arrival

The builder of slot N+1 needs the relevant inclusion lists from slot N before finalizing the payload. Attesters also need sufficiently consistent access to those lists before the view-freeze deadline.

A poorly connected builder can miss an IL that many attesters received. If the resulting block omits a still-valid transaction from that list, those attesters may refuse to vote for the block. The block builder therefore needs robust connectivity to the inclusion-list P2P network.

The deadline creates a necessary coordination buffer

Validators freeze their enforcement view before the builder's later payload-update point. This gives builders time to collect the lists that are likely to matter to attesters and incorporate transactions before the slot N+1 proposal deadline.

If the view freeze occurred too late, builders would have very little time to modify payloads. If it occurred too early, transactions arriving later in slot N would lose the censorship-resistance benefit. Parameter selection therefore balances fresh transaction coverage against payload-construction reliability.

Geographic network asymmetry should be measured

FOCIL creates a new performance surface where regional propagation differences matter directly. If some validators consistently receive committee lists later than others, their enforcement view can diverge.

Researchers should measure list arrival distributions, peer topology, client behavior, missed committee messages, and differences between large professional operators and geographically remote validators.

Why FOCIL is described as a same-slot inclusion-list design

FOCIL constructs the inclusion constraints for block N+1 while slot N is already underway. That means transactions appearing during slot N can potentially be listed and constrain the next block.

The design improves on older forward inclusion-list structures where the inclusion constraint could require an additional full-slot delay before enforcement.

This does not mean a transaction broadcast at any arbitrary millisecond is guaranteed to make the immediate next block. It still needs to reach at least one useful committee member, make that member's bounded list, propagate before relevant deadlines, remain valid, and fit within available block resources.

FOCIL guarantees inclusion pressure, not transaction position

Builders are free to place a required IL transaction anywhere in the block. FOCIL does not require it to appear at the top, bottom, before a particular transaction, or at the exact relative position implied by the committee member's local mempool ordering.

This anywhere-in-block property limits the complexity of the inclusion constraint and reduces incentives to create secondary markets around a mandatory position.

It also means FOCIL does not solve transaction-ordering fairness. A builder can satisfy the requirement to include a user's swap while still placing other transactions around that swap in economically significant positions.

FOCIL improves censorship resistance without eliminating MEV

Censorship and MEV overlap but they are not the same problem. Censorship asks whether a valid transaction can reach canonical blockspace. MEV concerns value created or extracted by transaction inclusion, exclusion, and ordering.

A builder can include a transaction because FOCIL requires it and still sandwich that transaction if the application and transaction parameters permit such ordering. A searcher can backrun a listed transaction. An arbitrage can execute immediately after it. A liquidation can still compete with other liquidations.

This distinction is especially important for users. A protocol-level transaction inclusion guarantee should not be marketed as a guarantee of good execution quality.

The TokenToolHub Front-Running in Crypto guide explains how transaction visibility and ordering create user-level risks that remain relevant even when censorship resistance improves.

A public mempool exposes transaction information

FOCIL is strongest for transactions that are openly propagated. Committee members need to see the transaction before they can place it in an inclusion list.

That creates a difficult tradeoff for MEV-sensitive transactions. Broadcasting publicly improves permissionless visibility and gives FOCIL committee members a chance to include the transaction, but revealing the transaction before ordering is fixed can expose profitable information to searchers and builders.

Users have responded to this problem by sending sensitive transactions through private RPC endpoints, private builder routes, orderflow auctions, and other systems that hide the transaction from the general public mempool.

Private routing can weaken the reach of public inclusion lists

If a transaction is visible only to one private service or one builder, a randomly selected FOCIL committee member may never receive it. A censorship mechanism based on public propagation cannot force inclusion of information the committee never observed.

This is why censorship resistance, privacy, and MEV protection need to be analyzed together rather than as isolated protocol properties.

FOCIL versus encrypted mempool approaches

Encrypted mempool research attempts to resolve the public-propagation tradeoff more directly. The goal is to let a transaction participate in a public, permissionless inclusion pipeline without revealing economically sensitive contents before the block-building commitment is fixed.

One current proposal, EIP-8184 LUCID, describes a public encrypted mempool architecture designed to work with FOCIL. Transactions can be propagated in sealed form, committed before their plaintext is revealed, and later decrypted for execution.

The important conceptual difference is that FOCIL answers which publicly observed transaction commitments must receive inclusion pressure, while an encrypted mempool attempts to answer how a transaction can become publicly includable without exposing its profitable contents too early.

Encrypted mempools do not make FOCIL obsolete

Hiding transaction contents does not by itself force a builder to include the commitment. A builder can still censor an encrypted transaction unless some protocol rule gives that transaction an enforceable path to blockspace.

This is why current encrypted-mempool research can be designed as an extension of an inclusion-list pipeline rather than a replacement for it.

FOCIL does not need to wait for perfect encryption

The cryptographic requirements for a large permissionless encrypted mempool are difficult. Key publication, non-reveal, ciphertext size, denial-of-service protection, decryption timing, quantum resistance, and trust assumptions all matter.

FOCIL can strengthen censorship resistance for ordinary public transactions while encrypted-mempool research continues addressing the privacy and MEV-sensitive transaction path.

FOCIL versus ePBS

FOCIL and enshrined proposer-builder separation are frequently discussed together because both change Ethereum block production, but their objectives are distinct.

ePBS formalizes the relationship between the consensus proposer and the specialized execution builder. It defines builder bids, payment commitments, delayed payload reveal, payload-timeliness signaling, and related fork-choice logic. The main goal is to make proposer-builder separation native and remove a critical external relay trust dependency while creating more time for execution validation.

FOCIL assumes specialized builders can continue existing and asks a different question: how can Ethereum prevent those builders from having unrestricted discretion to censor valid public transactions?

The two designs are complementary

ePBS can make specialized building safer for proposers and validators. FOCIL can make specialized building less dangerous to censorship resistance. Combining the ideas means Ethereum can outsource block optimization without giving one builder complete control over which publicly observed transactions are eligible for inclusion.

Neither mechanism eliminates builder concentration. A small builder set can still dominate MEV extraction, orderflow access, and transaction ordering even when proposers receive trustless bids and inclusion-list committees constrain some omissions.

What FOCIL changes for block builders

A FOCIL-aware builder cannot treat the block as an unconstrained optimization problem. It must monitor inclusion-list gossip, identify the lists relevant to the next block, de-duplicate transactions, track transaction validity, reserve or manage block capacity, and construct a payload that will satisfy the attesters' likely frozen views.

The naive implementation can become computationally expensive. Consider a collection of listed transactions where transaction validity changes as the builder adds other IL transactions. A transaction may fund another sender, increment a nonce, or alter validity relationships.

The EIP discusses how repeatedly testing every remaining transaction can lead to quadratic work in the worst case. It proposes more efficient state tracking around the nonce and balance of externally owned accounts involved in listed transactions.

Builders need excellent IL network connectivity

A builder cannot satisfy a list it never received. FOCIL therefore adds a new networking requirement to already latency-sensitive block-building infrastructure.

A sophisticated builder will likely monitor list arrival by committee index, maintain redundant peers, request missing lists where supported, track equivocation evidence, and compare the set of lists seen across geographically distributed nodes.

Payload optimization must account for constraints

The builder still wants to maximize block value. The optimization problem becomes maximize value subject to Ethereum validity and the applicable inclusion constraints.

Because FOCIL allows listed transactions anywhere in the block, the builder retains significant flexibility. It can position listed transactions where they interact efficiently with the rest of the payload, provided those positions do not invalidate the block or violate another protocol rule.

What FOCIL changes for validators

Validators receive a new censorship-resistance duty in addition to ordinary proposal and attestation responsibilities. Some validators are periodically selected as IL committee members, while all relevant validators need to observe and store valid inclusion-list gossip before the view freeze so they can enforce it later.

Committee duty is not ordinary block building

An IL committee member is not constructing a miniature execution payload. It is selecting transactions from its local public mempool and signing a bounded list.

The protocol currently does not define a special direct reward for participating in IL construction. The design relies on validators following the protocol because censorship resistance is a network property worth preserving.

Attestation software needs execution-layer feedback

A consensus client cannot determine every conditional omission from transaction bytes alone. It relies on the execution layer to report whether a proposed payload left out a listed transaction that remained valid and had room to fit.

The current design therefore extends Engine API interaction so inclusion-list information can participate in payload construction and new-payload validation.

Missed IL gossip can change an attester's view

Because validators enforce what they received before the deadline, network connectivity becomes part of censorship-resistance quality. Operators should monitor inclusion-list gossip with the same seriousness they apply to attestations, blocks, and other consensus messages.

Infrastructure requirements for FOCIL research

Protocol researchers need more than block explorer data to evaluate FOCIL properly. The mechanism depends on public transaction arrival, mempool visibility, inclusion-list gossip, builder views, block construction, execution validity, and attester behavior.

Useful studies may require geographically distributed nodes that record when a transaction first appeared, when an IL was observed, which validator signed it, when the block arrived, whether the transaction appeared, and what post-state validity conditions applied.

How to measure whether FOCIL is working

FOCIL success should not be judged only by whether clients implement EIP-7805 without consensus bugs. The intended outcome is stronger, measurable censorship resistance while preserving liveness.

Committee coverage

Measure how often at least one committee member receives a broadly propagated transaction before the list-building deadline. A censorship mechanism cannot protect public transactions if network propagation routinely fails to reach the committee.

List diversity

Compare how much committee lists overlap. Near-identical lists may indicate highly uniform mempool views, while extreme divergence can reveal propagation differences or radically different client selection strategies.

Listed-to-included conversion

Track what proportion of valid listed transactions appear in the next block. For omissions, separate insufficient capacity, post-state invalidation, list equivocation, late propagation, and actual inclusion failures.

Attestation behavior

A censorship-resistance rule only works when attesters enforce it. Researchers should identify blocks that appear to violate an attester's likely IL view and measure whether attestation support changes accordingly.

Builder-specific omission patterns

Compare builders over time. One builder may satisfy IL requirements consistently while another frequently relies on capacity or validity exceptions. Repeated patterns deserve closer investigation.

Transaction latency before and after FOCIL

Compare how long high-fee valid public transactions remain pending before and after activation, especially transactions associated with controversial applications, sanctioned addresses, privacy systems, or other historically censorship-sensitive categories.

Worked examples: how FOCIL treats real transaction situations

Example one: a builder deliberately omits a valid listed transfer

A user broadcasts an ordinary ETH transfer during slot N. One committee member sees the transaction, adds it to its inclusion list, signs the list, and gossips it before the deadline. The relevant attesters store that IL.

The builder for slot N+1 also receives the list but deliberately excludes the transaction despite leaving substantial gas unused. After the block executes, the transfer's nonce and balance remain valid and enough gas exists to append it.

The execution layer reports the inclusion-list condition as unsatisfied. Attesters enforcing that IL do not support the block. The builder cannot rely solely on ordinary execution validity to make its censored block canonical.

Example two: a listed transaction becomes nonce-invalid

A committee member lists Alice's transaction using nonce 25. The builder includes a different valid transaction from Alice with nonce 25 earlier in the block.

At the end of block execution, Alice's account now expects nonce 26. The listed transaction can no longer be appended. Its omission does not violate the FOCIL condition because the transaction is invalid against the post-block state.

Investigators should therefore avoid concluding censorship simply from listed but absent. Post-state validity matters.

Example three: the block has no room left

A listed contract call has a gas limit of 300,000. After constructing and executing the proposed payload, only 120,000 gas remains under the block gas limit.

The block is not rejected under FOCIL merely because the listed transaction is absent. The conditional inclusion check recognizes that the transaction could not be appended within remaining capacity.

Example four: two committee members list the same transaction

A popular transaction reaches most of the public network quickly and appears in several inclusion lists. The builder only needs to include the transaction once.

Committee overlap therefore does not multiply the execution requirement. The lists impose constraints, not duplicate execution.

Example five: committee members see different mempools

A transaction reaches validators in Europe quickly but arrives later at validators in another region. Committee member A lists it while committee member B never sees it before constructing its IL.

This is expected. FOCIL does not require identical lists. Attesters that received A's valid list before their freeze can enforce that transaction even though B's list does not contain it.

Example six: one committee member equivocates

A malicious committee member signs one inclusion list for half of its peers and a conflicting list for another half. Nodes later receive evidence of both signatures.

The protocol's response is to mark the committee member as an equivocator and ignore that member's inclusion constraints. Other honest committee members can still provide censorship-resistance coverage for the slot.

Example seven: a listed swap is sandwiched

A user's public DEX swap appears in an inclusion list. The builder includes the swap, so the FOCIL requirement is satisfied. However, the builder also places another transaction immediately before the swap and a backrun immediately afterward.

The user receives worse execution than expected. FOCIL worked from a censorship perspective because the transaction reached the block. It did not protect the user from ordering-based MEV.

Use the front-running guide and transaction-level evidence to analyze that outcome rather than treating inclusion and execution quality as the same security property.

Example eight: a private transaction never reaches the committee

A user sends a transaction directly to one private builder endpoint to avoid public-mempool MEV. The selected FOCIL committee never sees it.

Because no committee member can list information it did not receive, the transaction does not receive ordinary FOCIL force-inclusion protection. The user remains dependent on the private routing service or builder for access to blockspace.

Example nine: an encrypted public transaction

Under a future encrypted-mempool design integrated with FOCIL, a user could broadcast a sealed transaction commitment through the public network. Committee members could place the sealed object into the inclusion pipeline before builders learn its sensitive contents.

If the necessary decryption and execution conditions later succeed, the design can combine permissionless public inclusion with reduced pre-execution information leakage. This illustrates why encrypted mempool proposals are better viewed as FOCIL extensions than substitutes.

How to investigate a suspected censorship event

A transaction remaining pending for one or two blocks is not enough evidence to conclude censorship. A rigorous investigation starts with transaction validity and propagation.

Confirm the transaction's nonce, sender balance, max fee, priority fee, gas limit, chain ID, replacement history, and whether an earlier transaction from the same sender blocked it. If the transaction calls a contract, determine whether simulation succeeds against the relevant state.

Next establish whether the transaction was actually public. A wallet may label a transaction submitted while routing it through a private endpoint that bypasses the ordinary mempool. If the FOCIL committee never had a realistic opportunity to observe the transaction, its absence from ILs says little about builder censorship.

If the transaction appeared in one or more inclusion lists, compare the next block's remaining gas and the sender's post-block nonce and balance. Determine whether FOCIL would have required inclusion under the protocol's conditional rules.

Finally, study repetition. Persistent omission across multiple builders, high fee levels, valid state, and broad committee visibility provides stronger evidence than one isolated miss.

Does FOCIL solve rollup sequencer censorship?

No. EIP-7805 targets Ethereum L1 block construction. Rollups generally have their own transaction-ingress path, sequencer architecture, forced transaction mechanisms, batch submission rules, proof systems, and bridge escape hatches.

An L2 user can be censored by a centralized sequencer even while Ethereum L1 itself has strong FOCIL guarantees. The user may eventually force an L2 action through L1 if the rollup protocol exposes such a mechanism, but the exact guarantee depends on the rollup design.

FOCIL can strengthen the L1 blockspace path that rollup escape mechanisms ultimately depend on. If an L2's forced transaction is sent through Ethereum L1, stronger L1 censorship resistance can improve the reliability of that escape route.

For a broader assessment of sequencer centralization, forced inclusion, proof systems, settlement, bridges, data availability, and operational assumptions, use the TokenToolHub Rollups Buyer's Guide.

Validator and node-operator monitoring checklist

FOCIL introduces new consensus messages and deadlines. Operators should not treat the feature as invisible client plumbing.

Builder monitoring checklist

Builders need to integrate censorship-resistance constraints into an already latency-sensitive optimization pipeline.

What EIP-7805 does not solve

FOCIL is a targeted censorship-resistance mechanism. Several adjacent problems remain outside its direct scope.

It does not guarantee immediate inclusion for every transaction

A transaction must reach useful committee members, fit within bounded IL capacity, propagate before deadlines, remain valid, and fit inside available block resources.

It does not establish one globally identical mempool

Committee members and attesters can have different local views. The protocol is designed to operate despite those differences.

It does not eliminate builders

Builders can continue constructing the execution payload. FOCIL constrains omission rather than replacing specialized block construction.

It does not fix builder concentration

A few builders can still dominate because of private orderflow, capital, infrastructure, latency, simulation technology, and searcher relationships.

It does not provide transaction privacy

Ordinary FOCIL transactions are publicly visible before inclusion. This can expose them to ordering-based MEV.

It does not prevent sandwiches or front-running

A builder can satisfy inclusion requirements while choosing economically unfavorable ordering around a transaction.

It does not force impossible transactions

Invalid transactions and transactions that cannot fit in remaining block gas can be omitted under conditional inclusion.

It does not independently protect private orderflow

A transaction sent only through a private route may never be observed by the inclusion-list committee.

It does not solve L2 sequencer censorship automatically

Rollups retain their own ordering and forced-inclusion architecture.

It does not make censorship measurement trivial

Researchers still need propagation data, transaction validity, fee context, block capacity, builder identity, inclusion-list evidence, and repeated behavior before concluding intentional censorship.

Why FOCIL became a Hegotá headliner

Ethereum's scaling roadmap increasingly separates throughput improvements from the resilience properties needed to make that throughput safely accessible.

Glamsterdam's major changes focus heavily on execution capacity and block-production architecture, including enshrined proposer-builder separation and Block-Level Access Lists. Those changes can make larger workloads easier to propagate and process.

But scaling a builder-dominated system without strengthening transaction inclusion could increase the importance of the entities constructing those larger blocks. Ethereum Foundation protocol planning therefore treats censorship resistance as a dedicated L1-hardening objective rather than a side effect of scaling.

FOCIL was moved to Hegotá and selected as its consensus-layer headliner. By April 2026, Ethereum Foundation updates identified FOCIL as the selected major feature for the upgrade, and subsequent protocol reporting described functional prototypes with multi-client devnet work as the next milestone.

Hegotá gives FOCIL room to become a first-class protocol feature

Inclusion lists alter consensus networking, attester behavior, execution payload construction, Engine API interaction, fork choice, and validator duties. Treating FOCIL as a headliner gives client teams space to test those interactions across multiple implementations instead of adding censorship resistance as an incidental small feature.

Questions researchers should keep asking

Conclusion: FOCIL constrains builders without replacing them

EIP-7805 FOCIL addresses a structural consequence of Ethereum's move toward specialized block construction. Proposer-builder separation can protect validator decentralization by letting specialized entities optimize execution payloads, but concentrating transaction selection in a small builder market weakens the assumption that any widely propagated valid transaction will eventually find an independent proposer willing to include it.

FOCIL restores part of that inclusion authority to validators. During slot N, a 16-member committee independently publishes bounded transaction lists from its public mempool view. Validators freeze the IL evidence they received. Builders preparing slot N+1 incorporate those constraints into their execution payload. When the next block arrives, attesters compare it with their stored lists and use the execution layer to distinguish legitimate omissions from transactions that could still have been validly appended.

The enforcement mechanism is powerful because it sits inside fork choice. A block can be execution-valid yet still fail to receive honest attestation support if it improperly omits an applicable listed transaction. Builders are therefore constrained not merely by voluntary good behavior but by the canonical-chain incentives of proof-of-stake consensus.

The mechanism is also deliberately conditional. Invalid transactions cannot force their way into the chain. Transactions that no longer have sufficient balance, have the wrong nonce, or cannot fit into remaining block gas do not automatically make a block unacceptable. Committee equivocation is handled by ignoring conflicting lists from the equivocating member, while the multi-member committee preserves the possibility that another honest validator listed the censored transaction.

FOCIL should not be oversold. It does not guarantee transaction position. It does not eliminate MEV. It does not make a publicly visible swap private. It does not force private transactions into committee visibility. It does not remove specialized builders, eliminate builder concentration, or decentralize rollup sequencers.

This is where the broader protocol architecture matters. ePBS makes the proposer-builder relationship native and reduces relay trust. FOCIL constrains builder censorship. Encrypted mempool research aims to let MEV-sensitive transactions participate in a public inclusion path without revealing profitable information before commitment. These mechanisms target different layers of the same block-production system.

For prerequisite protocol context, continue through the Blockchain Advanced Guides. For the economics behind specialized builders and orderflow, use the MEV guide. For transaction-ordering exposure, see the front-running research. When investigating a specific included transaction, use the Transaction Decoder to move from protocol-level assumptions to direct execution evidence.

FOCIL's central idea is ultimately simple: specialized builders can optimize blocks, but they should not have unilateral power to silently exclude every valid transaction that the validator network can see. A rotating committee provides inclusion constraints, and fork choice gives those constraints consequences.

FAQs

References and further reading

The following primary Ethereum specifications and official protocol updates provide additional detail on FOCIL, Hegotá planning, proposer-builder separation, censorship resistance, and encrypted public transaction propagation.

• EIP-7805: Fork-choice enforced Inclusion Lists
• Ethereum Foundation: Protocol Priorities Update for 2026
• EIP-8081: Hegotá Network Upgrade Meta
• EIP-7732: Enshrined Proposer-Builder Separation
• EIP-8184: LUCID Encrypted Mempool
• Ethereum Foundation Checkpoint #9: Hegotá and FOCIL Headliner Update

This TokenToolHub guide is technical research and educational material. EIP-7805 remains a Draft specification and implementation details, timing parameters, Engine API behavior, committee rules, Hegotá contents, and activation dates can change before deployment. Validators, builders, client teams, application developers, and researchers should verify finalized Ethereum consensus specifications and production client releases before relying on the mechanism operationally.