Ethereum Developers Lock in EIPs for Glamsterdam Upgrade

The Glamsterdam hard fork has entered its final devnet phase, and two significant EIPs are now confirmed for mainnet activation in the second half of 2026: EIP-7732, known as Enshrined Proposer Builder Separation (ePBS), and EIP-7928, Block Level Access Lists. For anyone building on or around Ethereum's execution layer — whether directly or through L2 bridges and sequencing infrastructure — these aren't abstract governance milestones. They reshape how blocks are constructed and how state access is priced at the protocol level. If you're maintaining smart contract deployments or optimizing for gas efficiency, the clock on your compatibility planning just started ticking louder.

What EIP-7732 Actually Changes

Proposer-Builder Separation has existed in practice for years through MEV-Boost and relay infrastructure. What EIP-7732 does is enshrine that separation into the protocol itself — no more reliance on out-of-protocol middleware to mediate between proposers and builders. In production terms, this means the protocol formally acknowledges and governs the block construction pipeline rather than leaving it to external infrastructure.

The trade-off here is nuanced. On one hand, enshrining PBS reduces trust assumptions in the MEV supply chain — proposers no longer need to blindly trust relay operators. Conversely, it introduces new protocol-level complexity that client teams must implement and maintain. For developers working on MEV-aware contracts or building tooling that interacts with block ordering, the interface changes. You'll want to track how the new builder market functions in devnet before mainnet, particularly if your contracts depend on transaction ordering assumptions or use backrunning strategies.

For related context, see CoreWeave Unveils ARIA to Accelerate AI Research and Agent Development.

Block-Level Access Lists and Parallel Execution

EIP-7928 — Block Level Access Lists — is arguably the more interesting one from a systems architecture perspective. Access lists already exist at the transaction level (EIP-2930), but moving this concept to the block level has implications for how execution clients can parallelize state reads and writes.

In practice, this means an execution client can inspect the block's aggregate access list before processing transactions sequentially. The result: potential for more aggressive parallelization of independent state accesses. For L2 sequencers and rollup architectures, this matters because calldata posting and L1 state verification are bottleneck-sensitive operations. If L1 execution can process access patterns more efficiently, the cost floor for L2 settlement could shift.

That said, the actual throughput gains depend heavily on client implementation. The access list is only useful if execution engines are rewritten to exploit it — and that's client-team-dependent work that won't happen overnight.

What to Watch Between Now and Mainnet

With Glamsterdam in its final devnet stage, the most practical thing developers can do is start testing against devnet specifications. If your deployment pipeline assumes current block construction semantics, verify compatibility with ePBS. If you're optimizing calldata costs for L2 settlement, monitor how client teams implement Block Level Access Lists — the gas accounting could shift.

The broader signal here is architectural: Ethereum is systematically internalizing what was previously outsourced infrastructure. PBS goes from middleware to protocol. Access patterns go from transaction-level hints to block-level metadata. Each step reduces external dependencies but increases protocol surface area. That's a trade-off the core devs have clearly decided is worth making.

Don't wait for mainnet announcements to start validating your assumptions against the devnet specs.