The Problem With Letting Builders Run the Show
You submit a transaction. It's valid, properly funded, and the gas price is competitive. Then you watch six consecutive blocks land on-chain without touching it. Nothing is broken in any error-message sense. Nobody drained your wallet. But somewhere upstream, a quiet decision got made: you're not in this block. Or the next one. Or the one after that.
This is transaction censorship in Ethereum's post-Merge architecture, and it's structurally harder to prevent than most people assume. The reason comes down to one specific design choice: the separation of block proposers (validators, the nodes that formally add blocks to the chain) from block builders (specialized actors who actually assemble the transaction payload). That separation, called Proposer-Builder Separation or PBS, created enormous efficiency gains for MEV extraction. MEV, maximal extractable value, is the profit available to whoever controls transaction ordering inside a block. PBS also handed builders a new kind of power, and the community was slow to reckon with it.
Inclusion lists are the answer to that power. They don't collapse the auction. They don't redistribute MEV. They constrain the one thing builders should never have had: the ability to systematically erase specific addresses from the chain.
Why Builders Can Censor and Validators Can't Stop Them Alone
Under PBS as it runs today through MEV-Boost, a validator commits to using a builder's block if it pays the highest bid. The validator sees the bid amount and a block hash, not the transactions inside. Once they accept the bid, the full block is revealed and broadcast. The validator's rational move is almost always to accept the highest-paying block.
Builders know this.
A builder running under regulatory pressure, or simply choosing to comply with an OFAC-style sanctions list, can exclude certain addresses from every block they produce without the validator ever noticing. The validator isn't censoring. The validator is just taking the money. There's a difference, legally and morally, but the censored user can't feel it.
The aggregate effect is measurable. Researchers tracking the Ethereum mempool have observed that a significant fraction of all blocks produced through MEV-Boost came from builders applying some form of address filtering. The exact percentage has shifted as the builder landscape evolved, but the structural incentive never went away. A builder who filters faces no direct penalty. A validator who rejects a high-paying block to protest its contents loses real revenue.
So the censorship isn't malicious in the cartoon-villain sense. It's rational, diffuse, and nearly impossible to attribute to any single actor. That's actually what makes it dangerous: it hides inside ordinary economic behavior like a parasite that never kills its host.
How Inclusion Lists Actually Work
The core idea is elegant in the way that good protocol design usually is: give the validator the ability to demand that specific transactions appear in a block, before the builder has a chance to construct it.
The mechanism runs as follows. Before the block auction happens, the proposing validator assembles a short list of transactions pulled from the public mempool. These are transactions that are valid, properly funded, and have been waiting long enough that excluding them looks suspicious. The validator broadcasts this list. Any block built for that slot must include every transaction on that list, or it is invalid. Full stop.
Builders still compete. The auction still runs. The winning builder still collects the MEV. But they must incorporate the validator's required transactions, or their block gets rejected by the network regardless of how high they bid.
The validator, in this design, doesn't need to build a block. They just need to read the mempool and flag a handful of transactions. That's a much lighter computational task, which matters because one goal of PBS was precisely to keep validator requirements manageable.
Work through a concrete example. A validator is scheduled to propose in slot 8,450,211. Before the builder auction closes, they scan the mempool and find three transactions that have each been waiting more than two minutes, all from addresses with no apparent sanctions exposure. They publish an inclusion list containing those three transactions. Builder X wins the auction with the highest bid. Builder X's block, however, omits transaction two. The network rejects Builder X's block as invalid. Builder Y's block, which includes all three, is accepted instead, even though Builder Y's bid was slightly lower.
The validator still earns revenue. The builder still extracts MEV. The censored transaction gets in.
The Design Tensions That Make This Hard
Anyone who tells you inclusion lists are a clean, solved problem is selling something.
The first tension is what researchers call the free-rider problem on the inclusion list itself. If a validator can force transactions in, a validator under its own regulatory pressure might publish an empty list, or a trivially short one, and pocket the bid without doing the work. The protocol needs some mechanism to make empty lists costly, or the guarantee becomes hollow. Current proposals debate whether inclusion lists should have minimum length requirements, or whether social and economic pressure from the broader validator set is sufficient. I'd argue that social pressure alone is not sufficient. The history of optional compliance mechanisms in blockchain design is a history of slow erosion.
The second tension is griefing. A malicious validator could stuff the inclusion list with high-gas, complex transactions specifically designed to make block construction expensive for builders, reducing builder profit and therefore MEV revenue flowing back to validators. It's a self-defeating attack, but it's a real design surface that proposals have to close.
The third tension, and the most technically interesting, is timing. For inclusion lists to work, the validator must publish their list before the builder finishes constructing the block. But if the validator publishes too early, builders can front-run the listed transactions, placing their own trades around them to extract value before committing to include them. The window is narrow. Several EIP-level proposals have suggested cryptographic commitments to obscure the list's contents until just before the builder deadline, though this adds meaningful complexity.
There's also a subtler issue that deserves explicit acknowledgment: inclusion lists constrain who can be excluded, but they don't constrain how included transactions are ordered. A builder can still sandwich a required transaction. Censorship resistance and MEV protection are different problems. Inclusion lists only address the first one, and conflating the two leads to disappointed users who thought they were getting more than they were.
The Version That's Actually Being Built
The proposal with the most traction in Ethereum research circles is called FOCIL: Fork-Choice Enforced Inclusion Lists. The key feature is that enforcement happens at the fork-choice layer. A block that ignores a published inclusion list doesn't just fail a local validity check; it loses fork-choice weight and gets orphaned by the network. That makes censorship economically punishing rather than merely technically irregular.
FOCIL also distributes the list-publishing role across a committee of validators rather than a single proposer. Multiple validators each contribute a partial list, and the union of those lists must be satisfied. This matters because it dramatically raises the bar for censorship: you'd need a significant fraction of the committee to collude around the same filter, not just one builder deciding to skip an address.
The committee-based approach also reduces the griefing surface. No single actor controls the whole list, so a coordinated stuffing attack requires committee-level coordination, which is a much harder thing to organize quietly.
None of this is deployed on mainnet yet, but the research has progressed from whiteboard sketch to detailed EIP-level specification, with active testing in devnets. The direction is set. The open questions are implementation details, not conceptual ones.
What This Actually Fixes (and What It Doesn't)
The distinction matters, because imprecision breeds disappointment.
Inclusion lists, implemented well, fix persistent, systematic censorship by builders. If a builder consistently refuses to include transactions from a specific address or contract, a functioning inclusion list regime makes that strategy fail. The transaction gets in via the list, the builder still wins the auction, and the censorship achieves nothing.
What inclusion lists don't fix: short-term, slot-level exclusion. A transaction submitted one second before the inclusion list was published might still miss that slot. A brief delay is not the same as systematic exclusion, and the protocol isn't designed to guarantee zero-latency inclusion.
They also don't fix validator-level censorship. A validator who refuses to publish any inclusion list, or who publishes a deliberately empty one, is harder to constrain. The mechanisms for addressing that are weaker than cryptographic enforcement.
And they don't touch MEV ordering. Your transaction gets in. It might still get sandwiched.
So ask yourself what you actually want from this mechanism. If the answer is "a guarantee that no well-funded, valid transaction can be quietly erased from the chain by a builder with a compliance checklist," inclusion lists deliver that. If the answer is "complete protection from all forms of value extraction," you're describing a different and much harder problem.
Inclusion lists are a targeted, well-scoped tool for a specific problem. They preserve the economic structure that makes Ethereum's block production efficient, while closing the loophole that let builders act as quiet gatekeepers. The auction survives. The censorship doesn't get to.