This post was inspired by discussions with Thomas Thiery, Barnabé Monnot, Francesco D’Amato, and Maneesha Papireddygari.

Inclusion lists (ILs) are a design philosophy that allows validators to provide input in block construction even when most validators outsource execution payload construction to a centralized set of builders. Validators outsource execution payload construction rights for three main reasons:

• Construction of valuable execution payloads requires sophistication. It is computationally difficult to construct the most valuable execution payload, and the payoff increases with the sophistication of the extraction strategies block producers use. Validators are not sophisticated and are not good at producing the most valuable execution payloads.

• There are high barriers to entry to become a competitive block producer. Not only would an entrant aspiring to become a competitive block producer need to gain a similar level of sophistication in terms of MEV strategies other builders have, but the entrant also needs to acquire exclusive order flow, which likely requires a significant investment and the entrant needs to be trusted by the order flow originators.

• It is individually profitable for a validator to outsource execution payload construction to a builder because the average payoff from outsourcing to a builder is about four times the average payoff a validator could have gotten by itself.

This out-of-protocol market for outsourcing execution payloads, MEV-Boost, has an incredibly high adoption rate and many externalities on Ethereum. One important externality is that Ethereum's credible neutrality degraded because some sophisticated builders would not include transactions at their own will. Inclusion lists combat this externality by allowing (multiple) validators to input into block construction.

The efficacy of any inclusion list design relies on the fact that members from the decentralized validator set have a say in block construction and that these members do not outsource their inclusion list construction rights to some centralized set of agents, similar to the MEV-Boost market. It is logical to ask whether the ecosystem expects inclusion lists to be effective or whether the design might also succumb to market forces, leading to validators outsourcing their inclusion list construction rights to a centralized set of agents.

This question has been studied in general before. An inclusion list design that is well-suited to prevent outsourcing of inclusion list construction rights to a centralized set of agents is called uncrowdable. Suppose a valuable use for inclusion lists differs from the protocol's intended use case; this valuable use case crowds out the inclusion list design.

Fork-Choice enforced Inclusion Lists, better known as FOCIL, is the latest inclusion list design. On a high level, it appoints multiple validators to be inclusion list committee members. Each committee member constructs a list of transactions, its local inclusion list. The block producer then aggregates the transactions from these local inclusion lists. The validity of the execution payload depends on whether all of the transactions referenced in all the local inclusion lists have been included. The attesters enforce this validity condition.

FOCIL is specifically designed to be uncrowdable. This post presents the argument as to why this is the case. The argument relies on three observations that collectively show there is no incentive to outsource inclusion list construction to a centralized set of agents. The observations are that agents in FOCIL do not benefit from sophistication, that there are no barriers to entry to be a FOCIL committee member, and that deviating from the protocol prescribed strategy is not individually profitable.

First, FOCIL does not require or reward the sophistication of the local IL creator. IL committee members cannot determine the ordering of transactions (anywhere-in-block property), nor can they guarantee transaction inclusion when there is congestion (conditional property). This means transactions in local ILs do not have preferential treatment over other transactions. For any non-censored transaction, the transaction originator would be equally well off by sending their transaction into the public mempool and sending it to an IL committee member. Therefore, IL committee members are not rewarded for using sophisticated strategies to determine how to create their local IL.

Secondly, the high barriers to entry that entrants in the MEV-Boost market face do not apply to IL committee members. The largest barriers to entry are sophistication and acquiring exclusive order flow. As previously argued, sophistication is not rewarded in IL creation. Acquiring exclusive order flow is also unnecessary in FOCIL since FOCIL does not allow for exclusive order flow. Any transaction included in a local IL is publicly broadcasted. The block producer is free to include this transaction anywhere in the block, meaning there is no advantage to sending a transaction privately to an IL committee member over sending it to the public mempool.

These two observations imply that all validators and more sophisticated agents can create inclusion lists equally well. Therefore, there is no reason for a validator to outsource its inclusion list construction duties to a more sophisticated party. Consequently, no clear market forces lead to the centralization of inclusion list construction duties. Alternatively, if there were to exist a market for inclusion list construction rights, the set of buyers in this market is likely to be decentralized and numerous.

Thirdly, since there is no individual profitable deviation from the honest protocol strategy, there will likely be no market for inclusion list construction rights. In FOCIL, inclusion list committee members do not receive a transaction fee for including transactions in their local IL (although this may change in future iterations). Moreover, an individual IL committee member cannot provide better inclusion guarantees to a user than the public mempool provides. The EIP-1559 transaction fee mechanism ensures that a non-censored and valid transaction will be included in the next block as long as there is no congestion. A transaction censored by the block producer could be included in any local IL; hence, an individual IL committee member cannot state that a transaction is included if and only if the individual IL committee member includes the transaction in its local IL. Since an individual IL committee member cannot improve a user’s inclusion guarantees, no user will be willing to pay for inclusion in an individual local IL. Therefore, there is no deviation from the honest protocol strategy a committee member could make to increase its profits.

IL committee members and the proposer could collude only to include transactions that pay an inclusion fee, which would profit IL committee members. This is where an inclusion list creation market fundamentally differs from the execution payload construction market. The former relies on collusion to be profitable, whereas the latter is individually profitable. Importantly, however, the Ethereum ecosystem has not seen middleware deployed to facilitate collusion, even though validators could profit from collusion in multiple known ways.

Finally, if such a collusion were set up, the inclusion fee would be close to zero by competition. Since IL committee members and proposers do not often interact jointly, it can be considered a single-shot game. Consider a user who wants to include their transaction at the lowest fee. It could host an auction in which the transaction fee rises until the first IL committee member or the proposer takes the transaction fee and includes the transaction (a Dutch procurement auction). Since including a transaction comes at practically no cost to IL committee members, they will be incentivized to take the fee as soon as possible, meaning the inclusion fee a user would have to pay would be close to zero.

In short, there is no individually profitable way to outsource inclusion list construction rights. If such rights were outsourced, collusion would be required to be valuable. Such a collusion is likely unstable. Finally, even if the unstable collusion were to hold, the buyers of the inclusion list construction rights would likely be decentralized and numerous. Therefore, outsourcing inclusion list construction rights is not a concern in the FOCIL design, and FOCIL seems very uncrowdable.