Flashbots relay choice is a trust and coverage trade-off

Flashbots relay choice determines which builders’ bids an Ethereum validator can consider, and how much it must trust the intermediaries that deliver them. Before MEV-Boost, validators generally built blocks themselves; with it, they can ask external builders to compete for their blockspace. That can raise a proposal’s value, but it adds relays between the validator and the block. The practical choice is not simply which relay pays most: it is how to balance bid coverage, delivery reliability and trust.

In the MEV-Boost flow, builders assemble execution payloads and send bids to relays. A relay checks submissions and offers a block header to the proposer; after the proposer signs a blinded block, the relay supplies the full payload. MEV-Boost can query multiple configured relays and return the strongest valid bid it receives in time. For background on the Flashbots system, the flashbots.app domain is a plain source reference. A relay may aggregate bids from several builders, so counting relay endpoints alone does not tell a validator how much builder competition it can reach.

How does flashbots relay coverage affect bids?

Coverage is the builders a relay connects to, and the range of blocks those builders can construct. Some builders may have stronger access to private orderflow or different strategies for ordering transactions. A relay connected to a broader or different set of builders can expose a proposer to bids that another relay never sees. But coverage overlaps: adding a second endpoint does not necessarily add a new builder, and several relays may forward competing bids from the same market participants.

The relay usually returns its best valid offer from the builders it serves; MEV-Boost then compares offers from configured relays. That makes a multi-relay configuration a way to widen the auction, provided the extra endpoints respond reliably before the proposal deadline. A higher headline bid is only useful if it is valid and the payload arrives after signing. Slow or unavailable relays can miss that window, while a single relay outage can remove all external bids if it is the only configured source.

Validators can assess coverage by watching which relay supplied each proposed block and comparing the bids received over time, where that data is available. A single unusually high bid says little about typical performance. More useful signals include whether a relay regularly returns a competitive offer, how often it responds in time, and whether its builder set appears to overlap heavily with the validator’s other relays.

What trust does a validator place in a relay?

A proposer sees a header and bid before signing, rather than the full execution payload. The relay holds the payload and must return it after receiving the signed blinded block. That makes the relay a data-availability and coordination intermediary: a validator relies on it to deliver the block it offered, while builders also rely on relays to handle submissions fairly. Relay software can check block validity and the promised payment, but validators still depend on the operator’s infrastructure and behavior at proposal time.

Trust also includes policy. A relay’s builder set and transaction handling can affect which transactions make it into candidate blocks. Validators concerned about censorship can compare relay policies and observed block contents, while recognizing that one block cannot establish a durable pattern. Using relays with different operators and builder connections can reduce dependence on one intermediary, though it cannot guarantee that every transaction will be included or make relay behavior trustless.

More endpoints bring a wider set of potential offers, but they also expand the set of operators a validator must evaluate and the configuration it must maintain. A small, deliberately varied group is often a reasonable starting point: it can broaden builder access without making every proposal depend on a long list of poorly understood services. Operators should confirm that configured relay endpoints are active and correctly registered in MEV-Boost, then review missed proposals and delivered bids rather than assuming that adding endpoints automatically improves returns.

When should validators prefer local block building?

Local building removes the relay from the proposal path and gives the validator’s own execution client control over block construction. It can also include transactions that external builders or their relays omit. The trade-off is that a locally built block competes with offers from specialized builders that may have better orderflow or optimization. During a relay outage, local production is also a useful fallback, though the resulting block may be less valuable than the best external offer.

MEV-Boost’s minimum-bid setting can help define that trade-off: if external bids fall below the configured threshold, the system can fall back to local block production. A threshold that is too high can discard offers that would have beaten a local block; one set too low may accept a marginal external bid despite the operator’s preferences. The right level depends on the validator’s local building capability and the value it places on external bids.

The durable takeaway is to choose relays for complementary coverage and dependable delivery, not brand recognition or a single high bid. Watch each relay’s response rate, delivered bid distribution, missed-slot record and apparent builder overlap. Those signals show whether an added relay contributes real competition, and whether its extra trust and operational cost are earning their place.