Where the Pipeline Falls Short

The PBS pipeline described in 201 works. Over 90% of Ethereum blocks flow through it. But three years of production have surfaced structural limitations across four categories. The Blockspace Forum series covers each in depth:

  1. Economics. Originators are incentivized to send transactions exclusively to a single builder, because broadcasting to multiple builders causes priority fees to get competed away in the relay auction. As a result, builders construct blocks from partial views, blockspace goes underutilized, and relays struggle to sustain themselves despite performing critical infrastructure functions.

  2. Robustness. Winner-take-most dynamics shrink the active builder and relay set, raising correlated failure risk from implementation monocultures, shared infrastructure, and jurisdictional pressure. The out-of-protocol pipeline does not match Ethereum’s own decentralization guarantees.

  3. Performance. No explicit queuing, scheduling, or deadline mechanisms exist along the hot path. Tail latency is high. Users overpay to hedge uncertainty. The 12-second slot creates a structural UX gap compared to chains with faster block times.

  4. Services. Validators gave up control of their blocks when they adopted the block auction. They cannot require specific transactions to be included. They cannot make commitments to users. Preconfirmations and other services require bilateral integration with every builder and relay, creating a cold-start problem.

The research directions below address different pieces of this problem. Some require protocol changes. Others work within the existing pipeline. They are not mutually exclusive; in many cases they reinforce each other.

Enshrined PBS (ePBS)

Today’s block auction runs entirely outside the Ethereum protocol. Enshrined PBS (proposed in EIP-7732) would bring the core auction mechanism into the consensus layer itself.

The key change is unconditional payment. In the current system, if something goes wrong in the relay handoff, the proposer can lose their slot and earn nothing. In ePBS, the protocol guarantees the proposer receives the builder’s bid regardless of whether the builder reveals the block contents. A new group of validators called the Payload Timeliness Committee (PTC) observes whether the builder’s payload arrives on time and attests accordingly. This replaces the relay’s escrow role with protocol-level enforcement.

It is worth noting that some form of unconditional payment is already approximated today through optimistic relaying. In this model, the relay holds collateral on behalf of builders and can compensate the proposer if a builder submits an invalid block. ePBS replaces this with a protocol-level guarantee.

What ePBS changes:

  • The block auction moves in-protocol. Builders submit bids through a gossip subnet visible to all participants.
  • Fair exchange is enforced by the protocol, not by relay infrastructure.
  • Proposers are protected from invalid blocks without relying on relay simulation.

What ePBS does not solve:

  • Builder concentration. The exclusive order flow dynamic that concentrates building among a few entities is an economic problem, not a structural one. ePBS removes relays from the critical path but does not necessarily fix who wins the auction. It could shift dynamics by changing the auction format, but does not guarantee a more competitive auction. The Align the Incentives post explores this dynamic in depth.
  • Relays may persist. Even after ePBS, relays can offer valuable services beyond block escrow: bid cancellation management, bid aggregation, and more sophisticated coordination like multi-party block construction (covered below). The relay role narrows from a critical intermediary to an optional service provider.

Enshrining the auction into the protocol also raises a question: if the consensus layer absorbs relay functionality, does the sidecar layer become unnecessary? The answer is no. Sidecars remain valuable precisely because it is easier and more efficient to coordinate and experiment out-of-protocol. Different validators have different needs: some want to offer preconfirmations, others want to enforce inclusion constraints, others want to delegate duties to specialized operators. Addressing these at the sidecar level avoids requiring hard forks or adding complexity to security-critical consensus clients. The protocol enshrines the minimum viable mechanism. Everything above that stays in the sidecar.

ePBS is the foundation. It moves the core block auction into the protocol. But the pipeline’s other limitations require additional mechanisms.

Inclusion Lists (FOCIL)

If builders control what goes into blocks, who ensures that censored transactions still get through?

FOCIL (Fork-choice enforced Inclusion Lists, proposed in EIP-7805) is a committee-based mechanism that guarantees transaction inclusion regardless of what builders prefer.

