PBS & Inclusion Lists: Enforcing Censorship Resistance
Proposer builder separation inclusion list mechanisms are transforming how Ethereum resists censorship. By coupling the efficiency of PBS with a mandatory inclusion list (IL) that the proposer can enforce, the protocol ensures that no builder can censor a transaction without risking severe penalties. This guide explores the game theory, concrete proposals like FOCIL and ePBS, and why this design is critical for permissionless access to the network.
In today’s MEV-Boost system, relay operators and builders can selectively drop transactions, often due to OFAC compliance or profit motives. The proposer builder separation inclusion list proposal flips the dynamic: the proposer—the one with the ultimate authority to propose a block—can commit to including certain transactions. Builders then compete to construct the block around that list, knowing that failure to include those transactions will invalidate their submission. This builds censorship resistance directly into the market design.
- Proposer builder separation inclusion list is the leading proposal to enforce censorship resistance without sacrificing MEV efficiency.
- Inclusion lists give the proposer a credible threat: miss my txs, lose the whole block reward.
- Current MEV-Boost relies on trusted relays; ePBS with ILs removes this trust assumption.
- FOCIL and BRAID are concrete protocol designs incorporating mandatory inclusion lists.
- The game theory ensures builders include the list because the cost of censoring is higher than any potential gain.
- Adoption requires careful handling of latency, proposer MEV extraction, and builder regret, but the net effect is a more neutral Ethereum.
What Problem Does Proposer-Builder Separation Solve?
Proposer-builder separation (PBS) was originally proposed to democratize MEV extraction. Without PBS, a single validator who wins a proposal slot must also compute the most profitable block, giving an advantage to sophisticated actors with advanced order-flow. PBS splits the roles: a builder constructs the block (with complex MEV strategies) and a proposer simply selects the best header. Flashbots’ MEV-Boost implements PBS via relays, but relays become central chokepoints. Relays can drop transactions or entire blocks that contain sanctioned addresses, leading to censorship. The proposer builder separation inclusion list proposal directly addresses this by restoring power to the proposer.
How Current PBS (MEV-Boost) Enables Censorship
Under MEV-Boost, a relay acts as a trusted intermediary. It receives full blocks from builders, validates them, and forwards the header to the proposer. The relay can choose to reject blocks that contain OFAC-sanctioned transactions (e.g., Tornado Cash interactions). Because the proposer never sees the full block until after signing, they have no way to enforce inclusion of censored transactions. This has led to over 50% of Ethereum blocks being OFAC-compliant at times. The proposer builder separation inclusion list proposal eliminates this relay-level censorship by giving the proposer a credible commitment mechanism.
The Core Idea: Mandatory Inclusion Lists
At its simplest, an inclusion list (IL) is a set of transactions the proposer commits to include in the next block. The list is broadcast before builders submit their blocks. Builders must include all IL transactions in the block they propose; otherwise, the block is treated as invalid and will not be voted canonical by attesters under the fork-choice rule. The proposer builder separation inclusion list design means the proposer’s power is not just to select between block headers but to enforce a baseline of uncensorable transactions. For example, if the proposer includes a Tornado Cash withdrawal, every builder must include it, ensuring those transactions are always processed.
Game Theory: Why Builders Have No Incentive to Censor
Builders maximize profit by including high-tip transactions. If a mandatory inclusion list contains transactions with below-market tips, builders might be tempted to leave them out. However, the rules ensure that a builder who omits any IL transaction loses the entire block reward (or is slashed). The rational choice is to include the IL and then fill the rest with profitable txs. This aligns incentives: the proposer pays for the IL (e.g., by setting a floor fee), and the builder competes to offer the best “fill” around the IL. The proposer builder separation inclusion list game theory works because the cost of censoring (losing the whole block) dwarfs any potential gain from excluding a single transaction.
Real Protocol Proposals: ePBS and FOCIL
Ethereum is actively considering an enshrined PBS (ePBS) design that includes mandatory inclusion lists. One leading proposal is FOCIL (Fork-Choice enforced Inclusion Lists, specified as EIP-7805). Rather than relying on a single block proposer, FOCIL uses a committee of validators that each build and broadcast their own inclusion list during the slot; attesters then only vote for a block if it includes the transactions from those lists, so the fork-choice rule recognizes non-compliant blocks as invalid. Another proposal, BRAID, uses multiple proposers to further decentralize the list creation. All these designs rely on the proposer builder separation inclusion list principle: give the proposer a tool to force inclusion, and penalize builders who ignore it.
Comparison: MEV-Boost vs. Enshrined PBS with Inclusion Lists
| Feature | MEV-Boost (Current) | Enshrined PBS + IL (Proposed) |
|---|---|---|
| Censorship vector | Relay or builder can drop transactions | Proposer enforces a minimum inclusion set |
| Trust assumptions | Trusted relay (non-collusion) | Trustless via protocol rules |
| Proposer power | Accepts/rejects block headers blindly | Controls a mandatory inclusion list |
| Enforcement | None for censorship | Block invalid if IL excluded |
| MEV extraction | Builder captures most MEV | Builder still captures most, but proposer can extract via IL fees |
| Latency overhead | Low (relay handles) | Moderate (extra round of communication) |
The proposer builder separation inclusion list approach fundamentally shifts the balance of power. In MEV-Boost, censorship is checked only by relay reputation; in ePBS+IL, it is enforced by protocol economics.
Implementation Challenges and Open Questions
Adopting proposer builder separation inclusion list designs comes with trade-offs. The IL broadcast adds a round of communication, increasing latency. Builders must decide how to fill the remaining space under time pressure. There is also the “builder regret” problem: a builder who sees a high-tip transaction after the IL is finalized cannot include it if it conflicts. Proposers may manipulate the IL to extract more MEV (e.g., front-running). Solutions include interleaved lists or allowing the builder to replace IL transactions with higher-tip ones if they refund the proposer. Projects like Flashbots’ SUAVE explore off-chain solutions, but the core consensus will be fought at the protocol level.
The Broader Impact on Censorship Resistance
If successful, the proposer builder separation inclusion list paradigm will make Ethereum resistant to nation-state level censorship. Users can be confident that any transaction—even one that interacts with a blacklisted address—will eventually be processed as long as at least one proposer includes it in their list. This is crucial for decentralization and neutrality. The design is being actively discussed in ETH research forums and the Ethereum Magicians community. While not yet deployed on mainnet, testnets like Holesky are experimenting with early prototypes.
Common mistakes to avoid
- Assuming inclusion lists make all transactions free; proposers must still pay for the list (floor fee) to attract builders.
- Confusing inclusion lists with transaction censorship resistance at the p2p layer; ILs protect inclusion but not propagation.
- Believing MEV-Boost relays cannot censor; they have been shown to drop OFAC-related transactions regularly.
- Thinking one inclusion list per slot is enough; some proposals require multiple lists to prevent proposer MEV abuse.
- Overlooking the latency impact: adding a round of communication can increase slot time, requiring hard fork changes.
- Assuming builders will always comply; game theory works only if the invalid-block conditions are properly enforced by the protocol's fork-choice rule.
Frequently asked questions
How does a proposer builder separation inclusion list actually prevent a builder from censoring a transaction?
The proposer broadcasts a list of transactions (the inclusion list) before builders finalize their blocks. Any block that omits any transaction from that list is considered invalid and will be rejected by the Ethereum consensus. Builders know they must include the full list or lose their block reward, so they comply.
Will mandatory inclusion lists make MEV markets less profitable for builders?
Not necessarily. Builders can still fill the rest of the block with high-tip transactions. The inclusion list only consumes a small portion of block space, and the proposer may set a minimum fee to compensate builders. The overall profitability can remain high while censorship resistance is guaranteed.
Related reading
Track the entities behind the concepts
DeFi Intel maps 11,000+ protocols, tokens and companies to a typed knowledge graph — with live data, incidents and regulation.