# Inclusion list and out of protocol market risks

Today I learned two things:

- 99% of validators have used mev-boost at some point. (h/t dataalways: https://x.com/Data_Always/status/1841244184927486062)
- Consensus layer clients don’t need any changes to support "IL-boost." Instead of directing the CL client's execution endpoint to a local EL, it can be pointed to a multiplexer that handles inclusion list calls through a pre-confirmation gateway or a third-party out-of-protocol market allocation service. (h/t potuz)

Now, based on what I've learned, I'm increasingly concerned that any inclusion list design could create a wide opening for out-of-protocol markets. While I'm using [FOCIL](https://ethresear.ch/t/fork-choice-enforced-inclusion-lists-focil-a-simple-committee-based-inclusion-list-proposal/19870) as an example, this issue isn't specific to FOCIL—it's a paradox that any in-protocol inclusion list design is likely to face.

We assume the following inclusion list design:

- A committee of size $N$ at slot $n$, where each member can enforce the proposer of slot $n+1$ to include a list of transactions.
- The proposer has the flexibility to include the transactions in any order.
- The proposer is not required to include all the transactions if the block becomes full.
- The proposer is not required to include any transactions that cannot be processed when appended to the end of the block body.
- The inclusion list transaction functions as a normal Ethereum transaction, where the base fee is burned and the tip goes to the block proposer. The IL committee does not receive any in-protocol rewards or tips.

Then we assume the following market setup:

- There exists a middleware design that allows the node operator to connect their beacon node to the middleware using the `execution-layer-endpoint`. The middleware also connects to the local execution layer client. It uses the local execution layer for all engine API endpoints, while relying on an out-of-protocol exchange service gateway for new inclusion-list-related endpoints.
- Transactions processed through the gateway pay the IL committee members out of protocol and no longer pay the priority fee for the transaction.
- The transaction is simple and does not guarantee pre- or post-execution conditions, only ensuring inclusion.
- Given how easy it is to set up by simply using middleware, which requires no changes to the consensus layer client, and the fact that IL committee members can earn additional fees by offering inclusion list services (potentially useful for pre-confirmation), we may see a mev-boost-like effect, with usage rates for IL-boost approaching those of mev-boost.

Now that you've read this far, I know I’ve painted a pessimistic outlook, but I think it's better to be honest upfront and face these questions head-on. Here are some open thoughts to consider:

- Why would anyone pay a priority fee for a transaction if they can simply pay an IL committee member out of protocol to guarantee inclusion in the next slot? In a sense, this feels like the IL committee is siphoning revenue from the proposer. Sure, the proposer could always stuff their block, but would they be willing to pay the cost to do this? Are there other mitigations in place to prevent this from happening?
- MEV-boost reached 98% usage, as we’ve seen. Should we assume that an out-of-protocol IL-boost would reach similarly high usage? Could this lead to a "time game" effect, where once one party starts using it, others feel compelled to follow? What is the Nash equilibrium in this scenario?
- Would legitimate companies like Coinbase Staking use IL to sell pre-confirmation? Would Lido DAO mandate that its operators adopt a similar approach?
- I don’t think relying on social consensus is a viable answer here, so we shouldn’t argue that if someone uses IL-boost, social consensus will step in and punish them.
- How much liveness or safety risk does IL middleware introduce to the protocol? Additionally, how much does it harm client diversity if a middleware bug prevents the beacon node from communicating with the local EL client?

These are important questions that need to be addressed before we move forward with any inclusion list design.