In each slot, a set of validators is selected as an inclusion list (IL) committee. Each committee member observes their local view of the mempool and builds an inclusion list: a set of transactions they believe should be in the next block. They gossip these lists to the network.

The proposer (or builder, if the block is not built locally) must include transactions from all collected ILs when constructing the block. The enforcement happens through the fork-choice rule: attesters only vote for a block if it includes transactions from all the ILs they have seen. A block that ignores the inclusion lists will not gather enough attestations to become canonical.

This serves as a censorship-resistance backstop for the protocol. Even if every builder in the market wants to exclude a particular transaction, the IL committee guarantees it a path into the chain. Builders remain free to order transactions however they like and include whatever additional transactions they want. FOCIL only ensures that no transaction can be permanently excluded.

FOCIL is complementary to ePBS. Where ePBS addresses the structure of the auction, FOCIL addresses the censorship risk that comes with builder concentration: it gives the network a way to override builder preferences when inclusion guarantees require it.

Relay Inclusion Lists

FOCIL requires a protocol-level change (a hard fork). But the same idea can be approximated today, without any changes to Ethereum’s consensus rules.

Relay inclusion lists are an out-of-protocol mechanism where relays enforce inclusion constraints on builder blocks before forwarding them to proposers. The relay maintains a list of transactions that should be included. When a builder submits a block, the relay checks whether those transactions are present. If not, the relay can reject the block or, in conjunction with multi-party block construction, inject the missing transactions itself.

This works within the existing block auction pipeline. No hard fork, no new consensus roles. Relays already validate builder blocks before forwarding them; adding an inclusion check is a natural extension of that responsibility.

A related mechanism, multi-relay inclusion lists, extends this by sharing constraints across relay instances, improving enforcement coverage and reducing single-relay dependence.

Relay inclusion lists are not a substitute for FOCIL. They depend on relay adoption, which is centralized. But they provide a practical bridge: censorship-resistance improvements that can ship today while the protocol-level solution is developed.

Preconfirmations

Today, when you send a transaction, you wait up to 12 seconds (one full slot) for it to appear in a block. In practice, with mempool propagation and builder auction timing, it can take longer. For applications that need fast feedback, like trading or gaming, this latency is a barrier.

Preconfirmations allow proposers to issue signed commitments to users before the block is finalized. A proposer can promise: “your transaction will be included in my block,” and back that promise with their stake. The user receives confirmation in milliseconds rather than seconds.

The mechanism works through the sidecar layer. A proposer running Commit-Boost can load a preconfirmation module that listens for user requests, evaluates whether the commitment is safe to make, and signs a binding promise using a proxy key. If the proposer fails to honor the commitment, their collateral can be slashed.

For solo validators, delegation is key. A solo validator does not have the infrastructure to run a preconfirmation service themselves. But they can delegate preconf duties to a specialized gateway operator while retaining ultimate control over their block. The gateway handles the complexity; the validator earns a share of the preconf fees.

Preconfirmations rely on knowing who the upcoming proposer is. EIP-7917 (Deterministic Proposer Lookahead) provides a reliable schedule so that preconf protocols can identify and interact with the right validator ahead of time.

Multi-Party Block Construction

In the current pipeline, the auction selects a single winning block and delivers it. If that block does not include certain transactions, those transactions wait for the next slot. Any transaction not known to the winning builder has no path to inclusion in that slot.

Multi-party block construction changes this. Instead of a single builder producing the entire block, the operator uses its view of all submissions to merge non-contentious transactions from other builders to the winning block, producing a strictly fuller result and improving censorship resistance by offering a second path to inclusion.

The mechanism works through explicit opt-in. Contributing builders label specific transactions as available for inclusion. The winning builder makes a binary choice: allow or reject merging. If allowed, the operator adds those transactions to the block. The resulting block is guaranteed to be at least as full as the original.

This has a direct connection to preconfirmations. If a proposer has issued a preconf commitment and the winning builder’s block does not include that transaction, the operator can inject it rather than rejecting the entire block. This bypasses the cold-start problem for preconfirmation adoption: only a few operators need to support preconfs, rather than requiring every builder to integrate every preconf protocol individually.

