Ethereum Glamsterdam Upgrade: ePBS, BAL & 200M Gas Limit

Ethereum's next major upgrade has a name, a date, and a mission. Glamsterdam — combining the Amsterdam execution layer and Gloas consensus layer upgrades — is the network's most ambitious protocol overhaul since the Merge. It reached its final devnet stage in June 2026, with Sepolia testnet activation tentatively set for August 3 and mainnet deployment around September 16.

For builders, Glamsterdam is not just another fork. It fundamentally reorganizes how Ethereum builds blocks, verifies transactions, and prices permanent storage. The goal: clear the path for a 200 million gas limit while preventing the database from ballooning out of control.

Here's what every smart contract developer and protocol builder needs to understand about Glamsterdam — the EIPs that matter, the breaking changes to watch for, and the opportunities the upgrade unlocks.

ePBS: Enshrined Proposer-Builder Separation (EIP-7732)

The biggest structural change in Glamsterdam. Enshrined Proposer-Builder Separation — ePBS or EIP-7732 — formally separates the proposer (who selects the consensus block) from the builder (who assembles the execution payload), baking this relationship directly into the protocol.

Today, the proposer-builder relationship runs through off-protocol middleware like MEV-Boost and third-party relays. That creates two problems. First, it introduces trust assumptions — relays can theoretically censor or reorder transactions without protocol-level recourse. Second, it forces validators into a brutal 2-second "hot path" window where they must handle consensus, execution, data availability, and attestation simultaneously. This bottleneck caps how much data the network can safely process per block.

ePBS extends the execution payload propagation window from roughly 2 seconds to about 9 seconds. A Payload Timeliness Committee (PTC) verifies that builders deliver their promised payloads on time, and trustless builder payments become part of the protocol itself. Builders and proposers can still use relays for complex features, but the critical path no longer depends on them.

For the average builder, ePBS is mostly invisible — your smart contracts and dApps keep working as before. But it's the foundational change that enables everything else: higher gas limits, more blobs for L2s, and a network that processes larger blocks without risking missed slots or reorgs.

Block-Level Access Lists: The Prerequisite for Parallel Execution (EIP-7928)

If ePBS widens the highway, Block-Level Access Lists (BALs) are the traffic control system that makes parallel lanes possible. EIP-7928 mandates that every block include a complete map of which accounts and storage locations the block's transactions touch — and what their final state looks like after execution.

How BAL Works

Currently, Ethereum processes transactions sequentially because validators do not know in advance which transactions might read or write the same data. Two transactions touching the same storage slot, processed simultaneously, would create race conditions. So validators go one by one, discovering dependencies as they execute.

BALs change this by putting the dependency map directly into the block. The block header stores a hash fingerprint of the access list; the execution payload carries the complete list. Validators can immediately see: these three transactions touch completely disjoint storage — process them in parallel. These two touch the same account — serialize them. This information also enables parallel disk reads and parallel state root computations, dramatically reducing validation time.

The companion EIP-8159 (eth/71) upgrades the peer-to-peer protocol so nodes can actually share these access lists over the network. Together, BALs and eth/71 create the engineering foundation Ethereum needs for true parallel execution — where a single block's transactions can be validated simultaneously across multiple cores rather than in sequence.

Why This Matters for Gas Limits

Parallel validation means blocks can get bigger without validation time growing linearly. A block that takes 12 seconds to validate serially might take only 3 seconds across four parallel lanes. This is how Ethereum gets from the current 60 million gas limit toward the 200 million target without making node hardware requirements unaffordable.

State Cost Rebalancing: The Unsung Scaling Hero

Increasing the gas limit creates a second-order problem: permanent database growth. Every new account, deployed contract, and storage slot occupies disk space that every full node must keep forever. Under current pricing, state growth at a 200 million gas limit would exceed 380 GiB per year — crossing the performance degradation threshold for consumer hardware in under 12 months.

EIP-8037: State Creation Gas Cost Increase

EIP-8037 solves this by separating the pricing of "temporary computation" from "permanent data occupancy." It introduces a Cost Per State Byte (CPSB) that targets a sustainable growth rate of 120 GiB/year. Creating new accounts or deploying large smart contracts will cost more because they impose a long-term storage burden on every node, not just a one-time computation cost.

