The Problem With Letting Builders Drive

You submit a transaction. It sits in the mempool for three slots, four slots, five. No error. No rejection. Just silence, because somewhere upstream a block builder looked at your address, checked it against a compliance filter, and quietly dropped you. The validator got paid. You got nothing. And nobody left a fingerprint.

That's the power structure Ethereum handed to block builders when proposer-builder separation (PBS, the protocol pattern where validators propose blocks but specialist builders actually construct them) became dominant. Clean division of labor in theory. In practice, a handful of builders now assemble the overwhelming majority of Ethereum blocks. Estimates from MEV-Boost relay dashboards have repeatedly shown the top three or four builders producing upward of 80% of all blocks across extended measurement windows. When any entity controls what goes into a block, it controls what gets excluded from one too.

Inclusion lists are Ethereum's structural answer to that problem. Not a social norm. Not a gentlemen's agreement: a protocol-enforced mechanism that forces builders to include transactions validators have already committed to.

How an Inclusion List Actually Works

The mechanic is cleaner than it sounds. Before a validator proposes a block, it assembles a short list of transactions it believes should appear there, essentially staking its reputation on a set of pending transactions it observed in the mempool. The builder, who wants the validator's slot to publish its profitable block, must satisfy that list or the block is invalid.

The validator doesn't build anything. It just names names.

Here's a worked scenario. A validator's node sees a transaction from address `0xABC...` that has sat in the public mempool for two slots already. The validator adds it to its inclusion list. The winning builder, who might otherwise drop that transaction because the address appears on an OFAC sanctions list it filters against, now faces a binary choice: include the transaction and collect the block reward, or refuse and forfeit the slot entirely. A competing builder willing to comply wins the auction instead.

The key insight is that validators are far more geographically and jurisdictionally distributed than builders are. A validator running on a home staking setup in Portugal has no obvious legal incentive to filter for a U.S. regulatory list. Builders concentrated in data centers under specific jurisdictions do. Inclusion lists shift the censorship-resistance burden to the party that's structurally harder to coerce, which is exactly where it belongs.

Consider two stakers, Ana and Marcus, both running 32 ETH validators around the same time. Ana uses a large builder-integrated staking service that applies compliance filters. Marcus runs his own node. Without inclusion lists, Ana's service quietly drops the same transactions Marcus would happily include, and no one is the wiser. With inclusion lists enforced at the protocol level, Marcus's validator can force even Ana's preferred builder to include what it sees in the mempool, because Ana's service still bids through the open relay market and can be outbid by a builder willing to comply. Marcus's geographic distance from a particular regulator becomes, structurally, a shield for everyone.

The Auction Layer and Where It Gets Complicated

Inclusion lists don't eliminate the auction. Builders still compete on MEV (maximal extractable value, the profit available from reordering or inserting transactions) and priority fees. What changes is the constraint set they're optimizing within.

This introduces a subtle tension around list length and builder profitability. If a validator's inclusion list is long, or contains transactions that conflict with the builder's carefully assembled MEV bundle, the builder's optimal block becomes harder to construct. Builders may discount their bids on slots where the inclusion list is expensive to satisfy. Validators, who want maximum bid revenue, then face a soft incentive to keep their lists short and mild.

That's the honest friction in the design, and I think it's undersold in most writeups.

The proposed mitigations involve forward-inclusion semantics (the list applies to the next slot, giving builders time to plan around it) and capping list length at something like 16 transactions per slot, small enough that builders can satisfy it without wrecking their bundles. Sixteen transactions sounds trivial. Across 7,200 slots per day, though, that's over 100,000 guaranteed inclusion opportunities per day that bypass builder discretion entirely. It's less like a ceiling and more like a ratchet, a mechanism that keeps turning even when no one is watching.

Whether 16 is the right cap is still an active design question. Raise it and censorship resistance improves but builder revenue per slot drops. Lower it and the mechanism becomes cosmetic.

What Inclusion Lists Can't Fix

This is the part that gets glossed over in optimistic writeups, so pay attention.

Inclusion lists protect against transaction censorship: a builder refusing to include a specific pending transaction. They do nothing about state censorship, where a builder constructs a technically valid block but deliberately reorders transactions to harm a particular address, or sandwiches it so the transaction is economically worthless even if it lands on chain. Included doesn't mean unharmed.

They also don't address the scenario where builders collude to reject slots rather than comply with an inclusion list. If all major builders refuse a slot simultaneously, the validator either misses its proposal window or falls back to locally built blocks, which most validators aren't equipped to do competitively. Full enshrinement of PBS (ePBS, where the builder-proposer relationship is baked into the protocol rather than handled by the out-of-protocol MEV-Boost arrangement) is meant to address some of these failure modes, but that's a separate and longer conversation.

The mechanism also assumes validators are actually watching the mempool. A validator using a cloud service that abstracts away mempool access might never assemble a meaningful inclusion list at all. The protection is only as good as the validator's visibility into pending transactions, and right now that visibility varies wildly.

So: inclusion lists raise the cost of censorship significantly. They don't eliminate it. A determined, coordinated builder cartel with legal backing could still apply pressure, just more visibly and at greater economic cost than today.

That visibility is the real prize. Right now, builder censorship is nearly invisible. A transaction just doesn't get included and there's no obvious fingerprint. With inclusion lists, a builder that refuses a validator's list fails the slot in a way the protocol records. Censorship becomes legible. And legible censorship, the kind that leaves a mark, is politically and legally a different animal from the silent kind. That might be the most underrated property of the whole design: not that it stops bad behavior, but that it makes bad behavior undeniable.