What is Relay?

A Relay is an intermediary service in Ethereum’s proposer-builder market that connects block builders with validators responsible for proposing blocks. Its main role is to coordinate the exchange of block bids and block contents without requiring builders and proposers to trust each other directly.

Relays became an important part of Ethereum’s MEV infrastructure through MEV-Boost, the middleware developed by Flashbots for validators after Ethereum’s transition to Proof of Stake. Builders construct candidate blocks and compete to offer them to proposers. Relays sit between these parties, receive builder submissions, validate relevant information, expose bids to proposers, and coordinate delivery of the winning block.

The Relay is therefore neither the Block Builder nor the proposer. It does not normally decide the transaction order itself, and it is not the validator selected by Ethereum consensus to propose the block. Its function is to make the external proposer-builder market work reliably despite an important information problem: builders need to prove that their blocks are valuable without revealing complete block contents too early.

This role is especially associated with today’s external form of Proposer-Builder Separation (PBS). In a more protocol-native PBS architecture, some functions currently performed by relays could instead be enforced through Ethereum’s protocol.

Why the Builder Market Needs Relays

The basic interaction between a builder and proposer creates a trust problem.

A builder spends resources finding valuable transaction combinations and constructing an optimised block. If it simply sends the entire block to the proposer before the proposer commits to using it, the proposer can see the transactions and ordering strategy.

This creates the possibility that valuable information could be copied without respecting the original builder’s bid.

The reverse problem also exists. A proposer wants to know how much value a builder is offering before selecting its block, but it does not want to commit blindly to a block that turns out to be invalid or unavailable.

Relays provide an intermediary coordination layer. They receive blocks from builders, perform checks, communicate bids to proposers, and help ensure that the corresponding block payload is delivered after the required commitment has been made.

A simplified interaction works as follows:

1. Builders construct candidate Ethereum blocks.
2. Builders submit blocks and associated bids to one or more relays.
3. Relays check submissions according to their validation policies.
4. The proposer queries available relays for block offers.
5. The proposer selects an attractive bid and signs the relevant commitment.
6. The relay reveals or delivers the corresponding execution payload.
7. The proposer publishes the block to Ethereum.

This architecture allows builders to compete without exposing complete blocks directly to proposers at the beginning of the auction.

Relays therefore solve an information and coordination problem rather than a blockchain consensus problem.

Relay, Builder and Proposer

The Relay is easiest to understand by separating it from the participants on either side of the interaction.

A builder’s competitive advantage comes from its ability to assemble valuable blocks. A proposer’s authority comes from Ethereum’s Proof of Stake consensus, which assigns it the right to propose a block for a particular slot.

A relay has neither of these powers. Its importance comes from its position in the communication path between them.

This also means that Relay centralisation and validator centralisation are different issues. Ethereum can maintain a large validator set while block production still depends heavily on a relatively small group of external infrastructure providers.

Relays in MEV-Boost

MEV-Boost allows Ethereum validators to access blocks produced by external builders rather than relying entirely on local block construction.

A validator running MEV-Boost can connect to multiple relays. Each relay can receive bids from several builders, and the proposer can compare the opportunities available through its configured relay set.

The system effectively creates a marketplace for block space. Builders compete to produce valuable blocks, while proposers can increase their revenue by accessing specialised block construction without operating advanced MEV infrastructure themselves.

The relay helps make this market possible by separating the block’s economic offer from the early disclosure of its complete contents.

Relays also perform operational checks. Exact policies vary between implementations and operators, but a relay generally needs to reject malformed or invalid submissions and ensure that information communicated to proposers corresponds to an actual builder submission.

Reliability is particularly important because Ethereum’s block production operates on 12-second slots. Delays in bid processing or block delivery can cause a proposer to miss its opportunity to publish a block.

As a result, relay performance is measured not only by security properties but also by latency, uptime, builder connectivity, and the ability to deliver payloads quickly.

Why Validators Can Connect to Multiple Relays

Using multiple relays reduces dependence on a single intermediary and can give a proposer access to bids from a broader set of builders.

Different builders may submit to different relays. A validator connected to only one relay could therefore miss a more valuable block available elsewhere.

Multi-relay configurations can also improve resilience. If one relay becomes unavailable, the validator may still receive builder bids through others.

However, simply increasing the number of configured relays does not eliminate infrastructure concentration. Several relays may depend on similar builders, data centres, software, or network routes. A large proportion of economically valuable block flow can still pass through a limited ecosystem.

Important considerations when evaluating relay infrastructure include:

