Glamsterdam is the next Ethereum hard fork after Fusaka, and its headline consensus change is EIP-7732, enshrined proposer-builder separation (ePBS). Devnets have been running the full Glamsterdam slate since June, public testnets fork next, and mainnet is targeted for the second half of 2026. If you build blocks or run a searcher, this is the largest restructuring of the block production pipeline since MEV-Boost appeared.
Here is the short version: the strategy layer of MEV mostly survives ePBS intact. The timing layer does not. The auction moves on-chain, the payload lands mid-slot instead of at the slot boundary, and the window in which a bundle can reach a builder and make it into a committed payload gets meaningfully tighter. Everything that was already a latency game becomes more of one.
What EIP-7732 actually changes
Today, roughly nine out of ten validators outsource block building through MEV-Boost. The proposer asks relays for the best header, signs it blind, and trusts the relay to reveal the payload and to have verified that the builder’s payment is real. The relay is unpaid, trusted middleware holding the whole market together.
ePBS moves that market into the protocol. Builders register as staked entities on the beacon chain, in their own registry next to the validator set, and every bid they sign is backed by their on-chain balance. The beacon block stops carrying the execution payload entirely; instead it carries the winning builder’s signed bid, which commits to the exact block hash of a payload along with the bid value, gas limit, fee recipient, and blob commitments. The moment a proposer includes that bid, the value is deducted from the builder’s balance. Payment is unconditional, meaning the proposer gets paid even if the builder never reveals the payload, and that is precisely why nobody needs a relay to escrow trust anymore.
The payload itself arrives later in the slot. After the beacon block has been attested, the builder publishes the full payload, and a Payload Timeliness Committee (PTC) of 512 validators attests to whether it showed up on time. Full execution validation moves off the attestation critical path entirely. Proposers who want nothing to do with the market can still build their own payload; self-building stays a first-class option in the protocol.
Glamsterdam pairs this consensus-side change with EIP-7928 Block-Level Access Lists on the execution side, which is what unlocks the fork’s push toward much higher gas limits. But for MEV infrastructure, ePBS is the change that rearranges the furniture.
The new slot anatomy
The point of splitting consensus from execution is time. Today a block has roughly two seconds to propagate and be validated before attestations are due. Under ePBS that critical window stretches to roughly nine seconds, because attesters vote on the consensus block without executing the payload at all.
The slot opens with the proposer publishing the beacon block, which locks the payload contents to a specific block hash. Attesters vote on that consensus block early in the slot without touching the payload. Somewhere around the middle of the slot the builder reveals the full payload (blobs get their own, later deadline), and the PTC attests that the payload matching the committed hash arrived in time. The rest of the slot belongs to execution: nodes apply the payload and update state, and execution validity is checked against the next block instead of blocking this slot’s attestations.
The exact second marks are still being tuned on devnets, but the shape is settled, and two properties of it matter enormously for MEV: the payload is committed at the slot boundary, and it becomes public only mid-slot.
What ePBS means for builders
Building becomes a capital business. Unconditional payment means your beacon chain balance has to cover your bids, and while the registry minimum is small, bidding competitively on a high-value block means parking serious collateral on-chain and eating its opportunity cost. Expect consolidation pressure, and expect new financial plumbing around it; some relays are already positioning themselves as capital providers that re-sign bids for a fee rather than as auctioneers.
The auction changes shape as well. Bids travel over two channels: a rate-limited p2p gossip topic that is public but not cancellable, and direct connections to proposers that are cancellable and faster. The transparent second-price dynamics of today’s relay auctions do not carry over cleanly, because builders with direct proposer connectivity can shade their public bids, which pushes the market toward first-price, sealed-bid behavior. Bid strategy becomes a genuinely new problem to solve.
A builder that wins the header can also simply decide not to reveal the payload. The bid is paid regardless, so the downside is capped, and in volatile moments the option to abandon a committed payload has real value. Slots will occasionally go empty in ways today’s pipeline does not produce.
Relays, meanwhile, stop being load-bearing. Nothing in ePBS needs a trusted third party to exchange a blind header for a payload or to vouch for payment, so whatever survives of the relay ecosystem survives as optional infrastructure for bid distribution, analytics, and capital services.
What ePBS means for searchers
Your relationships do not change: you still send bundles and private flow to builders, and builders still compete to include them. What changes is when everything has to happen.
Start with the window. Today the parent payload is public at the slot boundary, so a builder has essentially a full slot, ten seconds and more, to build on known state before the next proposal locks. Under ePBS the parent payload only becomes public mid-slot, while the next header still locks at the next slot boundary. That leaves roughly four to six seconds of building on fresh state, depending on where the reveal deadline finally lands. Your bundle has to reach a builder, simulate against the new parent state, and get merged into the payload whose hash the builder commits to, all inside that window.
The head of the chain also starts arriving in two steps. The consensus block tells you which payload hash won; the state behind it only exists for you once the payload is revealed and your node has executed it. If your view of the chain comes from a public RPC provider, you are waiting on their fan-out, their nodes’ execution, and the public internet, stacked on top of a reveal that already happens mid-slot. The searchers who see post-state first are the ones whose code sits where the payload lands.
Withholding adds a kind of variance searchers have not had to price before. When a builder abandons a committed payload, every bundle inside it dies too, and the state you predicted never materializes. Detecting an empty slot fast, from the PTC signal and your own node’s view rather than a delayed provider feed, decides whether you re-target the next block in time. And none of this makes timing games disappear: proposers can still propose late, builders will reveal as close to the deadline as tolerated, and cancellable direct-connection bids keep last-look dynamics alive. The games move earlier in the pipeline and run on smaller margins.
Why latency to the node matters more under ePBS
Every one of these changes shrinks a time budget that was already tight, and that raises the price of every network round-trip in your loop. We covered the general argument in why MEV is a latency game; ePBS sharpens it. A multi-pool simulation that does its state reads over public RPC spends a real fraction of a four-to-six-second window on round-trips alone, while the same loop running on the node does those reads as local socket calls. The per-call gap between those transports is measured in IPC vs HTTP vs WebSocket.
The payload reveal becomes the new critical moment. The instant it hits the wire, your node executes it and the post-state exists on that machine, so co-located code reads it immediately while remote code waits on a provider pipeline it can neither see nor control. The mempool stays decisive too, because ePBS does not touch it: pending transactions remain the raw material, and watching them from your own node’s connection beats a downstream relay. The mechanics are in how to access the Ethereum mempool, and you can watch the pool live on the BLAZED.sh mempool visualizer.
This is exactly the model BLAZED.sh is built around: your container or script deploys onto the same host as a fully synced Ethereum node and talks to it over a local socket instead of racing across the public internet. When the game restructures around a mid-slot reveal and a compressed build window, being on the node is not an optimization, it is the starting line.
How to prepare before Glamsterdam ships
There is a concrete checklist hiding in all of this. Rehearse against the public testnets; Holesky and Hoodi fork before mainnet, and the exact slot timings and PTC parameters will settle there, so you can learn the new rhythm somewhere other than mainnet. Measure your full trigger-to-submission path today, because anything that spends a second on remote round-trips will not fit comfortably in a post-ePBS build window. And move the evaluation loop onto the node, so the mempool subscription, the state reads, and the view of the payload reveal are all local. The deployment docs cover containers and scripts, supported networks lists what is live, and RPC pricing explains the credit model.
FAQ
When does ePBS go live?
EIP-7732 ships with Glamsterdam. Multi-client devnets have been running the full fork since June 2026, public testnets are next, and mainnet is targeted for the second half of 2026. Dates firm up once the testnet forks hold stable.
Does ePBS kill MEV-Boost and relays?
It removes their trust role. The header-for-payload exchange and the payment guarantee move into the protocol, so proposers no longer need MEV-Boost or a trusted relay to outsource building safely. Relay-like services may persist for bid distribution and builder capital, but they stop being load-bearing.
Do searchers need to stake under ePBS?
No. Only builders register and stake on the beacon chain. Searchers keep sending bundles to builders exactly as today; what changes for searchers is timing, not access.
Does ePBS change the mempool?
No. Public and private transaction flow work as before. The mempool remains the primary signal source for searchers, and low-latency access to it remains an edge.
Conclusion
ePBS re-times the entire block production pipeline: the auction commits at the slot boundary, the payload lands mid-slot, and the window between fresh state and the next committed block shrinks to a few seconds. Strategy still decides which plays are worth making; under EIP-7732, latency decides even more of who makes them. If your searcher currently races over public RPC, the time to fix that is before Glamsterdam reaches mainnet, not after. Start with the co-location argument, then the deployment docs.