Glamsterdam is coming: what Ethereum's next major upgrade could bring

Ethereum continues to move toward a more scalable, efficient network prepared for growing institutional use. After Pectra and Fusaka, the next major focus on the roadmap points to Glamsterdam, an upgrade that brings together relevant changes across both the execution layer and the consensus layer.

Glamsterdam combines two workstreams: Amsterdam, linked to the execution layer, and Gloas, focused on the consensus layer. As with any Ethereum hard fork, its scope can still evolve throughout the discussion, testing, and client coordination process. Even so, the proposals currently on the table already show where the network is heading.

The goal is not only to add new features, but to improve key parts of Ethereum's infrastructure: block production, execution efficiency, state sustainability, client performance, and validator operations.

Glamsterdam comes at an important moment for Ethereum. The network needs to keep increasing its capacity without compromising its core properties: security, decentralization, resilience, and verifiability.

Over the past few years, Ethereum has continued separating responsibilities and optimizing different layers of the protocol. The Merge changed the consensus mechanism; Dencun introduced blobs to improve L2 scalability; Pectra expanded capabilities related to accounts, validators, and user experience; and Fusaka continues that optimization path.

Glamsterdam points to a particularly sensitive area: how blocks are built, how state is accessed, how clients prepare for higher gas limits, and how validator operations improve in more demanding scenarios.

Work on Glamsterdam has already progressed through dedicated devnets and interop events. During the Soldøgn Interop, Ethereum teams worked on testing ePBS with external builders, optimizing Block-Level Access Lists, and defining repricing parameters as a basis for a possible 200M gas limit floor after Glamsterdam. That target still depends on final All Core Devs decisions, but it shows a clear direction: more execution capacity without ignoring client operational limits.

One of the most relevant proposals in Glamsterdam is ePBS, or enshrined Proposer-Builder Separation, described in EIP-7732.

Today, the separation between proposer and builder exists mainly through external infrastructure. With ePBS, Ethereum aims to bring that separation directly into the protocol, reducing external dependencies and making each actor's role in block production more explicit.

In simple terms, ePBS separates two functions more clearly:

• who proposes the block;
• who builds the content of the block.

This can help improve the neutrality, transparency, and robustness of the block-building process. For validator operators, it also means closely following new responsibilities, coordination timings, and possible changes in how slots are managed.

For institutions staking ETH, ePBS is relevant because it affects a critical part of Ethereum: how the block that ultimately enters the chain is produced. It is not a cosmetic improvement, but an evolution of the architecture that supports the network's daily operation.

Another important piece of Glamsterdam is Block-Level Access Lists, defined in EIP-7928.

Block-Level Access Lists describe which accounts and parts of the state will be touched during block execution. This can help clients prepare data access more efficiently, improve execution performance, and open the door to more parallelization.

In practice, this proposal aims to help Ethereum process blocks more efficiently. If the network wants to move toward higher gas limits, clients need better tools to manage state access and reduce bottlenecks.

That is why Block-Level Access Lists should not be seen as an isolated improvement. They are part of a broader set of changes aimed at helping Ethereum scale execution capacity in a more sustainable way.

One of Ethereum's major challenges is state growth. Every new account, contract, or persistent piece of data increases the load that nodes must store and process.

Glamsterdam includes proposals such as EIP-8037, focused on adjusting the costs associated with state creation, and EIP-8038, focused on updating state access costs.

The underlying idea is simple: if certain operations create a heavier permanent load for the network, their cost should better reflect that impact.

These changes are especially relevant for Ethereum's long-term health. A more efficient network is not only one that processes more transactions, but one that can do so without degrading the ability of nodes to stay synchronized, verify state, and participate reliably in the network.

Glamsterdam also includes proposals that directly affect validator operations.

One of them is EIP-8061, which aims to increase exit churn and consolidation churn to improve the protocol's ability to process exits and consolidations. This is especially important for operators and institutions because it connects directly with exit times, operational liquidity management, and the ability to respond to market changes or adverse events.

EIP-8045 is also under discussion. It is oriented toward preventing slashed validators from continuing to be selected to propose blocks in scenarios where their blocks would end up being invalid. The proposal has been narrowed during the Glamsterdam working process, so it should be understood as an evolving resilience improvement, not as a fully final rule.

For validator operators, these proposals matter because they affect very concrete processes: exits, consolidations, proposer selection, risk management, and incident response.

Glamsterdam is still in development, but there are already several areas validator operators should follow closely.

The first is client compatibility. Every hard fork requires coordination between execution client and consensus client teams, and any change to block production or state access can have operational implications.

The second is infrastructure management. If Ethereum moves toward higher gas limits, operators will need to review hardware requirements, node performance, monitoring, latency, and response capacity.

The third is risk management. Changes related to ePBS, churn, or slashing can affect how internal processes, alerts, and operational playbooks are designed.

In institutional staking, these details matter. It is not enough to have active validators; operators need clear procedures, constant monitoring, and the ability to adapt when the protocol changes.

For institutions, funds, custodians, or companies delegating ETH, Glamsterdam is also an opportunity to review the quality of their staking provider.

Some important questions include:

• whether the provider closely follows All Core Devs discussions and the final scope of each hard fork;
• how client updates are prepared before mainnet;
• what testing and monitoring processes are used;
• how risks related to slashing, missed slots, and validator performance are managed;
• what experience the provider has operating infrastructure across evolving networks.

Ethereum is not a static network. Every upgrade requires technical capability, coordination, and operational judgment. For an institution, choosing a staking provider means trusting a team that can adapt to that pace without improvising.

At Stakely, we operate blockchain infrastructure across multiple networks and closely follow upgrades that affect validators, nodes, and institutional staking.

Glamsterdam is relevant because it touches several critical layers of Ethereum: block production, state access, client efficiency, and validator operations. It is not just another technical upgrade, but an evolution that can influence how Ethereum is managed at scale.

For us, following these improvements from early stages is part of operating infrastructure with rigor. Understanding changes before they reach mainnet allows us to prepare clients, adjust internal processes, and better support those who trust Ethereum as a staking network.

Ethereum will keep evolving. And every major upgrade is a reminder of something essential: staking is not just about delegating ETH, but about relying on infrastructure prepared to support the network over the long term.

If you want to stake ETH with a European operator specialized in blockchain infrastructure, you can learn more about our Ethereum staking solution with Stakely.