FOCIL on Ethereum and legally credible neutrality

The debate over whether Ethereum's next major upgrade ("Glamsterdam") should include fork‑choice enforced inclusion lists (FOCIL, EIP‑7805)[1] has been framed primarily as an engineering and incentive‑design question. I want to reframe it as a legal‑design question: what does FOCIL do to the distribution of practical discretion among base‑layer actors, and does that improve the case for what I have elsewhere called "legally credible neutrality"?[2] My short answer is yes—mostly. FOCIL converts what is today a fragile, norm‑based non-censorship aspiration into a protocol‑enforced constraint for most validators and proposers, which strengthens the argument that they should be treated in law as neutral infrastructure rather than as editors of user activity. However, at the same time, FOCIL introduces a new locus of discretion in the inclusion‑list committee.

FOCIL is not a panacea for all forms of exclusion or latency gaming. Data Always and Hasu (Flashbots) even argued that FOCIL’s "censorship benefits do not extend to 99% of transactions known to be excluded by block builders today” (I'll return to this point later).[3] However, FOCIL certainly does increase Ethereum's censorship resistance and does so while improving the odds that base‑layer participants will be recognized as neutral where it matters.

What legally credible neutrality requires—and why FOCIL is relevant

I use legally credible neutrality to capture the argument that the law should recognize certain infrastructure actors as neutral and therefore refrain from imposing on them responsibility for user conduct.[4] The operative test in my work is practical: do these actors retain meaningful, attributable discretion over the information they process (here: transactions), or do protocol and market constraints make non‑neutral behavior implausible, futile, or prohibitively costly? Where discretion is diffuse, ephemeral, and auditable, the claim to neutrality is stronger.

In my companion Ethereum‑specific paper I argue that, for attestation in particular, the best path to legally credible neutrality is to make the neutral choice the only rational choice, enforced by the protocol (consensus) rather than more discretionary social pressure—so that validators can truly say "I could not do otherwise without breaking the chain's rules."[5] FOCIL is that kind of move for almost all network participants.

What FOCIL changes

At a high level, FOCIL adds a small, randomly selected committee of validators into each slot. Each committee member broadcasts a compact list (maximum 8 KiB) of transactions from its local view of the public mempool; the next block’s proposer (or external builder) must satisfy those lists, subject to obvious feasibility checks (e.g., gas and validity at block end). Crucially, attesters only vote for a block if it satisfies the stored inclusion lists. Fork‑choice, not etiquette, does the enforcement.

Why is this relevant to legally credible neutrality? Because FOCIL moves inclusion constraints into a place that is (a) independently verifiable, and (b) shared by many validators. That limits discretion—validators can credibly say: “my attestation was protocol‑constrained; my proposal was bound by inclusion lists; deviating would have made the block non‑canonical.” For sanctions, AML, and intermediary‑liability theories that turn on “control enables culpability,” this should matter.

However, the situation of those charged with creating inclusion lists is a bit more ambiguous. On the one hand, only one honest member of an inclusion committe (out of 16 members by default) is enough to get a transaction onto the aggregate list, and the committee’s discretion is bounded to a single slot. Those features increase neutrality of includers. On the other hand, beyond the cap on the size of an inclusion list (8 KiB), the spec intentionally leaves inclusion list building to client software. While this theoretically gives includers discretion over which transactions to pick, in practice they face significant barriers to exercising this discretion: modifying client software requires technical expertise, time, and ongoing maintenance costs to keep modifications compatible with protocol updates—a potentially onerous burden that makes deviation from default behavior economically and practically infeasible for most operators. In other words, while the Ethereum protocol would not police inclusion list content beyond a size cap, the default client behaviour functions as a strong coordination device; deviating is expensive enough that most includers are better characterised as rule-takers rather than agents with full editorial discretion—which matters for law and policy in the sense I develop in my general framework.[6]

Which actors gain (or lose) neutrality under FOCIL?

Attesters. Without FOCIL, attesters have no explicit content rule beyond protocol validity. With FOCIL, the only attestation compatible with consensus is for a block that satisfies inclusion lists. That removes residual discretion at the attestation stage and creates contemporaneous evidence of constraint (“fork‑choice made me do it”). This is a paradigmatic case for legally credible neutrality: a visibly neutral conduit.

Proposers and builders. Today’s proposers either build locally or outsource to builders; either way they retain discretion over inclusion and ordering. Under FOCIL, inclusion is constrained by inclusion lists, while ordering remains free. This is not perfect neutrality, but it is a significant narrowing of attributable choice (and it is the kind of neutrality that some kinds of legal regimes care for - e.g. economic sanctions - see below).

Inclusion list‑committee members. This is the residual weak spot in terms of legally credible neutrality. Committee members theoretically choose what to list, albeit under tight time bounds and without a veto power (because any one member suffices). However, the practical reality is that modifying default client behavior requires substantial technical resources and ongoing maintenance burdens that most operators cannot reasonably bear. As currently specified, inclusion lists can be attributed to specific includers, which creates a vector for "you chose to list X" theories—though this concern is mitigated by the fact that operators are effectively constrained to follow default client implementations. The way to further close that vector could include making inclusion list submissions indistinguishable (e.g., "anon‑inclusion lists") or otherwise de‑link inclusion lists from individual identities.[7]

