Inclusion List

What Is an Inclusion List?

An inclusion list is a set of transactions that a block proposer (or committee of validators) specifies as mandatory for a block builder to include in the next block. If the builder ignores the list and the block has available space, the block is considered invalid or attesters refuse to vote for it, effectively orphaning the non-compliant block.

The concept emerged from a fundamental tension in Ethereum's proposer-builder separation (PBS) architecture. PBS delegates block construction to specialized builders who optimize for maximal extractable value (MEV). While this separation improves validator decentralization by removing the need for validators to run complex MEV strategies, it concentrates censorship power in a small number of builders. Inclusion lists address this by giving validators a protocol-level tool to override builder censorship decisions.

Vitalik Buterin first outlined the concept in a 2022 research note on increasing censorship resistance under PBS. Since then, the design has evolved from single-proposer models to the committee-based FOCIL approach now scheduled for a future Ethereum upgrade.

The Censorship Problem

Nearly 95% of Ethereum blocks are now built by external builders through MEV-Boost relays. This concentration creates a practical censorship vector: builders can selectively exclude transactions interacting with OFAC-sanctioned addresses, privacy protocols, or any other target.

After Ethereum's transition to proof of stake, OFAC-compliant block building peaked at roughly 95% of relay-built blocks in late 2022. As non-censoring relays gained market share, that figure declined steadily: to approximately 47% by late 2023, below 30% by 2024, and to around 17% of MEV-Boost blocks by late 2026. While the trend is positive, even 17% censorship compliance means a meaningful fraction of blocks still exclude certain valid transactions.

Inclusion lists aim to make censorship structurally impossible at the protocol level, rather than relying on the goodwill of relay operators and builders.

How It Works

The core mechanism is straightforward: validators tell builders which transactions must appear in a block, and the network rejects blocks that ignore the instruction. The implementation details, however, have evolved significantly.

EIP-7547: The Original Proposal

The first formal specification, EIP-7547, used a "forward inclusion list" design. The proposer of slot N would specify up to 16 transactions (with a combined gas limit of approximately 2 million gas) that the builder of slot N+1 must include.

This approach had several weaknesses:

• A single proposer controlled the list, making them a straightforward bribery or coercion target
• The one-slot delay gave builders time to work around the list through strategic block construction
• Validators lacked economic incentive to include genuinely censored transactions, since the inclusion list block space could be sold through side markets

Core developers set aside EIP-7547 before the Pectra upgrade, citing the need for further research and a more robust design.

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

FOCIL, specified in EIP-7805, addresses the shortcomings of single-proposer inclusion lists by distributing responsibility across a randomly selected committee and enforcing compliance through the fork-choice rule.

The process works in several steps:

1. For each slot, 16 validators are pseudorandomly selected as inclusion list committee members using the same randomness beacon (RANDAO) that selects attestation committees
2. Each committee member independently scans the public mempool and assembles a short list of pending valid transactions they believe should be included
3. Committee members broadcast their individual inclusion lists across the peer-to-peer gossip network
4. Builders collect all received inclusion lists and must incorporate every listed transaction into the execution payload
5. Attesters independently verify whether the block satisfies the inclusion list conditions before casting their votes

Fork-Choice Enforcement

The key innovation in FOCIL is enforcement through the fork-choice rule rather than block validity alone. If a block fails to satisfy inclusion list requirements, attesters refuse to vote for it. Without sufficient attester votes, the block cannot accumulate enough weight to become canonical, and the chain forks away from it.

This makes censorship economically irrational: a builder who ignores the inclusion list produces a block that gets orphaned, wasting the block reward entirely. The builder gains nothing from censorship and loses everything.

Conditional Exemptions

Builders can legitimately omit an inclusion list transaction under specific conditions:

• The transaction has an invalid nonce because on-chain state changed after the list was created
• The sender no longer has sufficient balance to cover the transaction
• The block does not have enough remaining gas to fit the transaction (the block is already full)

These exemptions prevent inclusion lists from being weaponized to create invalid blocks. Builders must genuinely include listed transactions unless a legitimate state change makes inclusion impossible.

Comparison with Other Approaches

Inclusion lists are one piece of a broader censorship-resistance strategy. Several complementary approaches address different aspects of the problem:

Researchers describe FOCIL, enshrined PBS, and encrypted mempools as a "holy trinity" of censorship resistance. FOCIL forces transaction inclusion, enshrined PBS removes relay chokepoints, and encrypted mempools prevent builders from making content-based censorship decisions. Each addresses a different layer of the problem.

Why It Matters

Censorship resistance is a foundational property of public blockchains. If specific transactions can be reliably excluded, the network loses its credibility as a neutral settlement layer. This matters not only for Ethereum: any blockchain using a builder-proposer model faces similar risks, and inclusion list designs inform censorship-resistance thinking across the ecosystem.

For payment networks built on blockchain infrastructure, censorship resistance directly impacts reliability. A payment system where certain transactions can be silently dropped is fundamentally different from one where every valid transaction is guaranteed inclusion. Bitcoin Layer 2 networks like Spark benefit from Bitcoin's strong censorship resistance at the base layer, where the lack of a proposer-builder split means miners directly construct blocks and have economic incentives to include all fee-paying transactions.

The broader research into inclusion lists and forced inclusion mechanisms reflects a growing recognition that decentralization at the validator level is insufficient if block construction is centralized. Protocol-level guarantees are necessary to preserve the censorship-resistance properties that make blockchains useful as financial infrastructure.

Current Status and Roadmap

EIP-7805 (FOCIL) is currently in draft status. It was initially considered for the Glamsterdam upgrade but deferred to avoid bundling too many untested features into a single hard fork. FOCIL is scheduled as the consensus-layer headliner for the Hegota upgrade, targeted for mainnet deployment around mid-2027.

Alongside FOCIL, researchers continue exploring how encrypted mempools (such as the LUCID proposal in EIP-8184) could complement inclusion lists. LUCID depends on FOCIL as a prerequisite: inclusion lists force transactions into blocks, and encryption prevents builders from discriminating based on transaction contents.

For a deeper dive into how MEV extraction and proposer-builder dynamics shape Ethereum's validator economics, see Ethereum MEV, PBS, and Validator Economics.

Risks and Considerations

Validator Compliance Concerns

Inclusion list committee members may face legal or regulatory pressure to omit certain transactions from their lists. If validators in regulated jurisdictions are compelled not to include sanctioned transactions, the committee model's effectiveness depends on having sufficient geographic and jurisdictional diversity among committee members.

Committee Collusion

FOCIL requires corrupting a majority (9 or more) of the 16-member committee to censor a transaction. While this is significantly harder than bribing a single proposer, it is not impossible. If a large staking entity controls a substantial fraction of validators, they could appear on committees frequently enough to influence inclusion decisions.

Implementation Complexity

Adding committee-based inclusion lists introduces a new gossip network layer, new verification logic for attesters, and additional state that consensus clients must track. This complexity increases the attack surface and the burden on client development teams, which is why the feature has been developed cautiously across multiple upgrade cycles.

Builder Economics

Inclusion lists constrain builder flexibility in block construction. Mandatory transactions consume block space and gas that builders might otherwise allocate to higher-value MEV bundles. While this is the intended effect (preventing censorship), it may reduce builder revenue and could influence the competitive dynamics of the block building market.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.