# ePBS: Bypassing Relayer
**TLDR**: Relayers today represent both **functionalities** and **entities**. Under ePBS, the entities will disappear, but the functionalities may persist. Builders can and likely will absorb these relayer functionalities, which is positive for the MEV supply chain and the beacon chain for the reasons outlined below.

## Background

It's December 31, 2025, and you have decided to stake 32 ETH to become a validator on the Ethereum Beacon Chain. You prepare to start your consensus layer beacon client, validator client, and execution layer client. While starting your validator client, you check the documentation and notice a CLI flag to input a list of builders from whom you wish to outsource execution blocks. You pause, thinking, 'Wait, this seems like how mev-boost used to work. Instead of connecting to relayers, I’m connecting to builders. Wasn't the entire point of ePBS to eliminate the need for these direct RPC connections? How did we end up here?

We will address a common critique of block auction ePBS: the concern that relayers can not be **bypassed**, thus offering little difference from the current MEV-Boost PBS design. The persistence of the relayer functionality is likely in all PBS designs. Why wouldn't the relayer functionalities disappear? In short, relayers provide functionalities attractive to both proposers and builders:

- **Fast connection** over RPC reduces latency, allowing more time for MEV opportunities. This may be less relevant for slot auction-based ePBS or execution ticket-based ePBS, but our focus today is on block auction ePBS.
- **Customization** over bid preferences, such as bid cancellation and pre-confirmation, is more flexible via a single HTTP request-response exchange than through a p2p gossip network.

## Moving from MUST trust to MAY trust

One should think of a relayer as a **set of functionalities**, not as a **set of entities**. Relayers exist today because builders or proposers alone can't be trusted to take on these functionalities. But with block auction ePBS, we should see the builder taking on the relayer's role, absorbing its functionalities, like opening its RPC port to allow direct connections with the proposers. There will be a curated list of builders a validator can connect with. Each builder may offer different properties that validators may find appealing, such as bid cancellation, OFAC censoring, pre-confirmation, etc.

You might still be thinking, "If the relayer functionalities still exist, was that all for ePBS?" The answer is No. Let’s examine what block auction ePBS improves over the current design, discussing its effects from **external** (proposer to builder) and **internal** (beacon chain) perspectives. First, let’s start with some background.

In the current MEV-boost block auction environment, if a proposer wants to sell block construction rights to an external entity. This arrangement requires trusting in an intermediary to ensure two requirements are met: the proposer does not steal the transactions, and the proposer gets compensated for timely commitment to the outsourced beacon block. There is no way to secure these two properties without a trusted intermediary. This is a fundamental limitation.

