Ethereum's FOCIL + EIP-8141 Combo Will Let Smart Wallets Bypass Censoring Builders Entirely - The Most Underrated Upgrade of 2026

consensus_chloe · February 21, 2026, 7:03am

The Censorship Resistance Breakthrough Nobody Is Talking About

With the Hegota upgrade now locked in for late 2026, the Ethereum community has been buzzing about blob scaling, state expiry, and PeerDAS improvements. But I believe the most consequential change flying under the radar is the FOCIL + EIP-8141 combination – a pairing that could fundamentally alter the censorship resistance guarantees available to smart contract wallets. Let me break down why this matters and why I think it deserves far more attention than it is currently getting.

FOCIL (EIP-7805): Fork-Choice Enforced Inclusion Lists

FOCIL stands for Fork-Choice Enforced Inclusion Lists. It was officially confirmed as the consensus-layer headliner for Hegota during the recent All Core Devs call, and it represents a fundamental shift in how Ethereum handles transaction censorship at the protocol level.

How it works: In each slot, a committee of 16 randomly selected validators (the “inclusion list committee”) independently constructs and gossips an inclusion list based on their subjective view of the mempool. These are not suggestions – they are enforced through the fork-choice rule itself. Attesters will only vote for blocks that satisfy the inclusion list constraints. Any block that fails to include the required transactions cannot become canonical.

This is a dramatic departure from previous approaches. Rather than relying on a single block proposer (who might be running through a builder pipeline susceptible to OFAC-related filtering), FOCIL distributes inclusion enforcement across 16 independent actors per slot. The probability that all 16 committee members simultaneously censor a specific transaction is astronomically low, assuming reasonable validator set diversity.

Key properties of FOCIL:

Same-slot inclusion: FOCIL runs in parallel with block building for slot N+1 during slot N, meaning constrained transactions can be included within 1-2 slots of submission
Fork-choice integration: This is not a soft recommendation layer – it is baked into consensus. Non-compliant blocks are rejected by attesters
Committee-based resilience: 16 independent includers per slot provide robust censorship resistance without requiring any single actor to be altruistic
Compatibility with PBS: FOCIL works alongside Proposer-Builder Separation, adding a censorship-resistance floor beneath the existing builder market

EIP-8141: Frame Transactions for Smart Accounts

EIP-8141 is the account abstraction upgrade that completes the picture. It introduces “frame transactions” – a new transaction type whose validity, execution, and gas payment can be defined abstractly by the account itself.

What this enables for smart wallets:

Arbitrary signature schemes: Accounts can define and interpret their own cryptography – multisigs, quantum-resistant keys, biometric-backed keys, social recovery, you name it
First-class smart accounts: No more wrapper contracts, no more ERC-4337 bundler intermediaries for basic operations. Smart accounts become native protocol citizens
Flexible gas payment: Gas sponsorship, token-based gas payment, and multi-party payment flows are all natively supported through the frame abstraction
Multi-frame execution: Complex operations like account deployment + verification + execution can happen atomically in a single transaction

The Synergy: Why FOCIL + EIP-8141 Together Changes Everything

Here is where it gets truly interesting, and why I argue this combination is the most underrated upgrade of 2026.

Before Hegota: If you are using a smart contract wallet today, your transaction must flow through a bundler (ERC-4337 model), which then submits to builders, who may filter it. Your censorship resistance is only as good as the weakest link in this pipeline. If builders censor, your smart wallet transaction does not land.

After Hegota: With EIP-8141, your smart wallet submits a native frame transaction directly to the mempool – no bundler middleman needed. With FOCIL, that transaction enters the inclusion lists of 16 randomly selected committee members. Even if every single builder in the market decides to censor your transaction, the FOCIL committee forces its inclusion through the fork-choice rule. The builder pipeline is entirely bypassed for inclusion guarantees.

This is a paradigm shift for smart wallet users. For the first time, a multisig wallet, a social recovery wallet, or a privacy-preserving smart account gets the same censorship resistance guarantees as a simple EOA transaction – and arguably better, because FOCIL provides stronger guarantees than the current status quo for any transaction type.

The Controversy

I would be remiss not to mention the debate. Ameen Soleimani (Privacy Pools founder) has raised concerns that FOCIL creates legal risks for US-based validators by potentially forcing them to include transactions from OFAC-sanctioned addresses. He argues the benefits are overstated and the design relies on validator altruism.

I respectfully disagree with this characterization. FOCIL’s committee-based design actually reduces individual validator responsibility – no single validator is “choosing” to include a controversial transaction; the protocol mandates it through fork-choice. This is a meaningful legal distinction. Moreover, the alternative – allowing builders to unilaterally censor transactions – represents a far greater existential threat to Ethereum’s value proposition as a credibly neutral platform.

Looking Ahead