What this means for sanctions and AML laws

Consider U.S. sanctions' facilitation theories, or EU "mere conduit/hosting" logic.[8] The FOCIL story for most validators and proposers is simple: the protocol made inclusion a consensus condition; deviating would have broken the chain or likely been futile (because another proposer would satisfy inclusion lists). That is the kind of independently verifiable constraint that supports classifying attesters and most proposers as neutral infrastructure—akin to, say, caching providers or connectivity services whose operations are structured to avoid editorial control.

To force attesters not to follow inclusion lists would run against the protocol. In practice, in most jurisdictions that kind of mandate would either (a) be ignored and merely relocate validators offshore, or (b) cause a fork, destroying much of the network’s global value—arguably a disproportionate outcome even for important policies like economic sanctions.

What about inclusion list‑committee members and sanctions screening? If inclusion lists are attributable, a public authority might be tempted to argue that the committee member “selected” a prohibited transaction. This is the corner case where FOCIL may need augmentation.

In this context, it's worth mentioning anonymous or indistinguishable inclusion lists (anon‑inclusion lists). The goal is straightforward: prove that someone in the committee listed the transaction without revealing who. The Ethereum Magicians discussion sketches approaches (e.g., linkable ring signatures; ZK proofs of committee membership).[9] This does not change FOCIL’s guarantees, but it may improve a bit the legally credible neutrality of includers - though more from an evidentiary rather than substantive perspective.[10]

What FOCIL does not solve

I already cited the argument made by Flashbots researchers Data Always and Hasu that FOCIL’s "censorship benefits do not extend to 99% of transactions known to be excluded by block builders today.”[11] As they noted, blob‑carrying transactions are sometimes avoided for latency reasons, and a considerable slice of the most sensitive order flow bypasses the public mempool entirely; neither is directly addressed by FOCIL. The authors estimate that the “classes of transactions that would benefit the most” from guaranteed fast inclusion are precisely those least helped by FOCIL today.

From the perspective of legally credible neutrality, the relative modesty of the FOCIL proposal may be a source of strength. We get a consensus‑level constraint that narrows discretion where it is legally salient (at least for legal regimes like sanctions or AML), which may be harder to achieve with more ambitious proposals.

Policy suggestions: safe‑harbor framing that matches FOCIL’s reality

In my Legally credible neutrality paper I argue that proportionate regulation should (a) avoid deputizing base‑layer actors where enforcement would be futile or harmful, and (b) focus on the layers where discretion and profit‑motive actually sit. Here is the practical proposal I would test with policymakers:

  1. Attesters and proposers (post‑FOCIL). Where consensus rules enforce inclusion constraints independent of any given validator’s preferences, attesters and proposers should be presumptively treated as neutral infrastructure for sanctions and AML facilitation purposes.

  2. Inclusion list committee members. Extend the same presumption when inclusion lists are built under documented, content‑neutral rules, even if those rules are not policed by the protocol. The practical barriers to modifying default client software—requiring technical expertise, ongoing maintenance, and resources to keep modifications compatible with updates—mean that committee members are effectively rule-takers following standardized implementations rather than exercising genuine discretion.

  3. Target edges. Concentrate AML/sanctions tooling (and any necessary liability) on off‑ramps and applications with sustained, individualized discretion; do not export those duties to base‑layer actors who cannot exercise equivalent judgment.

Note: This text was updated on August 29, 2025, to clarify that while inclusion list committee members theoretically have discretion to modify client software rules on transaction inclusion, they face significant practical barriers—including technical expertise requirements, ongoing maintenance costs, and the burden of keeping modifications compatible with protocol updates—that effectively make them rule-takers following default client implementations rather than agents with full editorial discretion.

  1. EIP-7805: Fork-choice enforced Inclusion Lists (FOCIL); Fellowship of Ethereum Magicians, EIP-7805 ↩︎

  2. I develop the concept in Legally Credible Neutrality and Legally Credible Neutrality on Ethereum. ↩︎

  3. Data Always, An MEV Perspective on Glamsterdam (Flashbots Collective, July 23, 2025). ↩︎

  4. Legally Credible Neutrality. ↩︎

  5. Legally Credible Neutrality on Ethereum. ↩︎

  6. EIP-7805 specifies IL_COMMITTEE_SIZE = 16 and MAX_BYTES_PER_INCLUSION_LIST = 8 KiB, and leaves inclusion list‑building strategies to implementers (e.g., random, priority‑fee, age), reinforcing client diversity but requiring careful defaults. ↩︎

  7. On the attribution risk and proposed anonymity (FOCILIS/anon‑inclusion lists) see Anonymous Inclusion Lists (anon-ILs) ↩︎

  8. For more background see Legally Credible Neutrality. ↩︎

  9. Anonymous Inclusion Lists (anon-ILs). ↩︎

  10. If including an "offending" transaction is still considered illegal, then anonimity doesn't change the fact that the includer does something illegal, but it makes it harder to prove. For instance, instead of relying on blockchain network data, a prosecutor may need to access directly the infrastructure of the includer to prove that they were the one who included some offending transaction. ↩︎

  11. Data Always, An MEV Perspective on Glamsterdam (Flashbots Collective, July 23, 2025). ↩︎