ePBS institutionalizes the role of this trusted intermediary within the protocol by utilizing the [Payload Timeliness Committee](https://ethresear.ch/t/payload-timeliness-committee-ptc-an-epbs-design/16054), which votes on the builder's action after the proposer has committed the block. This system includes a new fork choice attester voting scheme (block, slot) and builder attribution on-chain, allowing both the proposer and the block construction party to shift from **MUST** trust a relayer model to a **MAY** trust a relayer model.

## Benefit #1: Reduced hop

One external benefit of ePBS is that the flow from **`proposer -> builder`** has reduced hops compared to the **`proposer -> relayer <- builder`** . Let's compare the two flows:

- In the Mev-Boost model, builders submit execution blocks to a relayer. The relayer verifies the execution block (non-optimistic relayer), and the execution block becomes bids. The proposer then requests a bid from the relayer. The relayer returns the best bid.
- In the ePBS model, the proposer directly requests a bid from the builder. The builder returns its bid.

With the builder acting as the relayer, it can prolong its execution block construction time until closer to the slot deadline. Eliminating the need to submit the execution block to a relayer maximizes the potential for more MEV. With the builder acting as the relayer, the builder doesn’t have to verify the execution block. This reduction in the back-and-forth of data transmission between the builder and relayer improves overall efficiency. Additionally, the direct proposer-to-builder connection simplifies overall interactions. We can simplify the builder's API spec, retaining only the `GetHeader` method. The proposer only needs to make a single call to retrieve the bid, sign it, and then broadcast it as part of the beacon block. Other calls like `SubmitBlindBlock` and `SubmitValidatorRegistration` are no longer required.

*Source: https://ethresear.ch/t/empirical-analysis-of-builders-behavioral-profiles-bbps/16327. These bids are submitted directly to the relayer. What would it look like without that hop?*

## Benefit #2: Reduced operational cost

Another one external benefit of ePBS is that the relayer is **expensive to operate** and is intended to be an open-source good, but it suffers from a lack of a sustainable funding model. This has led to relayers exiting the market due to misaligned incentives. Various funding models for relayers have been proposed, and some have begun to take a share of the bid and redistribute it to the builder. Validators may not know how much the relayer is retaining and how much is being rebated to the builder. Without a relayer, there is no issue with finding sustainability, and there is one less player to pay. Opening its port is less expensive for the builder than using a relayer. The builder can check the proposer's signature without worrying about opening ports to other builders.

*Source: https://twitter.com/sui414/status/1778708084510302445. Ultrasound relayer using bid-adjustment feature.*

## Benefit #3: Reduced processing during peak times

Another one external benefit of ePBS is the **separation of processing times for consensus and execution blocks**, which reduces the risk of reorgs. In the current system, all the critical validation and processing steps are crammed into the first four seconds of a slot. If attesters do not complete these steps with the beacon block as the head of the chain in under four seconds, the block is at high risk of being reorg. The typical client sequence is:

- Receiving the block and blob sidecars over P2P networks.
- Validating the consensus and execution parts of the block.
- Validating blob sidecar availability.
- Updating the head.
- Meeting the attestation deadline. (4s mark)

With ePBS, the separation of consensus and execution slots reduces the reorg risk, particularly for clients who struggle with compute or bandwidth constraints within the first four seconds of the slot. The new sequence is:

- Receive the beacon block over P2P network.
- Validate the consensus rules.
- Update the head by the attestation deadline. (3s mark)
- Receive blob sidecars over P2P network.
- Validate blob sidecar availability.
- Receive aggregate attestation over P2P network. (6s mark)
- Receive the execution block over P2P.
- Validate the execution rules, which includes notifying the EL client about the new head.

The separation of execution also allows for earlier broadcasting of blob sidecars before the execution block reveal deadline, offering improvements over the current system where delays in blob sidecar propagation increase block reorg. This new timeline also increases incentives for blob inclusion, optimizing the overall network performance.

*Just a NUC attempting to process a block as quickly as possible. This Grafana chart illustrates the time it takes to process a block without the block arrival time, closely approaching the 4-second mark.*

One dynamic it opens up is allowing the validator to directly request an execution block from the builder, or in other words, allowing the builder to **self-advertise** to the validator. A builder is like a food stall, and a relayer is like a food court. Today, when you go to the food court to order food, your only option is to order through the food court desk. You cannot choose the restaurant. Instead, the food court serves you the best-valued item that all the restaurants offer at that moment. This arrangement might be okay for some people but lacks options for others. When a validator can work directly with a builder, there will be a site to curate the builder's quality, ability, and preferences, similar to Yelp for restaurants.

## Benefit #4: Reduced recurring execution faults

One internal benefit is that the **builder's attribution is on chain**. This makes it easier to take retrospective action against certain behaviors. For example, if a builder fails to fulfill promises such as out-of-protocol commitments, pre-confirmation, or experiences liveness failures, the validator could temporarily blacklist the builder. This is a straightforward action to implement through client code support. This is harder to implement today with MEV-boost without a sideband network. While we could implement similar actions today, why do so when we can get them for free under ePBS.

## Benefit #5: Reduced consensus faults

Another one internal benefit is that **consensus liveness** is decoupled from execution liveness. Today, missing an execution block means missing the corresponding consensus block—it's all or nothing. This is not ideal, as consensus blocks remain useful for economic security, slashing, and validator activations and exits. However, there are aspects that are coupled between the two layers, such as withdrawals that originate from the consensus layer and end at the execution layer. These require extra care.

## Benefit #6: No more out-of-band reimbursement

Another one internal benefit is **unconditional payment**. Unconditional proposer payment is guaranteed through the protocol rather than by a social contract. If the proposer reveals a valid consensus block on time, they will be paid the exact bid amount at a specified time, usually within the same slot or a new finalized epoch. While unconditional payment can also be guaranteed through an out-of-band social contract, it is more cumbersome.

I hope this article raised some useful points. Today's relayer consists of a rich set of functionalities that are hard to replace under any ePBS design. ePBS isn't about removing the relayer but rather enabling trustless exchanges between proposers and builders willing to sell execution block construction services. The set of functionalities could be absorbed by the builder, and while doing so, the protocol reaps additional benefits such as pipelining, reduced latency races, and more. Until next time!