Inclusion List

An inclusion list is a cryptographically signed list of pending transactions that a validator or block proposer mandates a block builder to include in the next block. This mechanism is a core component of proposer-builder separation (PBS) architectures, acting as a countermeasure against censorship by ensuring that certain transactions cannot be arbitrarily excluded. The proposer, who holds the right to propose the next block, creates the list from the mempool and passes it to the builder, who must incorporate these transactions or forfeit the block-building opportunity.

The primary technical goal is to enforce transaction inclusion guarantees. Without an inclusion list, a block builder could censor transactions based on origin, content, or gas price. By requiring specific transactions to be included, the system protects against Maximal Extractable Value (MEV) exploitation tactics like time-bandit attacks and ensures a base level of fair ordering. Protocols like Ethereum implement this through mechanisms such as the proposer-builder separation (PBS) with crLists (censorship resistance lists), where validators can force the inclusion of transactions that have been pending for too long.

Implementing an inclusion list involves a delicate balance. It must be privacy-preserving to prevent builders from front-running the listed transactions, often achieved through commitments or encryption until the block is revealed. Furthermore, it must respect the builder's autonomy over block construction for economic efficiency. The list typically specifies which transactions must be included but not where in the block, allowing builders to optimize ordering around them for fee maximization and MEV extraction, provided they do not invalidate the mandated transactions.

From a network health perspective, inclusion lists are a critical anti-censorship tool. They ensure that transactions from sanctioned addresses or competing MEV searchers cannot be systematically filtered out by dominant block-building entities. This promotes decentralization and credible neutrality at the protocol level. Their design is a direct response to the centralizing pressures of professionalized block building, making the blockchain more resilient against both malicious and profit-driven exclusion of valid transactions.

The evolution of inclusion lists is closely tied to Ethereum's roadmap. Post-The Merge, with the separation of consensus and execution layers, inclusion lists like those proposed in EIP-7547 provide a standardized way for consensus-layer validators to exert influence over execution-layer block content. This represents a shift from pure first-price auction models to a hybrid system that enforces social and protocol-level guarantees without completely sacrificing the efficiency gains of specialized block builders.

An inclusion list is a cryptographically signed list of pending transactions that a block proposer is required to include in the next block they produce. This mechanism, also known as a transaction inclusion list or block inclusion list, is a core component of proposer-builder separation (PBS) architectures like those in Ethereum. It acts as a countermeasure against censorship by preventing validators from arbitrarily excluding transactions, such as those from decentralized exchanges or privacy tools, from the mempool. The list is typically submitted by searchers or users to the current block proposer, who must incorporate it to remain compliant with the network's consensus rules.

The operational flow begins when a user or a specialized network participant, often called a committer, creates a list of transaction hashes they want guaranteed inclusion. This list is signed and transmitted to the block proposer for the upcoming slot. In systems like Ethereum, this is facilitated by a dedicated inclusion list endpoint on the validator client. The proposer is then obligated to add these transactions to the block's execution payload, provided they are valid (e.g., have sufficient gas and correct nonces). Failure to include a valid list can result in the proposer being slashed or penalized, enforcing protocol-level anti-censorship guarantees.

Inclusion lists directly address the maximal extractable value (MEV) concern of censorship. Without them, a block builder could ignore transactions that reduce their potential MEV profits. By mandating inclusion, the protocol ensures a base level of transaction liveness and fairness. This is particularly vital for time-sensitive DeFi arbitrage trades or liquidations, where delayed inclusion could lead to significant financial loss. The design represents a shift from a purely free-market model of block space allocation to one with enforceable social commitments embedded in the consensus layer.

Implementing an inclusion list requires careful protocol design to balance efficiency and security. Key challenges include determining the maximum list size (to prevent denial-of-service attacks), handling transactions that become invalid between list submission and block execution, and defining clear slashing conditions. Proposals like EIP-7547 for Ethereum formalize these specifications. The list does not dictate the order of transactions—only their inclusion—leaving the block builder free to optimize ordering for MEV capture around these mandatory items, thus preserving some economic efficiency for validators.

The long-term evolution of inclusion lists may see them integrated with other anti-censorship tools like crLists (censorship-resistant lists) or encrypted mempools. As a foundational credible neutrality tool, they ensure the base layer cannot be easily coerced into filtering specific transaction types. For developers, understanding inclusion lists is crucial for building applications that require reliable transaction settlement, as it defines the minimum guarantee their users have against being silently censored by the network's validators.

An inclusion list is a cryptoeconomic mechanism, most notably implemented in Ethereum's proposer-builder separation (PBS) framework, that grants a block proposer (or validator) the exclusive right to force the inclusion of certain transactions into the next block. This right is enforced at the protocol level, acting as a counterbalance to potential censorship by block builders who assemble block contents. By mandating that transactions on the list must be included if they are valid and pay sufficient fees, the system creates a credible threat that disincentivizes builders from filtering out transactions for non-economic reasons, thereby strengthening network neutrality.

The operational flow involves two key roles: the block proposer, who is randomly selected to sign off on a block, and the block builder, who constructs the block's contents for maximum profit. In a system with an inclusion list, the proposer can submit a list of pending transactions to the builder. The builder must then include all transactions from that list which are still valid and have met a minimum bid, or else forfeit the block. This creates a commitment device, ensuring that even if a builder wishes to censor certain transactions, the economic incentive to win the block auction will compel compliance with the proposer's list.

This mechanism addresses critical issues in modern blockchain design. Primarily, it mitigates censorship resistance risks by preventing builders from systematically excluding transactions based on origin or content. Secondly, it improves proposer economics; in pure PBS, proposers merely sell block space and capture minimal value, but with inclusion lists, they can extract more value by selling guaranteed inclusion, making the validator role more sustainable. The design is a direct response to concerns about centralized mev-boost relays potentially engaging in transaction filtering.

Implementation specifics can vary, with proposals like MEV-Boost++ exploring different models. A common approach is a pre-confirmation system, where users can pay the proposer directly for a slot on the list, receiving a cryptographic guarantee their transaction will be in the next block. Alternative designs may allow proposers to specify a tail gas reservation in the block header, which builders must fill with the highest-fee transactions from a public mempool, ensuring fee market efficiency isn't compromised.

The development of inclusion lists represents a significant evolution in blockchain governance, shifting from pure fee-market dynamics to a structured rights-based allocation of block space. It exemplifies how protocol design can embed economic and social values—like censorship resistance and fair access—directly into the consensus layer, creating robust incentives that align the interests of builders, proposers, and end-users without requiring off-protocol coordination or trust.