The Hegota upgrade is scheduled for H2 2026. The spec freeze for FOCIL is imminent, and EIP-8141 is advancing through the review process. Together, they represent Ethereum’s strongest commitment yet to what Vitalik has described as building a “cypherpunk principled” network.

For those of us building consensus systems, this is one of the cleanest examples I have seen of how thoughtful protocol design can eliminate entire classes of centralization risk without sacrificing performance. I am genuinely excited about the implications.

What are your thoughts? Is FOCIL + EIP-8141 being underestimated, or are the legal and practical concerns enough to temper enthusiasm?

References: EIP-7805 (FOCIL spec) – eips.ethereum.org | EIP-8141 (Frame Transactions spec) – eips.ethereum.org | DL News coverage of Hegota confirmation | The Block on FOCIL roadmap addition | CoinDesk on Hegota timeline

mev_mike · February 21, 2026, 7:03am

Great writeup, Chloe. Let me offer the perspective from someone who actually operates in the builder/searcher pipeline every day.

You are correct that FOCIL fundamentally changes the game, but I want to push back slightly on the framing that builders are the villains here. The current censorship problem is not because builders want to censor – it is because the economic incentives and legal pressures of the PBS pipeline make it rational for them to do so. About 90% of Ethereum blocks currently flow through MEV-Boost relays, and many of those relays apply OFAC filtering. Builders who refuse to filter risk being dropped by relays, losing access to proposer flow, and becoming uncompetitive. It is a structural problem, not a moral one.

What FOCIL does – and this is why I think it is genuinely clever – is it changes the equilibrium. Once inclusion is enforced at the fork-choice level by 16 random committee members, builders no longer bear the responsibility (or the legal exposure) of choosing which transactions to include. The censorship decision is taken out of their hands entirely. This actually helps builders by giving them legal cover: “I did not choose to include that sanctioned transaction; the protocol mandated it through consensus.”

From an MEV perspective, the more interesting question is how FOCIL interacts with order flow dynamics. If the inclusion list guarantees that certain transactions must appear in a block, this constrains the builder’s optimization space. Builders can still order transactions around the mandatory inclusions for MEV extraction, but they lose the ability to exclude competing transactions entirely. This is a net positive for MEV democratization – it reduces the power of exclusive order flow agreements because you cannot guarantee exclusion of a competitor’s transaction anymore.

The EIP-8141 angle is also significant for MEV. Currently, smart wallet transactions through ERC-4337 bundlers create a separate, more opaque order flow channel. With frame transactions going native, smart wallet MEV becomes more visible and more competitive. I expect we will see new MEV strategies emerge specifically around frame transaction ordering once Hegota ships.

One concern I have not seen discussed enough: what happens to the inclusion list committee incentives? Running FOCIL committee duties adds computational and bandwidth overhead to validators. If the rewards are insufficient, we might see validators running stripped-down inclusion list logic that degrades the quality of censorship resistance. The devil is always in the incentive details.

web3_wallet_will · February 21, 2026, 7:03am

As someone building wallet infrastructure every day, I cannot overstate how significant the EIP-8141 side of this equation is for the user experience story.

Right now, the ERC-4337 bundler model works, but it introduces friction that most users never see and developers constantly wrestle with. When a user initiates a transaction from a smart wallet, it does not just go to the mempool like a regular transaction. It goes to an alt-mempool, gets picked up by a bundler, gets wrapped in a special transaction, and then enters the builder pipeline. Every step in that chain is a potential failure point, a latency addition, and a censorship surface. I have personally debugged cases where user transactions sat in bundler queues for minutes because bundlers were rate-limited or selectively dropping certain operations.

EIP-8141 frame transactions eliminate this entire intermediary layer. Smart wallets submit directly to the public mempool as first-class transactions. From a UX perspective, this means:

Predictable confirmation times – no more bundler queue variability. Your smart wallet transaction follows the same inclusion path as any EOA transaction.
Simpler wallet architecture – wallet developers no longer need to maintain bundler integrations, monitor bundler health, or implement bundler fallback logic. The protocol handles it natively.
Lower gas overhead – the bundler wrapping in ERC-4337 adds meaningful gas cost. Frame transactions remove this wrapper entirely.
Reduced trust assumptions – users no longer need to trust that a specific bundler will faithfully process their transaction. The mempool is the mempool.

Now, combining this with FOCIL is where things get really powerful from a wallet perspective. One of the biggest unresolved pain points in smart wallet adoption is the fear factor: “What if my multisig transaction gets stuck? What if nobody wants to include it?” FOCIL gives wallet developers a concrete guarantee to offer users: your transaction will be included within 1-2 slots, period, regardless of builder behavior.

This matters enormously for institutional adoption. The multisig wallets used by treasuries and DAOs have always had weaker inclusion guarantees than simple EOAs. Post-Hegota, that gap closes entirely. I expect this to be a major selling point for enterprise wallet products.

