Ethereum Inclusion Lists: Constraining Builder Censorship Without Losing Builder Specialization
Your transaction has been sitting in the mempool for forty blocks. MEV bots have been served. Arbitrageurs have been served. You have not. You start wondering whether the problem is your gas price, and then you notice the address involved, and then you realize the problem is something else entirely: you never had a seat at the table to begin with.
Who actually decides what goes into an Ethereum block? Post-Merge, the answer is complicated. The fix being built around it, inclusion lists, is more elegant than most people realize.
The Problem Is Structural, Not Moral
Ethereum's current block production splits responsibilities between validators and builders. Validators propose blocks; builders construct them. This is proposer-builder separation, PBS, and it exists because building a maximally profitable block requires serious infrastructure: real-time mempool scanning, MEV simulation, relationships with searchers, low-latency connections to major DeFi protocols. Most home validators running a node on consumer hardware have none of that. Builders do.
The arrangement works well for efficiency. It works badly for censorship resistance.
A builder can exclude transactions from addresses flagged by OFAC sanctions lists, from protocols they dislike, from users who won't meet their preferred fee structure. The validator receiving the block header sees a bid, checks validity, and signs. They never see the individual transactions inside. They cannot easily tell what was left out.
This is not hypothetical. After the Tornado Cash sanctions, multiple major block builders began excluding Tornado-linked transactions. At peak, over 70% of Ethereum blocks were being produced by entities applying some form of transaction filtering. The chain kept running, yes. But a meaningful fraction of its block space was operating under discretionary editorial control. That should bother you more than it apparently bothers some people.
What an Inclusion List Actually Does
An inclusion list lets a validator assert: these specific transactions must appear somewhere in the next block, or the block is invalid.
The validator compiles the list before the block is built, pulling transactions from the public mempool that meet basic validity thresholds (correct nonce, sufficient base fee, not already included in a recent block). They attach this list to their slot. Whoever wins the MEV-boost auction must then incorporate those transactions into the block they construct.
The builder still does everything they normally do. Still runs the simulation stack. Still optimizes for MEV. Still arranges transactions in whatever order maximizes their bid. They just cannot exclude the validator's listed transactions. The editorial veto is removed. The specialization is not.
Think of it like a water main with a guaranteed flow minimum: the municipal engineer can still optimize pressure and routing across the whole system, but certain pipes cannot be shut off at will. The expertise is intact. The kill switch is gone.
A Worked Scenario
Two validators. Amara runs a large staking operation with 50,000 ETH delegated to her node, sophisticated tooling, and a compliance policy that mirrors her builder's OFAC filtering. Tomas runs a solo validator, 32 ETH, consumer hardware, a strong opinion about censorship resistance.
Under current PBS, both validators simply accept or reject the highest MEV-boost bid. Neither inspects the contents. Amara's builder filters transactions; Tomas's builder might too, depending on which relay he uses. The user whose Tornado-linked transaction is excluded has no recourse except to wait for a non-filtering slot, hoping one appears before they give up.
With inclusion lists active, Tomas scans the mempool before his slot. He finds five pending transactions that have been waiting more than 12 blocks, including one from the excluded address. He adds them to his inclusion list. His builder, still winning the auction on bid value, must include those five transactions somewhere in the block. The user gets in.
Amara can still choose not to compile an inclusion list, or compile one that conveniently excludes the same transactions her builder would. The mechanism does not coerce validators; it empowers the ones willing to use it. Even 20 to 30 percent validator participation would meaningfully disrupt any coordinated filtering campaign, because an excluded transaction would eventually land in an inclusion-list-active slot.
That is the decisive point. Censorship requires near-universal builder cooperation. Inclusion lists only require minority validator participation to make that coordination fail.
The Design Constraints That Make This Hard
Getting inclusion lists right is technically fiddly. The Ethereum research community has produced several spec iterations precisely because naive implementations break things.
The core tension: the list is compiled before the builder constructs the block. By the time the block is built, some listed transactions may have become invalid (a conflicting transaction landed, the account nonce advanced, the base fee moved). If the rule is a strict "all listed transactions must appear or the block is invalid," a builder facing one invalidated entry mid-slot might have no valid block to produce. Missed slot. Bad.
The working design, sometimes called forward inclusion lists or the EIP-7547 approach, distinguishes between the summary (the list the validator publishes) and the block's obligation to satisfy it. Listed transactions must be included unless they've become invalid for objective, verifiable reasons. The validator attests to the list's validity at compilation time; the builder handles conflicts. The rules for legitimate exclusion are narrow and checkable on-chain.
Size is also a constraint. A validator could theoretically compile an enormous list, forcing builders to fill the block with low-fee transactions and collapsing their bid value. Current proposals cap list size and require listed transactions to meet minimum fee thresholds. Keeps the mechanism proportionate.
One honest limitation: inclusion lists constrain builders operating through the public MEV-boost relay system. A validator building their own blocks entirely in-house, without any external builder, sits outside this mechanism. That is a small fraction of blocks today. It is still a gap, and pretending otherwise would be sloppy.
Not a Complete Answer, But a Real One
Inclusion lists will not eliminate censorship from Ethereum. A sufficiently motivated validator can ignore them, compile trivially empty lists, or choose relays that don't enforce them. The mechanism is permissive, not mandatory, and it depends on a meaningful fraction of validators actually caring enough about censorship resistance to run the extra logic. Whether that fraction materializes is a social question, not a technical one, and social questions are harder.
What inclusion lists do accomplish is structural: they break the clean separation between "validator signs" and "builder chooses." Validator agency over block contents is reintroduced without dismantling the efficiency gains PBS was designed to capture. The builder still wins on merit. The validator gets a veto over omissions, not additions.
For a protocol processing billions of dollars in transactions and positioning itself as neutral infrastructure, that distinction is not a footnote. It is load-bearing.