Critically, EIP-8037 also introduces a reservoir model — a dedicated state_gas_reservoir separate from the standard gas limit. This means the sheer size of an application's data no longer caps out the execution gas limit. As long as developers provide enough ETH to fill the reservoir for state storage, they can deploy much larger smart contracts than today. Combined with EIP-7954, which raises the maximum contract size from approximately 24 KiB to 32 KiB, Glamsterdam meaningfully expands what builders can deploy.

EIP-8038: State-Access Gas Cost Updates

While EIP-8037 addresses creation costs, EIP-8038 recalibrates the cost of reading existing state. Opcodes like EXTCODESIZE and EXTCODECOPY are currently underpriced relative to the actual disk I/O they require — each involves two separate database reads. EIP-8038 brings these costs in line with modern hardware performance and current state size, closing a denial-of-service vector where an attacker could spam cheap state-read operations to slow down blocks.

For dApp developers, this means gas cost simulations need updating. Contracts that frequently read external contract code or perform many SLOAD operations will see cost increases. The flip side: after Glamsterdam, these costs accurately reflect hardware burden, meaning gas limits can increase further without degrading node performance.

Developer Experience Upgrades You Will Use Immediately

Beyond the deep protocol changes, several Glamsterdam EIPs directly improve the developer experience.

Deterministic Factory Predeploy (EIP-7997)

If adopted, EIP-7997 permanently places a minimal factory contract at address 0x12 on every participating EVM-compatible chain. This gives developers a native, built-in way to deploy applications and smart contract wallets to the exact same address across Ethereum mainnet, L2s, and other EVM chains. No more custom CREATE2 salt calculations or chain-specific deployment scripts — just a universal factory producing deterministic addresses everywhere.

ETH Transfer Logs (EIP-7708)

Unlike ERC-20 tokens, native ETH transfers between contracts do not emit standard log events, forcing exchanges, bridges, and wallets to use fragile tracing infrastructure to detect deposits. EIP-7708 mandates a standard log for every non-zero ETH transfer and burn, making deposit detection as reliable for ETH as it is for any token.

Cheaper ETH Transfers (EIP-2780)

EIP-2780 reduces the base intrinsic gas cost for ETH transfers between existing accounts by up to 71%, making everyday payments significantly cheaper. It breaks down the transaction fee to only cover essential work — signature verification and balance updates — while adding a surcharge for transfers that create new accounts. Simple ETH sends become dramatically more affordable.

What Builders Should Do Now

With Sepolia testnet activation tentatively set for August 3 and mainnet around September 16, the window for preparation is roughly six weeks for testnet and about 11 weeks for mainnet.

If you deploy smart contracts on Ethereum or any EVM chain, here is your checklist:

Audit your gas assumptions. EIP-8037 (state creation costs) and EIP-8038 (state access costs) change the gas cost of deploying contracts, creating accounts, and reading external contract code. If your contracts have hardcoded gas stipends or assumptions about deployment costs, those need updating. Run your test suite against Sepolia once Glamsterdam activates there on August 3.

Check contract size limits. EIP-7954 raises the maximum contract size from ~24 KiB to 32 KiB. If you have been splitting contracts to fit under the old limit, you may be able to consolidate. If you are close to the new limit, plan accordingly.

Prepare for ETH transfer logs. EIP-7708 means your indexing infrastructure can switch from fragile tracing to standard event logs for ETH deposit detection. This is an infrastructure simplification, not a compatibility break — but you need to update your indexers to listen for the new log topics.

Monitor Sepolia. Deploy your contracts to Sepolia after the August 3 fork and run your full integration test suite. This is the best way to catch any gas-cost surprises or behavioral changes before mainnet.

If you are building a dApp, a smart wallet, or any EVM-deployed contract, Glamsterdam is the most significant protocol upgrade your code will encounter in 2026. The good news: most of the changes are either backwards-compatible or lower-level protocol restructuring that does not break existing contracts. The work is in updating assumptions, not rewriting code.

If you are ready to build or deploy on Ethereum and its L2 ecosystem, thirdweb offers developer plans that scale with your project — from testnet experimentation to mainnet production. Every Glamsterdam-compatible chain is fully supported.

The Bottom Line

Glamsterdam is Ethereum's most structurally ambitious upgrade since the Merge. ePBS removes trust assumptions from block building. BALs unlock parallel execution. State cost rebalancing makes a 200M gas limit sustainable. And half a dozen developer-facing EIPs make building on Ethereum simpler and cheaper.

The Sepolia testnet fork on August 3 is the first real checkpoint. If you build on Ethereum, that is when your testing should begin.