ePBS stands for enshrined proposer-builder separation. EIP-7732 moves the builder’s payload commitment and its payment relationship with the proposer into Ethereum’s consensus rules. The proposer can commit to a builder’s block without relying on a relay to enforce that exchange.
For searchers, the important change is timing. A consensus block and its execution payload no longer arrive as one object. The payload can arrive later, leaving less time to observe the new state, simulate a trade and reach the builder of the next block.
Updated October 1, 2026: ePBS activates on Sepolia at epoch 353024 on October 6, 2026 at 13:53:36 UTC, per the EF’s Glamsterdam testnet announcement. It is not live on Ethereum mainnet and no mainnet epoch is set; the EF’s September priorities update describes a December 2026 target, and a target is not an activation timestamp. EIP-7732 remains in Review, and client releases and fork announcements are the sources to use for deployment scheduling.
Why proposer-builder separation exists
The validator selected to propose a block does not necessarily have the infrastructure to build the most profitable one. Building involves selecting public transactions, receiving private order flow, simulating bundles and arranging them without nonce or state conflicts. That is a different job from participating in consensus.
Proposer-builder separation lets specialists construct payloads and offer payments for having them proposed. The proposer can select a bid instead of running its own searcher and builder operation. Local block building remains an option.
Today, MEV-Boost implements that separation outside the protocol. Relays sit between builders and proposers. They validate submitted blocks and bids, offer headers to proposers, then reveal the selected payload after receiving a signed blinded block.
The relay matters because neither side wants to move first without protection. A builder does not want to reveal a valuable payload that a proposer can copy without paying. A proposer does not want to sign a commitment to an unavailable or invalid payload. Relays mediate that exchange, so their correctness and availability affect both parties.
EIP-7732 changes the trust mechanism. It does not remove the work of building, simulating or distributing bids, and it does not require every service currently called a relay to disappear.
How EIP-7732 changes the block
The beacon block contains a signed execution-payload bid rather than the full execution payload. The bid identifies the builder and commits to a particular payload hash. The builder later publishes a signed payload envelope matching that commitment.
The proposal also introduces a builder registry in beacon-chain state, separate from the validator registry. In the trustless payment path, builders maintain a balance from which the protocol can enforce payment to the proposer. The specification also accommodates trusted payment promises, so “every bid is always fully collateralized” is too broad a description of the design.
A Payload Timeliness Committee, or PTC, attests to whether the committed payload arrived on time. The current EIP preset has 512 members. These committee members perform the required basic checks, including the commitment and signature checks; they do not need to execute the full payload before reporting timeliness.
Execution validation is deferred, not removed. Nodes still need to execute the payload and reject invalid execution. The distinction is that full execution no longer sits on the same critical path as the initial consensus-block vote.
A proposer can still build locally. EIP-7732 specifies a self-build path rather than making participation in the external builder market mandatory.
The slot now has separate consensus and execution steps
The diagrams below show the proposed sequencing. The second marks illustrate the design, not a guaranteed production deadline or a measured RPC delivery time. Use the parameters in the client and network you are testing.
The important sequence is:
- Commitment. The proposer publishes a beacon block containing the chosen builder’s signed payload bid. Its hash fixes which execution payload can satisfy that commitment.
- Reveal. The builder publishes the payload envelope. Nodes can receive and execute the transactions.
- Timeliness observation. The PTC reports whether the committed payload was available on time.
- Execution validation. The chain’s subsequent processing incorporates execution validity rather than requiring all of it before the initial consensus-block attestation.
The EIP’s delayed-validation rationale describes a longer execution budget: six seconds for the next proposer and nine seconds for other validators under its specified timing model. That is an execution-validation budget, not nine seconds in which a searcher can submit a bundle to an already committed payload.
Once the payload hash has been committed, a builder cannot add your late transaction to that same payload without changing its hash. This is the deadline that matters to a searcher targeting that block.
What changes for builders
Payment and reveal risk move into the protocol
EIP-7732 distinguishes three outcomes: a full slot with both beacon block and payload, a skipped slot without a beacon block, and an empty slot whose beacon block exists but whose committed payload does not.
For the protocol-enforced payment path, proposer payment can survive that last case. The EIP calls this unconditional payment, under the design’s specified security assumptions. It also describes builder protections for timely reveals and for beacon blocks that are withheld and revealed late.
This does not mean “include a bid under any circumstances and immediately receive irreversible money.” The conditions in fork choice and payment processing matter. Builders should test those transitions using the client implementation, including late and absent payloads, rather than implementing accounting from a simplified diagram.
Bid distribution is still infrastructure
The proposal adds a peer-to-peer topic for signed payload bids. Builders still need to get bids to proposers reliably and in time. Direct services may also exist, but their cancellation behavior, latency and commercial terms are not a standardized searcher API in EIP-7732.
Do not infer a new auction pricing model from the existence of the gossip topic. Whether a service exposes bid updates, cancellation or private distribution depends on that service. Any claim that ePBS necessarily produces a first-price or second-price market goes beyond the protocol rules.
A committed payload can still be withheld
The EIP explicitly discusses the builder’s incentive to withhold a payload if revealing it becomes more costly than abandoning it. Its security considerations call this the free-option problem.
For a builder, that means modelling the period between commitment and reveal. For a searcher, it means a transaction inside a committed payload is not yet an included transaction. A bid or commitment should never be recorded as a successful execution in the bot’s ledger.
Withholding is also the failure developers expect to see on Sepolia. Builder stakes there are paid in free testnet ETH, so one actor can register many builders, win auctions with inflated bids and never reveal a payload; consensus developer Potuz put it as “any teenager can do this” (CoinDesk). Missing payloads on Sepolia will say more about free testnet capital than about mainnet behavior, but they are a good way to test that your bot handles the case at all.
What changes for searchers
Less time on freshly executed parent state
A builder targeting the next slot needs to build on the parent payload’s resulting state. If that parent payload is revealed later in its slot, less of the slot remains before the next payload commitment.
The rough four-to-six-second window shown in the diagram is a model of that sequencing, not a submission SLA. Actual usable time also depends on payload propagation, execution time, builder cutoffs and when the proposer selects its bid.
Measure your own path in parts:
- notification of a new execution head;
- availability of the required state reads at that head;
- completion of the actual executor simulation;
- completion of signing and submission;
- acknowledgement from the intended builder endpoint.
A slow stage is easier to fix when it has its own timestamp. A single “RPC latency” average will not tell you whether you were waiting for new state, doing local computation or missing the builder’s cutoff. The trading-bot RPC benchmark guide covers matched-state measurements and the distinction between acknowledgement and inclusion.
Consensus head is not automatically tradable execution state
Your bot may observe a consensus commitment before its node has received and executed the corresponding payload. A beacon block root, a committed execution hash and an available execution state are not interchangeable signals.
Gate state-dependent decisions on the execution data your strategy actually needs. Record the block hash used for reserve reads and simulation. Do not label an old latest result as the newly committed state just because a consensus notification arrived.
This is particularly important when comparing providers. An endpoint that returns an answer quickly can still be answering from an older head. Compare block hashes and availability as well as request duration.
Missing payloads need an explicit outcome
If a committed payload never appears, the state transition you expected does not occur. Keep that outcome separate from a normal included block, a transaction revert and a missed builder cutoff.
Re-targeting a trade requires more than incrementing a target block field. Check the canonical execution head, account nonce, fees and strategy conditions again. A previously profitable transaction can be stale even when its signature remains valid.
PTC information belongs to the consensus side of the system. Do not assume an ordinary execution-layer WebSocket subscription exposes it directly. Decide which client interfaces your monitoring uses and test them against the combined fork implementation.
What ePBS does not change for your bot
There is no protocol searcher registration. The builder registry is not a requirement for an application that sends transactions or bundles to a builder. Operating both roles is a separate choice.
There is no standard bundle API in EIP-7732. Existing submission services can change their products, but the EIP does not mandate a replacement for eth_sendBundle, a bundle format or a cancellation endpoint. Follow the documentation for the service you submit to.
Private order flow does not become a public pending feed. A builder can still receive transactions privately. Running near a node cannot expose transactions that were never gossiped to it. See why pending transactions go missing before treating a feed’s silence as a connection failure.
Other Glamsterdam EIPs still matter. EIP-7732 is a consensus-layer change. The fork’s Block-Level Access Lists and gas repricing have their own implications for execution and simulation. Passing an ePBS connectivity test is not a gas-compatibility test.
Preparing without guessing final deadlines
Start with a compatible test network and the client versions it specifies. Reproduce a normal payload reveal, an absent payload and a bot that reads state immediately after a head notification. Capture the consensus and execution identifiers separately.
Then run the same measurement stages your production bot uses. Compare the result with the actual builder’s acceptance cutoff, not with a number copied from a draft slot diagram. Keep errors and late responses in the report.
Co-location can reduce the application-to-node network path. BLAZED.sh’s live Ethereum product advertises sub-10ms local RPC round trips; that is not a promise of payload arrival, simulation completion or builder inclusion within the same time. Node execution and the path from your bot to an external builder remain part of the total.
BLAZED.sh hosts Ethereum mainnet today. Testnet access for upgrade rehearsals must be configured separately; do not assume the platform’s local mainnet endpoint is a Glamsterdam devnet.
The change to plan for
ePBS separates the consensus commitment from execution-payload delivery and moves the trustless builder payment path into the protocol. Searchers still need profitable transactions, valid simulations and a working relationship with a submission service. They also need to know exactly when the state behind a commitment becomes usable.
Track the EIP-7732 specification, Glamsterdam roadmap and network announcements as parameters settle. For the next fork’s different constraint on builders, read FOCIL: inclusion is not ordering.