• uptime and delivery performance;
• latency between builders, relays, and proposers;
• number and diversity of connected builders;
• validation policies for submitted blocks;
• transparency of relay operation;
• censorship policies;
• geographical and infrastructure diversity;
• behaviour when builders fail to deliver expected payloads.

For validators, the relay set therefore influences both potential block revenue and operational resilience.

Relay Trust and Failure Risks

Relays were introduced partly to reduce direct trust between builders and proposers, but the external architecture gives the relay itself responsibilities that can create new trust assumptions.

A malicious or faulty relay could misreport bids, fail to deliver a payload at the required time, selectively reject builders, or interfere with the information available to proposers.

Availability failures are another concern. Because Ethereum slots are short, even a temporary service interruption can matter. If a validator waits for external infrastructure that fails to respond quickly enough, it risks missing the slot.

The proposer-builder market also needs to deal with dishonest builders. A builder might attempt to advertise a valuable block and then fail to provide the expected payload. Relay policies and validation mechanisms help reduce such behaviour.

The major relay-related risks include:

• relay outages disrupting access to external builder blocks;
• delayed responses causing missed proposal opportunities;
• incorrect or misleading bid information;
• selective treatment of builders;
• censorship of transactions or builder submissions;
• concentration of traffic among a small number of relay operators;
• dependence on infrastructure outside Ethereum’s core consensus protocol.

These risks do not mean that a relay can arbitrarily rewrite Ethereum. The final block still needs to satisfy Ethereum’s validity rules, and consensus participants verify it according to the protocol.

The concern is instead that relays can influence the block-production pipeline before consensus sees the completed block.

Relays, Censorship and Ethereum Neutrality

Relay censorship became an important topic after Ethereum’s transition to Proof of Stake because relays occupy a strategically important position between builders and validators.

A relay can apply policies determining which builder submissions it accepts. If a widely used relay refuses blocks containing particular transactions, addresses, or applications, its market position can affect which candidate blocks are visible to connected proposers.

This becomes more significant when economic incentives reinforce the behaviour. Validators often prefer the highest-paying valid block. If a small number of relays and builders dominate the most profitable block flow, their policies can influence transaction inclusion even without controlling Ethereum consensus.

Validators can mitigate some dependency by connecting to diverse relay infrastructure and retaining alternative block-production paths. At the protocol level, Ethereum research has also examined mechanisms intended to preserve censorship resistance as block construction becomes increasingly specialised.

Inclusion lists are one example. They aim to give proposers some ability to require the inclusion of eligible transactions even when another participant constructs most of the block.

The broader goal is to prevent specialised block building from turning external intermediaries into permanent gatekeepers for Ethereum transactions.

Why Protocol-Native PBS Could Change the Relay Role

The current relay architecture exists because Ethereum’s proposer-builder market developed largely outside the core protocol.

MEV-Boost provides an external mechanism for validators to obtain blocks from specialised builders. Relays are necessary within this model because builders and proposers need a practical way to exchange bids and block payloads without directly trusting each other.

Protocol-native Proposer-Builder Separation seeks to move more of this coordination into Ethereum itself.

A native design could enforce builder-proposer commitments through protocol rules rather than relying on an external relay to mediate the interaction. This could reduce the amount of trust placed in independent relay operators and simplify some parts of the current market.

That does not necessarily mean that every form of relay-like infrastructure would disappear. Networking services, auction infrastructure, and other intermediaries may continue to exist for performance or market reasons. The key difference is whether Ethereum’s safety and block-production process depend on them performing trusted functions.

This makes Relay somewhat unusual as a glossary term. It describes an important component of Ethereum’s current MEV architecture, but not necessarily a permanent protocol role.

The Relay’s Place in Ethereum Block Production

Relays illustrate how Ethereum block production extends beyond the consensus protocol itself.

The validator selected as proposer still performs the formal consensus role, but the block it proposes may have passed through several specialised participants before reaching it. Searchers can identify MEV opportunities, builders assemble candidate blocks, and relays coordinate the builder-proposer exchange.

The Relay’s unique function is therefore narrow but important. It does not search for arbitrage, optimise transaction ordering, or provide finality. It creates a workable market interface between the party that constructs the block and the validator that has the right to propose it.

This distinction is also why Relay should not be treated as another name for Builder infrastructure. Builders compete over block construction. Relays facilitate the competition and delivery process.

As Ethereum develops more protocol-native approaches to proposer-builder separation, this architecture may evolve. For the current external PBS model, however, relays remain an important bridge between specialised block construction and Ethereum’s validator network.