Gloas for the consensus layer; Amsterdam for the execution layer. Put them together and you get Glamsterdam, Ethereum’s next major upgrade, which has just passed its first primetime test on a public testnet.
Glamsterdam officially went live on the Sepolia testnet, with the chain successfully finalizing blocks through the cutover without experiencing any critical hiccups. While this milestone represents testnet activity for the time being, the implications are considerable for the original smart contract network, pointing toward a monumental shift in how the blockchain handles scale and throughput.
Ethereum Foundation researcher Toni Wahrstätter echoed the significance of the deployment, describing Glamsterdam as the opening for Ethereum’s "biggest throughput increase since launch."
When examining the underlying metrics, Glamsterdam is architected to support a target gas limit of roughly 200 million, representing a roughly 3.3-fold increase from the 60 million gas limit seen on networks today. For historical perspective, the Ethereum mainnet sat at a 30 million gas limit for years before validators raised it to 60 million across three separate bumps. Even the London upgrade back in 2021, which famously doubled the maximum block size, kept the ultimate target at 15 million.
Despite the expansive capacity, the network fork will not instantly flip a switch to make Ethereum three times larger overnight. Instead, the upgrade fundamentally alters how blocks are constructed so that producing much larger blocks remains safe and efficient. Following the deployment, validators will ultimately hold the responsibility of deciding when and how to raise the limit on mainnet.
To understand the scope of the upgrade, it is necessary to examine what specifically is changing for Ethereum under Glamsterdam and what work remains before the code can safely reach the mainnet.
Glamsterdam’s Big Ideas
The upcoming network fork bundles 18 Ethereum Improvement Proposals (EIPs) in total, but three specific proposals are set to do the heavy lifting for the execution and consensus layers.
The first major pillar is enshrined proposer-builder separation, commonly referred to as ePBS. To simplify the mechanism, this protocol update is designed to grant Ethereum validators significantly more time to process network data.
Most Ethereum blocks today are built by specialized network participants known as builders and are subsequently passed to validators through trusted intermediaries called relays. Under EIP-7732, the proposer instead commits to a builder’s signed bid up front, and the builder reveals the full block data afterward.

This structural change means that the act of checking a block’s transactions no longer needs to be crammed into the tight roughly four-second attestation window. Per the specifications of the EIP, most validators will henceforth be granted approximately nine seconds instead, easing the computational rush and improving overall network stability.
The next significant pillar introduced in Glamsterdam is block-level access lists, or BALs. In short, these lists offer a new capability for parallel processing across client software.
For historical context, Ethereum clients have traditionally processed a block’s transactions sequentially, one by one, because they could not know ahead of time what state data each transaction would touch. EIP-7928 addresses this limitation by ensuring that every block ships with a comprehensive map of all the state it touches, alongside the resulting values after execution.
Armed with this pre-calculated guide, clients can efficiently prefetch required data and validate transactions in parallel. Using a manufacturing factory metaphor, ePBS is akin to giving quality control more time for thorough inspections, while BALs provide the production floor with everything it needs so that several assembly lines can run simultaneously without bottlenecks.
Additionally, Glamsterdam introduces larger smart contracts alongside important economic repricing. EIP-7954 is set to raise the maximum contract size from 24 KiB to 64 KiB, easing a restrictive cap that has historically forced large, complex decentralized applications to split their code across multiple disparate contracts.
Concurrently, the fork will increase the cost of resources meant to be strictly scarce—namely, new network state. Under EIP-8037, creating a fresh storage slot jumps significantly from 20,000 to 97,920 gas, while a plain Ether transfer to an existing account remains steady at 21,000 gas under EIP-2780.
Checking on Sepolia and the Road to Mainnet
Sepolia’s first Glamsterdam block landed with a 60 million gas limit, matching the operational cap that the Ethereum mainnet runs today. From there, Sepolia’s limit steadily climbed to the 200 million target approximately 11 hours after the fork concluded and has successfully maintained that mark since.
Because each block’s proposer can only nudge the network gas limit upward by about 0.1 percent per block, if every single proposer had actively raised it on every consecutive block, Sepolia could have reached the 200 million target in roughly four hours. It ultimately took more than twice that long, likely in part because two popular consensus clients, Prysm and Teku, kept their validators operating at the 60 million limit after the fork unless operators explicitly opted into the higher 200 million setting.
Researcher Toni Wahrstätter has since shared early performance figures suggesting that the technical optimizations are already yielding positive results. He found that every client now handles each unit of gas faster than before the fork. For example, a 40 million gas block that previously took the Geth client roughly 115 milliseconds to execute now takes approximately 30 milliseconds.

While this represents less than a single day of data gathered from one node per client, it marks a promising start for the new execution architecture.
Looking toward the road ahead, with Sepolia successfully behind the development team, Ethereum’s Hoodi testnet is next on the schedule for Glamsterdam deployment. October 27th has been tentatively floated for this activation, though that date is not yet set in stone, and the Ethereum mainnet remains targeted for a rollout sometime in the fourth quarter of 2026.
It is worth noting that Glamsterdam was originally penciled in for the first half of 2026, and Sepolia’s own testnet fork slipped from August 3rd to October 6th. As a result, it remains entirely possible that the timeline will experience further adjustments as testing continues.
More Scale, More Potential
As with any major protocol upgrade, the arrival of Glamsterdam will introduce new operational dynamics and technical questions for developers and node operators alike.
For instance, certain Ethereum ecosystem tools will inevitably break if they fail to stay synchronized with the fork’s changes. The Ethereum Foundation has previously warned that wallets, data indexers, and gas estimation utilities that hardcode assumptions around a maximum gas limit must be updated well in advance to prevent user-facing disruptions.
Furthermore, with the economic repricing surrounding expanding state, on-chain activities that generate a high volume of new accounts or complex storage—such as token airdrops, large-scale NFT mints, and fresh wallet creation—will incur higher costs, while everyday peer-to-peer transfers remain unaffected.
Ultimately, these technical intricacies will likely prove to be minor points compared to the broader narrative. The most significant dynamic at work is that the Ethereum layer-one network is about to become substantially roomier, offering positive implications for experimental developments across the ecosystem, ranging from institutional finance experiments to novel decentralized applications.
Glamsterdam should provide sudden surges in network demand with far more room to breathe, preventing everyday users from being priced out during peak usage periods. Ethereum is positioning itself to accommodate more projects, higher user activity, and diverse new use cases as the community prepares for the final stretch toward mainnet deployment.
