Ethereum ePBS Explained: How EIP-7732 Splits Block Building

Ethereum already has specialized block builders, but the handoff between a builder and a validator mostly happens through software outside the protocol. Ethereum ePBS, specified in EIP-7732, is designed to bring that exchange into Ethereum's consensus rules. It is one of Glamsterdam's headline changes, and it makes more sense with the broader blockchain infrastructure basics in view.

The short version: a consensus proposer chooses a signed bid, the chosen builder later reveals the execution payload, and a committee reports whether that payload arrived on time. The design aims to reduce reliance on trusted relays and give payload propagation more breathing room. It does not eliminate MEV, guarantee builder decentralization, or make every transaction instantly final.

Note

As of September 28, 2026, EIP-7732 is in Review. Ethereum.org lists ePBS as scheduled for Glamsterdam and names October 6 as the next Sepolia milestone, but the mainnet date is not confirmed. Exact mechanics and timing can change before activation.

What is enshrined proposer-builder separation?

A proposer is the validator selected to publish the consensus block for a slot. A builder assembles the execution payload: the ordered transactions, their results, and related execution data. One operator can do both jobs, but specialized builders often compete to construct valuable payloads.

Today, many proposers use MEV-Boost and relays. A relay sits between builders and proposers, checks bids and payloads, and helps prevent either side from cheating during the exchange. That arrangement is useful, but Ethereum's consensus protocol cannot enforce every promise made inside it.

Enshrined proposer-builder separation moves the core bid, commitment, reveal, and payment relationship into protocol rules. Think of a sealed freight auction. The proposer chooses a signed shipping offer without opening every container; the builder must deliver the matching cargo by a deadline; designated inspectors report whether it arrived; and payment follows terminal rules rather than a private broker's promise.

Question	Out-of-protocol PBS today	ePBS under EIP-7732
Who assembles transactions?	Usually a specialized builder	A builder, including a possible local builder
Who selects the block?	The slot proposer	The consensus proposer
What carries the exchange?	MEV-Boost, relays, Builder API	Consensus objects and fork-choice rules
How is timing observed?	Relay and client workflows	Payload Timeliness Committee votes
Are relays forbidden?	No	No; optional services can remain

How an ePBS slot works

1. Builders prepare bids

A builder constructs a candidate execution payload and signs a bid. The bid commits to details such as the parent and payload block hashes, fee recipient, gas limit, and value offered to the proposer. The Gloas consensus specification is the implementer reference and explicitly warns that its draft can change.

2. The proposer chooses a bid

The consensus proposer compares valid bids and includes one in its beacon block. It does not need the full execution payload on the critical path before publishing that block. The design also supports a locally built payload, so a proposer is not forced to outsource.

3. The builder reveals the payload

After selection, the builder broadcasts the matching signed execution payload envelope. Nodes check that the reveal matches the commitment. A builder cannot safely substitute a different payload after winning.

4. The PTC reports timeliness

Some validators are assigned to the Payload Timeliness Committee (PTC). They attest to whether the committed payload arrived on time and passed the required basic checks. This is a timing and availability signal, not a permanent replacement for full execution validation.

The current Gloas validator specification separates the beacon-block attestation, payload reveal, and payload-attestation deadlines. Moving full payload work away from the earliest deadline gives validators more time to validate execution and data availability.

5. Fork choice and payment settle the outcome

Fork choice distinguishes a full slot, an empty slot with a beacon block but no timely payload, and a skipped slot. EIP-7732 aims to protect payment for an honest proposer and canonical inclusion for an honest builder's timely payload under its security assumptions. Protocol-managed builder balances and pending payments give builders new funding and operational duties.

Why Ethereum is changing the block pipeline

The current pipeline compresses heavy work into a short window. Validators receive a beacon block with an execution payload, execute it, check associated data, and decide how to attest. Bigger payloads make that hot path harder across a geographically distributed network.

EIP-7732 separates the consensus block from the later payload reveal. The EIP says the next proposer gets about six seconds to validate the payload and other validators about nine seconds, rather than requiring full execution validation in the earliest attestation window. Ethereum.org summarizes this as expanding payload propagation time from roughly two seconds to about nine.

