What I’m watching in Ethereum’s Glamsterdam upgrade

Research checked on 7 September 2026. Glamsterdam is still in testing.

An Ethereum upgrade can change whether a transaction succeeds without changing the contract’s code.

In August, the Ethereum Foundation reported that replaying historical transactions under the proposed gas schedule exposed compatibility problems in a small set of contracts. Most contracts were unaffected, and many failures could be addressed by raising the transaction’s gas limit. Others still failed when the limit was raised. The Foundation’s findings are worth reading if you build on Ethereum.

I work in blockchain security, so that detail caught my attention. I want Ethereum to handle more activity. I also want to understand what changes underneath the applications people already use.

Where Glamsterdam stands

Glamsterdam is Ethereum’s next major upgrade after Fusaka. Its name combines Gloas, the consensus-layer upgrade, with Amsterdam, the execution-layer upgrade. The Ethereum roadmap currently points to Q4 2026, without a confirmed mainnet date.

The testnet schedule has been moving too. On the September 3 consensus call, developers settled on October 6 as the Sepolia target, subject to testing and further coordination. That is later than the September 28 date still displayed on the roadmap page. I would follow the latest developer discussion before making plans around a date.

The upgrade’s meta EIP is the place to check its scheduled contents. The two headliners are enshrined proposer-builder separation, or ePBS, and block-level access lists, or BALs. Gas repricing connects those capacity improvements to the cost of running the network.

A simplified view of the changes discussed below. Each still depends on correct implementation and validation by clients.

More time to do the work of a block

Building a block and proposing it are different jobs. A builder assembles the transactions; a proposer puts the block forward to the network. Ethereum already has a market around this separation, with trusted relays helping builders and proposers exchange block data and payments.

EIP-7732 brings that exchange into the protocol. A builder commits to an execution payload and a payment, and reveals the payload later. Consensus validation and execution validation are separated in time, giving the network more room to process the block’s data.

That last part matters for scaling. A larger block is only useful if the network can receive and validate it in time.

What interests me is how the responsibilities change. Moving the exchange into Ethereum’s rules reduces reliance on trusted middleware for that hand-off. It also gives client teams new timing, payment, and fork-choice behaviour to implement correctly. The work shifts into the protocol and its implementations.

Knowing which data a block will touch

BALs tackle another constraint: getting the right state data ready for execution.

An Ethereum client needs account information and contract storage to process transactions. EIP-7928 makes the block’s accesses explicit, recording the accounts and storage locations it touches, together with changes after transactions.

With that information available, clients can fetch data in advance and do more validation work in parallel. They can also parallelize parts of state-root computation. The block’s transaction order and the correctness of the supplied list still have to be respected and verified.

The gas changes deserve a close look

A new storage slot can remain part of Ethereum’s state long after the transaction that created it. Faster execution does not remove the cost of storing and accessing that data.

EIP-8037 changes the pricing of state creation and meters it separately. EIP-8038 updates state-access and write costs to better reflect the work clients perform. Some operations become more expensive as part of making higher overall capacity sustainable.

This is where a broad promise of “cheaper transactions” becomes unhelpful. Gas measures protocol work; the fee someone pays also depends on network demand and fee-market conditions. More capacity and a new gas schedule can affect different transactions differently.

There is a useful example in the Foundation’s Platåberget testnet announcement. Under the schedule it describes, a plain ETH transfer to an existing account with no code still totals 21,000 gas. A transfer that creates an account adds a state-gas charge. Software that assumes 21,000 covers every transfer needs revisiting.

For application teams, I would start with gas estimation, fixed gas budgets, and any transaction-building code that assumes the old accounting model. The Foundation has published a repricing impact tool, and its August report explains how to interpret the results. A successful test under today’s rules does not tell you how the same flow behaves under the proposed ones.

What the development work looks like

There is concrete progress to follow on GitHub. The consensus specifications reached v1.7.0-beta.0 on September 3. That is a specification prerelease, not a production client release or a mainnet launch announcement.

The same week’s core developer call was still working through client interoperability and fork-transition issues, with another development network planned. These are the details I would watch when judging readiness.

The community discussions also help explain why an upgrade takes this much coordination. During feature selection in July 2025, the Base team highlighted the execution benefits BALs could bring to both L1 and L2 systems. In the same discussion, Lido contributor fiddy emphasized the cost of adapting staking infrastructure, especially when specifications change late. Those were contributor views, not a Lido DAO-wide position.

I read those comments as different views of the same engineering problem. More capacity is attractive. Someone also has to update the software, operate the nodes, and carry the transition through.

Glamsterdam gives those teams plenty to prepare for. The public Platåberget network is there for application and infrastructure testing ahead of the longer-lived testnets. For anyone maintaining an Ethereum app, I would use that opportunity to run its ordinary flows—transfers, deployments, calls—and check the assumptions those flows depend on.