An Inclusion List is a blockchain mechanism that allows a designated participant, typically a block proposer, to specify transactions that should be included in a block constructed by another party. In Ethereum research, Inclusion Lists are primarily discussed as a way to preserve censorship resistance in a block production architecture where specialised builders determine most of a block’s contents.
The concept is closely connected to Proposer-Builder Separation (PBS). When builders construct blocks, proposers no longer directly control every transaction included in the block they propose. This improves specialisation but creates a potential problem: a dominant builder could repeatedly exclude valid transactions.
An Inclusion List gives some transaction-inclusion authority back to the proposer without requiring it to construct the entire block. The proposer identifies eligible transactions that should appear, while the builder remains free to optimise the rest of the block around those requirements.
The objective is therefore not to replace builders or dictate complete transaction ordering. It is to create a censorship-resistance safeguard inside a specialised block-building system.
Why Inclusion Lists Are Needed
Ethereum block construction increasingly involves specialised infrastructure. Builders can combine public transactions, private order flow, and MEV bundles to produce economically competitive blocks.
This model can improve efficiency, but it concentrates transaction selection in the builder market. If a small number of builders consistently win block auctions, they can gain considerable influence over which transactions reach the chain.
A builder might exclude transactions for regulatory, economic, technical, or strategic reasons. Occasional exclusion is not necessarily censorship because blocks have finite capacity and transactions compete for inclusion. The more serious problem appears when an eligible transaction is repeatedly ignored even though users are offering appropriate fees.
Inclusion Lists are designed to make sustained censorship harder.
Instead of relying entirely on the builder’s transaction selection, the proposer can observe transactions independently and identify some that should be included. The builder then has to respect those requirements when constructing the relevant block, subject to the exact rules of the protocol design.
This creates a division of responsibilities: builders retain most block optimisation power, while proposers preserve a limited ability to protect transaction inclusion.
How an Inclusion List Can Work
There is no single universal Inclusion List design. Ethereum researchers have explored different variants, and details such as timing, list size, eligibility rules, and enforcement can vary.
At a high level, the mechanism works by adding transaction constraints to the builder-proposer relationship.
A simplified model can be represented as follows:
- A proposer observes pending Ethereum transactions.
- The proposer selects eligible transactions according to the Inclusion List rules.
- The proposer commits to or publishes the list.
- A builder constructs a block while accounting for the listed transactions.
- The builder provides evidence that the inclusion requirements have been respected.
- The proposer publishes the resulting block according to Ethereum’s normal block production process.
The critical point is that the proposer does not need to optimise the entire block. It only contributes information about transactions that should not be censored.
The builder can still decide how to combine ordinary transactions, MEV bundles, private order flow, and other inputs within the remaining block capacity. This preserves much of the economic benefit of specialised block building.
Protocol enforcement is essential. If builders can ignore Inclusion Lists without consequence, the mechanism provides little protection. A practical design therefore needs rules defining when a transaction is eligible, when omission is justified, and how compliance can be verified.
Inclusion Lists vs Normal Block Selection
An Inclusion List should not be confused with a complete block template or an alternative mempool.
Its purpose is deliberately narrower. It constrains block construction rather than replacing it.
| Feature | Normal Builder Selection | Inclusion List |
| Primary participant | Block builder | Usually proposer |
| Main purpose | Construct an economically competitive block | Protect transaction inclusion |
| Determines entire block | Potentially | No |
| Optimises MEV | Yes | Not the primary purpose |
| Selects mandatory transactions | Not necessarily | Yes, within protocol rules |
| Censorship-resistance role | Depends on builder behaviour | Explicit objective |
| Requires full block construction | Yes | No |
| Relationship with PBS | Core builder function | Constraint on builder power |
This distinction is important because forcing proposers to construct substantial parts of blocks would weaken the purpose of PBS. Validators would once again need more sophisticated infrastructure and would compete directly with professional builders.
An effective Inclusion List should require relatively little additional work from proposers while still giving censored transactions a credible route into blocks.
What Counts as an Eligible Transaction?
One of the difficult design questions is determining which transactions proposers should be allowed to require.
A proposer cannot simply demand arbitrary transactions without constraints. A transaction might be invalid, use a stale nonce, depend on state that has already changed, or require more gas than remains available in the block.
Transactions can also conflict with one another. A transaction that was valid when the Inclusion List was created may no longer be executable after other state changes.
For this reason, Inclusion List designs need precise eligibility and validity rules.
Relevant conditions can include:
- whether the transaction was visible to the proposer at the required time;
- whether it pays the minimum fees required for execution;
- whether it was valid against the relevant Ethereum state;
- whether sufficient block gas remains available;
- whether another included transaction has made it invalid;
- whether the transaction has already been included elsewhere;
- whether the proposer followed limits on the number or size of listed transactions.
These restrictions protect builders from impossible requirements and prevent proposers from using Inclusion Lists to disrupt block production.
They also show why the concept is technically more complicated than simply creating a list of transaction hashes.
Inclusion Lists and Censorship Resistance
The main security objective of an Inclusion List is to reduce the ability of builders to sustain transaction censorship.
Imagine that a transaction remains in the public mempool while several dominant builders refuse to include it. If proposers only select the highest-paying builder block, the transaction could remain excluded even though many validators themselves have no intention of censoring it.
An Inclusion List allows an independent proposer to intervene. When that validator receives a proposal opportunity, it can identify the transaction and require its inclusion under the applicable rules.
This changes the economics of censorship. A censoring builder may have to either include the transaction or lose access to block proposal opportunities where Inclusion Lists require it.
The mechanism is particularly valuable when builder concentration is higher than validator concentration. Ethereum may have a widely distributed validator set even if block construction is dominated by relatively few professional builders. Inclusion Lists can use that validator diversity as a defence against concentrated builder policies.
They do not make censorship impossible. Their effectiveness depends on proposer behaviour, network visibility, protocol design, and the proportion of participants willing to use the mechanism correctly.
Interaction with MEV and Block Capacity
Mandatory inclusion can affect block optimisation because builders normally want flexibility to choose the most valuable combination of transactions.
If an Inclusion List consumes part of the available gas, the builder has less capacity for other transactions or MEV bundles. In extreme designs, overly large lists could significantly interfere with the builder market.
This creates a balancing problem.
Lists must be large enough to provide meaningful censorship resistance but constrained enough that proposers cannot effectively take over block construction or intentionally reduce builder revenue.
MEV also introduces transaction dependencies. A listed transaction might interact with a searcher bundle or change a decentralised exchange price. Builders need rules explaining whether and how they can place other transactions around required transactions.
For this reason, Inclusion Lists are primarily about inclusion rather than guaranteeing a specific execution position. Requiring a transaction to appear is different from requiring it to execute at an exact point in the block.
That distinction reduces the amount of ordering authority transferred back to proposers.
Inclusion Lists in Ethereum’s PBS Direction
Inclusion Lists are especially relevant to Ethereum’s longer-term work on proposer-builder separation.
External PBS infrastructure such as MEV-Boost demonstrated the economic benefits of specialised block builders, but it also highlighted the importance of block-builder concentration and censorship. Moving more of the builder-proposer relationship into Ethereum’s protocol creates an opportunity to address these issues directly.
A protocol-level PBS design can separate block construction from proposal while explicitly preserving proposer agency through mechanisms such as Inclusion Lists.
This is different from relying solely on market competition. A competitive builder market can reduce censorship risks, but competition does not guarantee neutrality if major builders follow similar exclusion policies or depend on the same private order-flow ecosystem.
Inclusion Lists instead create a protocol mechanism through which transaction inclusion can remain influenced by Ethereum’s broader validator population.
The exact design is still a matter of protocol engineering and research. Different proposals vary in when lists are created, how builders prove compliance, and what happens when transactions become invalid before execution.
Why Inclusion Lists Matter
Inclusion Lists address a specific consequence of specialised block building: efficiency can increase while control over transaction inclusion becomes concentrated.
PBS allows builders to focus on sophisticated block optimisation while validators remain relatively simple proposers. That separation is useful, but Ethereum also needs a way to prevent the builder role from becoming an effective censorship gatekeeper.
An Inclusion List attempts to preserve both advantages. Builders can continue constructing economically optimised blocks, while proposers retain limited authority to ensure that valid transactions are not indefinitely excluded.
The mechanism therefore sits at the intersection of MEV, PBS, validator decentralisation, and censorship resistance. Its purpose is not to make proposers responsible for block building again, but to ensure that outsourcing block construction does not mean outsourcing all control over who can transact.
As Ethereum’s block production architecture evolves, Inclusion Lists represent one approach to maintaining credible neutrality while preserving the efficiency benefits of specialised builders.