That is not “free throughput.” It is an engineering budget that can support larger payloads or more blob data without forcing home validators to finish everything immediately. Glamsterdam pairs this timing change with block-level access lists, which approach state access and parallel processing from another angle.

What changes for users and operators

Wallet users and applications

Most users will not choose builders, join a PTC, or migrate ETH. A transaction still competes for inclusion, and its fee still depends on demand and execution. ePBS is primarily infrastructure.

Confirmation language needs care. EIP-7732 notes that a transaction included in slot N is not widely validated until the next proposer builds on it and attesters vote for that head. Wallets, exchanges, bridges, and rollups should test what “included,” “executed,” “safe,” and “finalized” mean after the fork instead of treating a payload reveal as instant finality.

Validators, pools, and builders

Consensus clients gain bid, payload, PTC, and fork-choice duties. A validator may receive a PTC assignment and must be online for its deadline. Pools, DVT providers, and monitoring systems must observe consensus blocks and payloads separately.

The Ethereum Foundation's Platåberget announcement asks solo stakers, DVT projects, custom software teams, and large operators to test the builder flow and deposits. Builders must maintain the required balance, issue valid bids, reveal the exact payload, and meet the deadline. Relays can still provide aggregation, policy, routing, privacy, or monitoring; “enshrined” does not mean all middleware disappears.

Risks and limitations

Specification risk: EIP-7732 remains in Review, and the Gloas spec is work-in-progress.
Builder concentration: native PBS does not automatically create a competitive builder market.
Withholding: a winning builder can fail to reveal, leaving an empty execution slot even when payment rules work as designed.
Implementation complexity: clients coordinate blocks, bids, envelopes, PTC messages, balances, and new fork-choice states.
Network timing: latency and partitions can make one-sided monitoring misleading.
MEV remains: ePBS changes the exchange, not transaction-ordering value or every censorship incentive.
Finality confusion: timely publication is not economic finality; applications still need risk-appropriate confirmation policies.

These are protocol risks, not an ETH price thesis. Crypto assets remain volatile; never commit funds you cannot afford to lose.

Practical readiness checklist

Identify whether you operate a wallet, indexer, client, builder, relay, or staking pool.
Name beacon publication, payload reveal, PTC timeliness, execution validation, safe head, and finalized head separately.
Test empty and late-payload paths, not only healthy slots.
Record client versions, network configuration, spec commit, and test date.
Use testnet funds for builder deposits and validator experiments.
Recheck the Glamsterdam roadmap and official client releases before activation.

Frequently asked questions

Is ePBS live on Ethereum mainnet?

No. As of September 28, 2026, Ethereum.org describes Glamsterdam as testing and lists the October 6 Sepolia fork as the next milestone. No confirmed mainnet activation date is published.

Does ePBS remove MEV-Boost and relays?

It removes the need to trust a relay for the basic payload-for-payment exchange. Middleware may still provide additional services, so relays are not prohibited or automatically erased.

Does the PTC execute every transaction before voting?

No. PTC members perform basic payload checks for their timeliness signal rather than completing full execution before that vote. Full node validation still matters.

Will ePBS lower my gas fee?

Not directly. It changes the block-production pipeline and creates more propagation time. Fees still depend on gas rules and blockspace demand.

Is ePBS the same as proposer lookahead?

No. EIP-7917 proposer lookahead exposes future proposer assignments earlier. EIP-7732 defines the proposer-builder payload and payment exchange.

Primary sources

Bottom line

EIP-7732 turns the proposer-builder handoff into a consensus-visible process: the proposer commits to a bid, the builder reveals the payload, the PTC reports timeliness, and protocol rules handle payment and fork choice. That creates more time to move and validate execution data while reducing a core relay trust dependency.

It is also a major consensus change with new duties and failure modes. Test assumptions on Sepolia, label confirmation states precisely, and verify the final specification before mainnet. This guide is educational, not financial advice; do your own research (DYOR/NFA).