Enshrined Proposer-Builder Separation (ePBS) on Ethereum and legally credible neutrality
Enshrined proposer–builder separation (ePBS) scheduled for Ethereum's Glamsterdam upgrade promises to make the blockchain more robust and less reliant on external tools.[1] I'd like to explore whether ePBS will also improve legally credible neutrality for any of the participants in the Ethereum network,[2] like I recently did for the FOCIL proposal.[3] Here, I explain how ePBS strengthens that case for proposers, creates an even cleaner “conduit‑like” role for a new committee, and concentrates discretion (and thus potentially legal attention) at the builder layer.
What ePBS changes that is salient for law and policy
The core mechanical change is straightforward. The beacon block no longer carries a full execution payload. Instead, the proposer includes a SignedExecutionPayloadHeader—a builder‑signed commitment that binds to a future execution block and a value to be paid to the proposer. The protocol deducts that value from the builder’s beacon balance during block processing (“proposer unconditional payment”). Meanwhile, a new Payload Timeliness Committee (PTC) later attests—without execution validation—to whether the payload was revealed on time (and whether blobs were available). Execution validation shifts out of the hot path to the next slot. A global gossip topic is introduced for broadcasting these signed headers (so proposers can hear about builder bids without external relays). This design eliminates the need for trusted middleware (relays) to fairly exchange blocks for payment between proposers and builders.
In short:
- proposers pick among public, content‑blind commitment bids,
- builders later reveal content,
- a PTC certifies timeliness, and
- the network validates the content afterward.
Under ePBS, the proposer’s in-slot job would be narrower than today: instead of including a full execution payload, the proposer includes a builder-signed execution-header commitment and is paid by protocol for doing so. A Payload Timeliness Committee (PTC) would then attest to timely reveal and blob availability. Proposers would still propose beacon blocks, but their selection would be content-blind because they see price and a cryptographic commitment, not transactions.
However, the same person or company who acts as a proposer for a given slot, could also separately run (act as) a builder. Moreover, they would be free to pick their own builder bid in preference over any other bids, irrespective of remuneration offered by other builders. Such proposer operators would effectively be building blocks locally, like proposers did in pre-MEV-Boost days.
How this updates my earlier analysis of Ethereum's legally credible neutrality
In my earlier Ethereum‑specific note, I distinguished three focal points for analysing legally credible neutrality: block production, outsourcing via MEV‑Boost, and attestations. The core diagnostic was whether an actor had practical control over content in a way that would make legal “targeting” both feasible and proportionate. I suggested safe harbors for validators who adopt content‑blind strategies, and I was cautious about legal rules aimed at attestations given the risk of network harm.
ePBS changes the facts under that analysis in three ways.
1. Validators-proposers become more credibly neutral by design (but only as a default). Under ePBS, a proposer’s selection is content‑blind by design. Builder headers they see reveal price, not block content, and the payment is enforced regardless of later reveal. Yes, operators of validators can still build blocks "locally" if they also operate a builder. But for those proposers who don't operate builders there is, I think, a meaningful improvement in credible neutrality under ePBS. The difference comes from the source of their neutrality. Under MEV-Boost, a proposer becomes content-neutral by choosing to engage in an out-of-protocol scheme. Under ePBS, a proposer is neutral by default, due to the core design of the Ethereum protocol.
Aside from the question of directly choosing block content, there is an issue of discretion in the choice of block content suppliers. Under MEV-Boost, proposers can select which relays to use. I discussed elsewhere how the choice of relays that brand themselves as "max profit" as distinguished from relays branded as "ethical" or "regulated" may be a policy concern.[4] Somewhat analogously, the ePBS design does not impose on proposers any method of builder bid selection. Moreover, builder identity would be knowable to proposers at bid selection time. Proposers would be free to choose the highest bid, but also free to use "allow-lists" or "deny-lists" of builders. Hence, this choice could remain as a source of potential risk for proposers.
2. A new, cleanly neutral actor appears—the Payload Timeliness Committee (PTC). PTC duties are intentionally content‑blind: attesting to timeliness and availability only. This role maps to a classic “mere conduit” analogy in intermediary‑liability law.[5] As long as the PTC’s scope remains narrow, I consider PTC members strong candidates for explicit recognition of legally credible neutrality.
3. Builders are the focal point of discretion. Builders select and order transactions, and—under the current ePBS draft proposal—enjoy a non‑trivial “free option” to withhold reveal within the ePBS timing window, paying the committed value but causing an “empty” execution side in that slot if they exercise the option. This could be economically meaningful in volatile periods and could distort user experience. Flashbots’ analysis suggests mitigations, notably tightening PTC deadlines and penalising late or non‑reveal.[6]
In other words, ePBS strengthens my prior view that validators-proposers should be treated as credibly neutral infrastructure and clarifies that, if law insists on imposing content‑related obligations at base‑layer interfaces, the builder layer is the least‑bad target. That does not mean that law should target builders. It means proportionate interventions are less destructive there than at the proposer layer.
How ePBS interacts with sanctions/AML “facilitation”
My general paper argued that “facilitation” theories tend to follow control—sometimes expansively—and that law occasionally recognises neutral infrastructure despite capacity, as with some internet intermediaries and arguably Swift’s payments messaging. The rationale is both principled (fundamental rights, proportionality) and instrumental (the alternative would degrade critical infrastructure for little gain).[7]
Under ePBS, validators-proposers and PTC members fit that template better than before: they lack pre‑commit content knowledge and their duties are verifiably mechanical. Put differently, if a statute or regulator insisted on “screening,” proposers under ePBS are a poor compliance surface because they lack the means at the relevant decision point. Builders do have means and may devise policies about content and ordering.
Censorship resistance, inclusion lists, and where “control” sits
The ePBS proposal is meant to be compatible with fork‑choice enforced inclusion lists (FOCIL, EIP‑7805), an optional companion that would constrain builder discretion further by protocol rule.[8] FOCIL would allow a committee to force‑include transactions into blocks by embedding constraints in fork‑choice—that is, in the voting rule rather than in ad hoc external norms. In terms of legally credible neutrality, this pushes inclusion guarantees not only away from proposer choice, but also away from builder choice. Hence, FOCIL may be especially worth considering given that the protocol itself would point to builders as a locus of discretion under ePBS.
Buildernet and credible neutrality under ePBS
Buildernet is a network of block builders running attestable code in TEEs, peer‑sharing order flow and using a public refund rule.[9] Given that builders would be the focal point of discretion about transaction inclusion and ordering under ePBS, it is worth considering how Buildernet could affect the legally credible neutrality of builders who use it under ePBS. I intend to analyse Buildernet separately soon, but I'll flag here that Buildernet could improve credible neutrality of the builder layer. Naturally, there are caveats regarding the details of Buildernet rules and governance. More on this topic soon.
Policy implications and recommendations
Validators-proposers and PTC. ePBS gives policymakers a clean hook for safe harbors premised on content‑blindness. One could draft an exemption keyed to two facts: (i) proposers and PTC members lack pre‑commit visibility into execution contents and (ii) they act in accordance with protocol duties that are verifiably mechanical. This aligns with legally credible neutrality—independently verifiable design reasons to trust neutrality—and it fits my prior safe‑harbor proposals for “passive” block production strategies, now realised in protocol rather than by voluntary practice.[10]
Builders. If the law insists on base‑layer obligations, apply them, if at all, at the builder surface—and prefer mechanical constraints over content‑classification rules. The issue of constraints is relevant in part due to the “free option” issue, which is a form of discretionary control. Exercised at scale, it could be misinterpreted by policymakers as censorship, or could invite market‑abuse theories if coordinated around price‑sensitive events. Flashbots’ work suggests that shortening the option window and penalising late or non‑reveal materially reduces option value and exercise probability. Those mitigations align with legally credible neutrality because they would curb discretionary behaviour without pushing content decisions back onto proposers.[11]
EIP‑7732, Enshrined Proposer–Builder Separation, available at GitHub; Ethereum Magicians, EIP‑7732—the case for inclusion in Glamsterdam. ↩︎
See my Legally Credible Neutrality and Legally Credible Neutrality on Ethereum. ↩︎
Data Always, An MEV Perspective on Glamsterdam (Flashbots Collective, 23 July 2025); Flashbots Collective, The free option problem in ePBS (July 2025); Flashbots Collective, The free option problem in ePBS, Part II (August 2025). ↩︎
See my FOCIL on Ethereum and legally credible neutrality; see also EIP-7805: Fork-choice enforced Inclusion Lists (FOCIL); Fellowship of Ethereum Magicians, EIP-7805. ↩︎
“What is Buildernet,” Buildernet docs (overview and mission) buildernet.org; Flashbots, “Introducing Buildernet” (forum post, 26 Nov 2024) The Flashbots Collective. ↩︎
See n 6 above. ↩︎