This work is part of Fabric
Current preconf efforts were designed around the existing PBS pipeline, with the goal of extending it minimally—primarily by introducing Gateways—rather than shifting responsibilities onto Builders or Relays. This design assumed the continued presence of Relays to mediate between Proposers, Builders, and Gatways.
However, ePBS eliminates the role of Relays entirely, which breaks the underlying assumptions of the current preconf architecture. While this does not make based preconfs incompatible with ePBS, it does require rethinking how preconf enforcement is integrated into the new pipeline.
Fortunately, since ePBS is not yet SFI in Glamsterdam, there is still time to adapt. The open question is whether these adaptations can preserve the trust-minimizing properties of existing preconf designs—or whether support for preconfs under ePBS will reintroduce the very trust assumptions this EIP aims to eliminate.
Today, L1 validators are responsible for proposing BeaconBlocks and attesting to those proposed by others. Each BeaconBlock includes both consensus-layer data (e.g., randao_reveal, attestations, deposits) and an ExecutionPayload containing the execution-layer data.
Because ExecutionPayloads carry MEV opportunities—and MEV tends to centralize over time—a concern emerged: validators with advanced block-building capabilities could consistently outcompete less sophisticated validators and eventually dominate the network. This risks undermining decentralization, particularly for the critical role of attesting.
Proposer-Builder Separation (PBS) was introduced to address this. The core idea is to keep validators as unsophisticated as possible by offloading execution-layer block construction to a separate network of builders. Validators (i.e., L1 proposers) remain responsible only for proposing BeaconBlocks, while the construction of the ExecutionPayload happens externally, outside the validator’s node.
However, PBS introduces a fair exchange problem: builders have no trustless way to deliver an ExecutionPayload to a proposer without risking theft—i.e., the proposer could take the payload and include it without paying the builder. Since builders are competitive and for-profit, this is unacceptable. To solve this, PBS initially relied on a trusted third party called a relay, which mediates the exchange of ExecutionPayloads between builders and proposers. Note that over time the role of a Relay has evolved to encompass block propagation, timing games, and inclusion lists.
One of the core motivations behind EIP-7732 is to enshrine the relay’s role directly into the Ethereum protocol. By doing so, Ethereum can eliminate its reliance on trusted third parties and their software to facilitate fair exchange between builders and proposers. Instead of depending on external relays to enforce builder payments and protect block contents, ePBS introduces protocol-level mechanisms that allow builders to commit to payloads and pay proposers in a trustless, verifiable way. This reduces centralization risk, simplifies infrastructure, and strengthens Ethereum’s neutrality and resilience.