Glamsterdam ePBS: How Proposers and Builders Divide Block Production

Building an execution payload and proposing a consensus block are different jobs. Ethereum's planned enshrined proposer-builder separation, or ePBS, makes their hand-off part of the protocol. Understanding that hand-off helps explain the upgrade without turning it into a claim about instant confirmation or guaranteed application performance.

Status checked November 6, 2026: the Ethereum Foundation's October 22 Hoodi update postponed the previously scheduled Glamsterdam activation. It supplied no replacement activation time and did not set a mainnet date. Treat the mechanism below as a planned upgrade feature and check current announcements before arranging network-specific tests.

Start with the two jobs

Ethereum's proposer-builder separation documentation describes builders as specialized participants that order transactions and assemble execution payloads. Validators retain consensus responsibilities, including proposing and voting on blocks. Existing external building arrangements use middleware to connect these roles, introducing trust assumptions around the hand-off.

The distinction is useful even outside protocol work. “The block producer” can refer to different responsibilities in different tools. When reading a log or writing an incident report, identify whether you mean the party assembling transactions, the validator proposing the consensus block, or the client validating execution.

An operator can perform more than one role. Separating the roles in the protocol does not require every role to belong to a different company or machine. For troubleshooting, responsibilities are the more useful starting point than organizational labels.

A commitment arrives before the payload

The current EIP-7732 specification replaces the execution payload inside the beacon block body with a signed builder commitment. That commitment identifies the promised execution block and a payment value. The builder reveals the corresponding execution payload later.

A Payload Timeliness Committee, drawn from validators, reports whether the matching payload was revealed on time and whether blob data was available from its members' perspective. That task is separate from full execution validation, which is deferred in the proposed processing flow.

The EIP page remains marked Last Call at this review. A review deadline passing does not establish mainnet activation, and implementation details should be checked against the client versions used for testing.

For an application engineer, the distinction between “a commitment was observed” and “execution has been validated” is the part to retain. Avoid assigning both observations the same success label in tools you build.

What putting the exchange in the protocol means

The Glamsterdam roadmap describes ePBS as moving the proposer-builder exchange and builder payment mechanics into Ethereum's protocol. It aims to reduce reliance on trusted third-party relays for that core exchange and make more of the slot available for payload propagation and processing. Participants may still use optional middleware for additional features.

That changes where some responsibilities are enforced. It does not, by itself, establish a performance result for your application, ensure that a particular transaction is included, or eliminate the need to monitor infrastructure.

Our practical recommendation is to treat this as an ownership review. For each component you run, write down the inputs it trusts, the checks it performs, and the event that allows the next component to proceed. Review those boundaries again when client releases change them.

Build an event timeline before an alert

Suppose a dashboard currently has one green light labeled “block received.” During upgrade preparation, ask what event turns it green. Is it a consensus message, an execution payload becoming available, an execution client's accepted result, or a later confirmation policy? If the team cannot answer, the metric needs a clearer definition before it becomes a paging rule.

For a test environment whose fork activation has been confirmed, we suggest recording a timeline rather than choosing a single latency number:

Use actual client logs and documented interfaces available in that environment. This table is a proposed diagnostic plan, not a list of new public RPC methods. Record the network, slot or block identifier, client versions, and clock synchronization assumptions alongside the observations.

Keep application acceptance criteria explicit

Application teams can prepare without implementing builder infrastructure. Review user-facing wording for “submitted,” “included,” and “confirmed,” and connect each term to the evidence your application actually checks. Keep handling for unavailable data, delayed results, and changed chain views in the same review.

Validator and builder operators need a more specialized plan based on their client teams' release instructions. Before a rehearsal, confirm the active fork configuration across the execution client, consensus client, validator software, and any external building components you use.

A useful rehearsal ends with a trace the team can explain: who made each commitment, what arrived, which checks ran, and why the application accepted the outcome. That is a concrete preparation target while Glamsterdam's revised activation schedule remains pending.