No consensus-layer changes are required. Today, relays are the natural operators for this mechanism, but the design is not permanently tied to relays. As the pipeline evolves, this role can migrate to other infrastructure.

Attester-Proposer Separation (APS)

In today’s Ethereum, every validator both proposes and attests. PBS separated block building from block proposing, but proposing and attesting are still bundled into the same role. Attester-Proposer Separation (APS) takes the next step: fully decoupling these two duties.

Under APS, attesting and proposing become separate roles with separate incentives. Attesters form the decentralized backbone of consensus, voting on block validity and chain head. Proposers become a specialized role focused on block selection and commitment.

This separation has a key benefit: if proposers are assumed to be sophisticated operators, they can take on responsibilities that are impractical for the average validator today. A sophisticated proposer can run preconfirmation services directly, evaluate complex builder bids, and manage commitment protocols without delegation overhead. The barrier to offering these services drops because the proposer role is designed for entities that can handle the complexity.

More importantly, APS reduces the centralizing effects of bid variance on the validator set. Today, block auction revenue flows to proposers, creating variance that pushes solo stakers toward pools (as we covered in PBS 201). Under APS, what matters for network security is that attesting remains decentralized. The proposer role can tolerate more concentration without threatening consensus, because attesters, not proposers, are the ones securing the chain.

In-Protocol Delegation

One persistent challenge with proposer commitments is enforcement. A proposer always has the final say in block construction. Even if they have committed to proposing a builder’s block, they could choose not to, accepting the penalty if it is cheaper than honoring the commitment.

Today, this is handled through out-of-protocol mechanisms: extra collateral requirements, slashing via external protocols, and reputation systems. These create barriers to entry for proposers and introduce risk. A solo validator who wants to participate in commitment protocols needs to post additional collateral and rely on external slashing infrastructure, which pushes them toward pools or delegation services.

In-protocol delegation would simplify this by allowing proposers to delegate their block production rights directly within the consensus rules. The delegate, not the proposer, would be responsible for fulfilling commitments, and the protocol itself would enforce the delegation. The proposer is no longer a source of risk because they have credibly handed off control.

This removes the need for extra collateral and out-of-protocol slashing mechanisms. It lowers the barrier for proposers to participate in commitment markets and makes the system more accessible for smaller operators who want to earn from commitment protocols without taking on the infrastructure and risk burden themselves.

In-protocol delegation can be thought of as a baby step toward APS. Both move in the same direction: separating who has the right to propose from who actually builds and commits. Delegation does it optionally, within the current validator model. APS does it structurally, as a protocol-level role split.

PEPC: The Generalization

Each mechanism above addresses a specific limitation: ePBS enshrines the auction, FOCIL prevents censorship, preconfirmations improve latency, merging increases block fullness. But they share a common thread: they all involve proposers making commitments about their blocks.

Protocol-Enforced Proposer Commitments (PEPC) generalizes this into a single framework. Rather than enshrining each commitment type separately, PEPC provides general-purpose infrastructure for proposers to enter into arbitrary commitments with third parties, enforced by the protocol.

In this framing:

  • ePBS is a specific PEPC instance: “I commit to proposing this builder’s block.”
  • Inclusion lists are a PEPC instance: “I commit to including these transactions.”
  • Preconfirmations are a PEPC instance: “I commit to including this user’s transaction.”

PEPC is a long-term research direction, not something shipping soon. But it provides the conceptual unification. And the practical bridge exists today: Commit-Boost enables validators to make proposer commitments through a standardized sidecar interface. The commitment types that Commit-Boost supports now will inform which PEPC variants are worth enshrining in the protocol.

The Work Ahead

These research directions are not independent. They interact, sometimes reinforcing each other, sometimes creating tension. ePBS and FOCIL are designed as companions. Relay inclusion lists and multi-party block construction complement each other. Preconfirmations need both a sidecar framework and a fulfillment mechanism.

The Blockspace Forum exists to map these interactions, identify the most impactful paths, and ship the infrastructure that makes them real.