Summary

EIP-7732 (ePBS, enshrined Proposer-Builder Separation) moves the block builder auction from MEV-Boost’s extraconsensus relay to the core Ethereum protocol. Scheduled for Glamsterdam (H1 2026), ePBS eliminates relays as trusted intermediaries, addresses bid adjustment abuses, and creates a cleaner separation between the consensus layer (block structure and proposer commitments) and execution layer (payload content).

Motivation

Problems with MEV-Boost that ePBS solves:

  1. Trusted relays: the relay is a trusted escrow that can adjust bids, censor transactions, or fail — none of which is slashable.
  2. No protocol fallback: if relays go down, proposers miss slots or use local builds (much lower value).
  3. Bid adjustment: ~5% of slots see bid adjustments; ~2% of bid value affected. Builders have no recourse.
  4. Opaque flow: proposers can’t verify that the builder paid the claimed amount without trusting the relay.

How ePBS Works (EIP-7732)

Commit-Reveal Mechanism

The slot is divided into two phases:

Phase 1: Proposer Commitment (consensus)

  1. Builder submits a bid containing: (payload_hash, bid_value, builder_pubkey, conditions).
  2. Proposer selects the highest valid bid and broadcasts a signed commitment to payload_hash at the consensus layer.
  3. The commitment is included in the beacon block.
  4. The builder has guaranteed payment if they reveal the matching payload.

Phase 2: Payload Reveal (execution)

  1. The winning builder broadcasts the full execution payload.
  2. Validators verify: hash(payload) == committed payload_hash.
  3. If the builder fails to reveal: payload withholding penalty (the builder is slashed or loses a bond).
  4. The proposer is paid regardless; the builder’s payment is conditional on reveal.

Timing

  • Commitment: happens at the attestation deadline (~4s into the 12-second slot)
  • Payload reveal: happens at the block production deadline (~8s into the slot)
  • 4-second window: builders know they must reveal, no incentive for last-second timing games after commitment

Builder Bonds

ePBS requires builders to post bonds to guarantee they can pay proposers and to be slashable for payload withholding. This creates a minimum capital requirement for builders.

Finality Nuances Under ePBS (Gloas)

The Gloas research (Potuz, Apr 2026) reveals a subtlety: under ePBS, the beacon block and execution payload are separate objects that may not be co-available:

  • A beacon block can be finalized (voted by ≥⅔ stake) without the execution payload being available.
  • The Engine API safe tag (used by L2 bridges and apps) currently conflates these; it needs updating.
  • Implication: an application that treats a finalized beacon block as a guarantee of payload availability could be wrong in Gloas-aware scenarios.
  • Solution: the Engine API should expose both beacon_safe (beacon block finalized) and payload_safe (payload available + beacon block finalized).

Impact on Relay Ecosystem

Current (MEV-Boost)After ePBS
Relays are trusted; no slashingProtocol-enforced; builders slashable
Relay adjusts bids; undetectableBid committed on-chain; immutable
Relay fails → missed slot or local buildProtocol fallback; no relay needed
Relay location affects latencyLatency from builder ↔ proposer directly

Relays don’t disappear entirely — they may provide ordering services and flow aggregation — but they lose their trusted escrow role.

Impact on Block Building Concentration

ePBS addresses relay trust issues but does not directly address builder concentration:

  • The top 2 builders will still have exclusive order flow advantages.
  • The auction is now on-chain, but the inputs (builder flow, searcher bundles) remain off-chain.
  • Builder bonds create capital requirements that may further disadvantage small builders.
  • FOCIL (Hegotá) is the complementary mechanism to address builder censorship.

Geographic Impact

  • MEV-Boost relay locations (US/EU) disadvantage Asian validators who must reach relays with ~120ms additional latency.
  • Under ePBS, the builder directly communicates payload to the proposer; the latency bottleneck shifts to builder ↔ proposer.
  • If builders remain US/EU-concentrated, Asian validators may still be disadvantaged.
  • The block propagation path changes: payload goes through GossipSub rather than relay-to-proposer, which benefits from geographic P2P improvements.

Current Status (2026)

  • EIP-7732 is finalized and scheduled for Glamsterdam (H1 2026).
  • Implementation is in progress across multiple client teams.
  • The Gloas research (Apr 2026) raises open questions about finality semantics that may need Engine API updates before deployment.

Open Questions

  • What should the Engine API safe tag mean after ePBS? (Current proposal: safe = beacon block finalized + payload available)
  • How does ePBS interact with relay block merging? (Merging is a relay-layer enhancement; ePBS makes relays optional)
  • Should builder bonds be denominated in ETH or a separate token?
  • How do partial block reveals (e.g., headers only) interact with ePBS’s commit-reveal?

Key Sources

  • Three Years of PBS (Dec 2025) — motivation; structural gaps ePBS addresses
  • What is Finalized in Ethereum (Apr 2026) — Gloas finality; beacon block vs. payload availability; Engine API implications
  • Protocol Priorities Update for 2026 (2026) — Glamsterdam EIP list; ePBS confirmed