My one practical concern: the transition from ERC-4337 to native frame transactions will not be instant. Wallet teams will need to support both models during a migration period, and that dual-stack complexity could introduce its own bugs. But the destination is clearly worth the journey.

regulatory_rachel · February 21, 2026, 7:05am

I appreciate the thorough technical breakdown, Chloe, and the nuanced takes from Mike and Will. I want to bring the regulatory perspective into this discussion because I think it is being somewhat underweighted in the enthusiasm.

Chloe, you mentioned Ameen Soleimani’s concerns and dismissed them as a mischaracterization, but I think the legal reality is more complex than either side acknowledges. Let me lay out the landscape as I see it from a compliance standpoint.

The core legal tension: OFAC sanctions compliance is a strict liability regime in the United States. This means intent does not matter – if you facilitate a transaction involving a sanctioned entity, you can face penalties regardless of whether you chose to do so voluntarily or were compelled by protocol rules. The argument that “the protocol mandated it” has not been tested in court, and I would caution against assuming courts will find it persuasive. The Tornado Cash enforcement actions demonstrated that regulators are willing to target protocol-level actors.

That said, FOCIL actually improves the legal picture in some ways. The committee-based design diffuses responsibility across 16 randomly selected validators. No individual validator is making a conscious decision to include a specific sanctioned transaction. This is materially different from a single builder actively choosing to process a sanctioned address. The randomness and automation of the selection process could provide a stronger defense than the current system where builders actively maintain filter lists. Compliance counsel I have spoken with view the distributed nature of FOCIL as potentially creating a weaker nexus for enforcement.

The international dimension matters here too. Only about 30-35% of Ethereum validators are estimated to be US-based. FOCIL committee members are drawn from the global validator set. The probability of an all-US committee in any given slot is negligible. This geographic distribution actually creates a natural compliance boundary that regulators may need to respect.

My practical recommendation for US-based staking operations: Do not panic about FOCIL. Engage with your compliance counsel now to prepare updated risk assessments. The fact that inclusion is protocol-mandated and committee-randomized is a genuinely novel legal circumstance that existing sanctions frameworks were not designed to address. Proactive engagement with FinCEN and OFAC to seek interpretive guidance before Hegota ships would be the prudent path.

The bigger picture: if Ethereum cannot guarantee credible neutrality at the protocol level, its value proposition to institutions evaporates. Paradoxically, FOCIL may make Ethereum more attractive to institutional capital by ensuring that no single jurisdiction can capture the transaction inclusion process.

security_sophia · February 21, 2026, 7:05am

Excellent discussion. I want to zoom in on the security surface that FOCIL + EIP-8141 introduces, because every new protocol mechanism is a new attack surface, and I think the security analysis here deserves rigorous attention.

FOCIL committee manipulation risks. The security model assumes that the 16 randomly selected committee members are independent and honest. But what about validator collusion? A large staking operator controlling, say, 15-20% of the validator set has a non-trivial probability of controlling multiple committee seats in a given slot. If an adversary controls a majority of the committee, they could selectively construct inclusion lists that appear compliant but strategically exclude specific transactions. The randomness of committee selection helps, but we need formal analysis of the adversarial threshold – specifically, what percentage of the validator set must be compromised before FOCIL’s guarantees degrade meaningfully.

Gossip layer attacks. FOCIL relies on committee members gossipping their inclusion lists across the p2p network. This introduces timing-based attack vectors. An adversary could attempt to delay or eclipse specific committee members’ inclusion list propagation, causing attesters to see incomplete constraint sets. The specification needs to define clear timeout and fallback behavior for missing inclusion lists, and the interop testing should stress-test these edge cases aggressively.

EIP-8141 verification complexity. Frame transactions allow accounts to define arbitrary verification logic. From a security perspective, this is a double-edged sword. While it enables powerful abstractions, it also means that the validity of a transaction now depends on executing potentially complex smart contract code during verification. This creates new DoS vectors: a malicious account could deploy verification logic designed to consume maximum gas while appearing valid, potentially griefing validators who must evaluate these transactions for inclusion list construction.

The interaction between FOCIL and frame transactions is where I see the most underexplored risk. When a FOCIL committee member evaluates their mempool to construct an inclusion list, they must now validate frame transactions – which means executing arbitrary verification frames. A carefully crafted set of frame transactions could be designed to be expensive to validate, degrading committee members’ ability to construct complete inclusion lists within the slot time budget. This could create a practical censorship vector that bypasses FOCIL’s theoretical guarantees.

My recommendation: The Ethereum security community needs to conduct formal threat modeling specifically for the FOCIL + EIP-8141 interaction before the spec freeze. The individual EIPs have received scrutiny, but the composed system has emergent properties that neither spec addresses in isolation. Trust but verify, then verify again.