Skip to content

Proposer-Builder Separation and Relays

Follow an Ethereum block bid from builder to relay to proposer, and see how signing changes the available fallback.

Proposer-builder separation (PBS) splits block production into two jobs. A builder assembles the ordered transactions and the rest of the execution payload. The validator assigned to propose in that slot chooses a payload and signs the block. On Ethereum, the relay-based MEV-Boost system gives a proposer access to bids from specialist builders. For a quant estimating validator revenue, the builder’s offer for the whole block is a separate quantity from the tip on any one transaction. Flashbots’ MEV-Boost overview

What the proposer sees before signing

  1. Builders submit full payloads and bids to relays. Builders can combine public transactions with privately submitted bundles and seek maximal extractable value (MEV) through their choice of transactions and ordering. The relay sees the full payload and checks the submission and its offered payment. Flashbots’ relay has a path that simulates the payload before serving the bid and an optimistic path that can simulate it asynchronously. Flashbots Auction overview · Flashbots relay implementation
  2. MEV-Boost compares blinded bids from configured relays. It requests them with getHeader. A bid includes the payment amount and an execution payload header that commits to the payload while leaving the transaction list hidden. MEV-Boost checks that the bid matches the requested parent block and applies its bid filters before ranking by value. The proposer can see what it is offered before seeing the builder’s transaction order. Flashbots’ relay documentation · MEV-Boost bid processing
  3. The proposer signs, then the relay unblinds the block. If the proposer takes the external bid, it signs the blinded beacon block containing that header. MEV-Boost sends the signed block back via submitBlindedBlock. The relay verifies the signature and unblinds the block with the matching full payload. Flashbots’ v1 relay path returns the payload after broadcasting the block. Its v2 path acknowledges the request and handles publication separately. Flashbots relay implementation · Relay publication paths

Two bids for the same slot

Suppose MEV-Boost receives two fictional bids for the same slot and parent block. Both arrive in time, pass the bid checks and are otherwise comparable. Builder A offers 0.20 ETH and Builder B offers 0.15 ETH. In this example the proposer takes the best external bid, so A is selected and offers 0.20−0.15=0.050.20-0.15=0.05 ETH more. The spread compares two offers for a block. In a priority gas auction, traders compete for favourable execution order by bidding up transaction fees.
Fictional bids of 0.20 and 0.15 ETH reach the relay layer. The proposer sees the winning 0.20 ETH bid and header, signs the blinded block, and relies on the relay to unblind that same block. The bid spread is 0.05 ETH.
Fictional bids of 0.20 and 0.15 ETH reach the relay layer. The proposer sees the winning 0.20 ETH bid and header, signs the blinded block, and relies on the relay to unblind that same block. The bid spread is 0.05 ETH.
The relay layer sees both full payloads. The proposer sees a header and price before signing, and the signature fixes which payload can be revealed.
Before signing, the validator can use a locally built block if no eligible relay bid arrives or all bids fall below its configured minimum. After the signed blinded block is sent, a failed reveal can cost the proposer the slot. Signing a different block for that slot risks slashing. The relay therefore matters both for which offers reach the proposer and for whether the chosen payload is published in time. MEV-Boost minimum bid documentation · Ethereum Builder API’s proposer slashing guidance
For revenue analysis, keep the offered bid, relay delivery and the payment realised on the canonical chain as separate observations. A relay’s data API reflects the submissions and deliveries that particular relay handled. Flashbots’ relay data API overview

What changes with enshrined PBS?

MEV-Boost arranges the handoff outside Ethereum’s consensus rules. Enshrined PBS (ePBS) under EIP-7732 puts the builder’s payload commitment and the subsequent reveal into the protocol and provides a protocol mechanism for paying the proposer from the builder’s stake. As of 8 November 2026, Glamsterdam, the upgrade that includes ePBS, was still being tested on testnets, with no confirmed Ethereum mainnet activation date. The Ethereum Foundation’s 6 November update said the Hoodi testnet upgrade remained on hold. EIP-7732 · Glamsterdam activation status · Ethereum Foundation’s 6 November update

Sources

Last updated
  • ethereum
  • mev
  • block building
  • validator revenue
  • relays
← Back to the glossaryBack to top ↑