Skip to content
Financial Context Wiki

Proposer-builder separation (PBS)

Proposer-builder separation splits block construction from consensus proposal. Learn how Ethereum's MEV-Boost market works, how it differs from enshrined PBS, and where relay, censorship, concentration, and missed-slot risks remain.

Updated

For educational purposes only; not investment or validator-operations advice. PBS does not remove MEV, censorship, missed-slot, relay, builder-concentration, or protocol-design risk.

Direct answer

Proposer-builder separation (PBS) splits two block-production jobs. A builder chooses and orders transactions and constructs an execution payload; the consensus proposer selected for the slot chooses a payload commitment, signs the block proposal, and broadcasts or causes the complete block to be published. The proposer remains a validator with consensus duties. A builder is a separate market role and, in today’s external market, need not be the slot’s validator.

On Ethereum, distinguish the system used today from proposed protocol changes. MEV-Boost is out-of-protocol PBS: validator middleware queries relays that mediate an auction between builders and proposers. Enshrined PBS (ePBS) would put the exchange and enforcement into Ethereum’s consensus rules. As of the fact-check date, Ethereum describes in-protocol PBS as active research without a finalized specification, and EIP-7732 remains a draft proposal.

PBS aims to let validators access competitive block value without each validator operating a sophisticated MEV search and block-building stack. That can reduce a centralizing advantage among proposers, but it does not eliminate MEV. It moves specialized construction into a builder market and introduces questions about relay trust, builder and order-flow concentration, censorship, timing, and payload availability.

How it works

  1. Builders construct and bid. Builders receive public transactions and, often, private order flow or searcher bundles. They simulate candidate blocks, order transactions, produce a valid execution payload, and attach a bid representing the payment offered to the proposer.
  2. Relays mediate the current market. In the MEV-Boost design, a relay receives the complete payload from a builder, checks the submission according to its policy, and exposes a signed header and bid without initially revealing the transaction body to the proposer. MEV-Boost can query multiple configured relays and compare usable responses.
  3. The proposer selects a commitment. The proposer may compare external bids with a locally built payload and apply software settings such as a minimum bid. If it accepts an external bid, it signs a blinded beacon block committed to the selected payload header; it cannot then substitute different transactions into that payload.
  4. The payload is revealed and validated. After receiving the signed blinded block, the relay returns or publishes the full execution payload. Consensus and execution clients validate the resulting block. A late, unavailable, or invalid payload can impair publication and may cause a missed slot.
  5. Payment and consensus remain distinct. The builder’s bid is the promised execution-layer payment to the proposer’s configured fee recipient. Consensus-layer proposal rewards and penalties follow separate protocol rules. Choosing a builder does not transfer finality or fork-choice authority to that builder.

The Builder API standardizes interfaces such as validator registration, header retrieval, and submission of a signed blinded block. An API specification is not itself a trust guarantee: relay admission, validation, data handling, and failure behavior still depend on the implementation and deployment.

Example

Suppose a validator’s local execution client can build a payload worth 0.03 ETH, while usable relay bids are 0.05 ETH, 0.08 ETH, and 0.07 ETH. Ignoring latency and failure costs, the highest external bid offers a gross uplift of 0.05 ETH over local construction:

Gross uplift = builder bid - local payload value = 0.08 ETH - 0.03 ETH = 0.05 ETH

The proposer selects the 0.08 ETH header and signs the blinded block without seeing its full transaction list. The relay then supplies or publishes the committed payload. If the block is valid and timely, the network processes it and the configured fee recipient receives the builder payment. The proposer still performs its consensus role; the builder does not decide whether the block becomes canonical or final.

This comparison is not a guarantee of net income. Relay latency, a failed reveal, software behavior, payment verification, and the probability and cost of a missed slot all matter. If no external bid satisfies the proposer’s policy in time, a correctly configured client may use its local payload instead.

Risks

  • Relay trust and availability: Current MEV-Boost relays mediate fair exchange, see full builder payloads, apply admission and validation policies, and sit on a time-critical path. Relay diversity reduces dependence on one endpoint but does not make every relay honest or available.
  • Builder and order-flow concentration: Builders with better private order flow, latency, capital, or simulation infrastructure may win more blocks. A competitive auction for proposer revenue does not by itself guarantee decentralized construction or neutral transaction inclusion.
  • Censorship and privacy: Builders or relays can omit transactions, and private order flow may be visible to intermediaries. Proposed inclusion-list mechanisms are separate protocol designs; current PBS does not automatically force inclusion of every valid transaction.
  • Timing, withholding, and missed slots: A high bid is useful only if the committed payload is valid and delivered in time. Builder withholding, relay failure, network delay, or a bad configuration can reduce rewards or cause the proposer to miss its slot.
  • Changing protocol assumptions: ePBS proposals such as EIP-7732 change payment, reveal, validation, and fork-choice mechanics. Because the proposal is a draft, operators and researchers must use the specification for the deployed fork rather than treating roadmap language as an active guarantee.

Common misconceptions

Myth 1: PBS eliminates MEV

PBS separates who constructs and who proposes the block. Builders can still compete to extract MEV; the design seeks to reduce MEV’s centralizing effect on validators and distribute block value through bids.

Myth 2: The builder proposes or finalizes the block

The builder constructs an execution payload. The slot proposer signs the block proposal, other validators attest, and Ethereum’s fork-choice and finality rules determine the canonical chain.

Myth 3: MEV-Boost already is trustless, protocol-enforced PBS

MEV-Boost is external middleware using relays. It approximates PBS without changing Ethereum consensus, so its trust and failure assumptions differ from a future enshrined design.

Myth 4: The highest displayed bid is always the best choice

Bid value is only one input. Validity, delivery timing, relay behavior, local fallback, fee-recipient configuration, and missed-slot risk affect the actual outcome.

Sources

Navigation

Search the wiki...