Ethereum’s Glamsterdam Upgrade: A Deep Technical Dive into the Future of Ethereum Scalability

Ethereum’s scaling story has always been a balancing act: how do you make the world’s most decentralized smart-contract platform dramatically faster and cheaper, without sacrificing the security and openness that make it valuable in the first place? For years, the answer was simple: push activity onto Layer 2 rollups. In 2026, that answer is evolving.

The December 2025 Fusaka upgrade quietly transformed Ethereum’s data availability layer, laying the groundwork for the network’s next phase of growth. Its successor, Glamsterdam, goes several steps further, re-architecting how blocks are built, propagated, and executed at the protocol level. It is arguably the most consequential change to Ethereum’s execution environment since the network transitioned to proof-of-stake.

For enterprises exploring the future of Ethereum blockchain development services, Glamsterdam represents more than just another hard fork. It signals Ethereum’s broader ambition to scale the base layer itself while preserving decentralization, security, and accessibility for developers and users alike. The upgrade introduces technical innovations that could reshape how decentralized applications are designed, how infrastructure providers operate, and how a blockchain development company approaches building next-generation Web3 solutions.

In this blog, we’ll take a deep technical dive into what Glamsterdam actually is, unpack the protocol mechanics behind its headline features, compare it with the Fusaka upgrade, explore the real-world use cases it unlocks, and examine how a blockchain development company is preparing to help businesses build on Ethereum’s next evolution.

The Last Update: What Fusaka Delivered

To understand Glamsterdam, you first have to understand the upgrade that came before it. Fusaka activated on the Ethereum mainnet on December 3, 2025, marking another important milestone in Ethereum’s long-term scalability roadmap.

At the heart of Fusaka was PeerDAS (Peer Data Availability Sampling), a mechanism designed to address one of Ethereum’s emerging bottlenecks: efficiently handling the growing volume of rollup data. Rollups publish compressed transaction data to Ethereum in the form of blobs, allowing them to inherit Ethereum’s security while executing transactions off-chain. However, validating this growing amount of data was becoming increasingly resource-intensive.

PeerDAS fundamentally changed that process. Instead of requiring every validator to download and verify the entire dataset, validators can now sample small, randomly selected portions of blob data while maintaining strong cryptographic assurances that the complete dataset is available. This significantly reduces the bandwidth burden on individual validators and enables Ethereum to support a much higher volume of rollup data without compromising decentralization.

The impact of Fusaka was substantial. It strengthened Ethereum’s role as the settlement and data availability layer for the broader Layer 2 ecosystem, making rollups more efficient and cost-effective. For businesses leveraging Ethereum blockchain development services, this translated into improved scalability opportunities and lower operational friction for applications built on Ethereum’s expanding ecosystem.

Yet, despite these advancements, Fusaka primarily focused on scaling data availability, not Ethereum’s execution layer itself. It made Ethereum better at supporting rollups, but it did not fundamentally change how Ethereum constructs blocks, processes transactions, or executes smart contracts at the base layer.

That is precisely where Glamsterdam enters the picture.

If Fusaka was about preparing Ethereum’s infrastructure for a rollup-centric future, Glamsterdam is about advancing Ethereum L1 scaling by rethinking the mechanics of block production and execution. In doing so, it could redefine how developers approach Ethereum smart contract development and shape the next generation of Ethereum blockchain development.

What Is Glamsterdam? An Overview

Glamsterdam is Ethereum’s next major hard fork, designed to advance Ethereum L1 scaling by improving how the network builds blocks, processes transactions, and manages long-term growth. Named through Ethereum’s established convention, it combines the consensus-layer name Gloas (a star) and the execution-layer name Amsterdam (a Devconnect host city), as formalized in Meta EIP-7773.

At its core, Glamsterdam focuses on three interconnected objectives: improving execution efficiency, expanding Ethereum’s processing capacity, and ensuring the network remains sustainable as adoption grows. By introducing dependency-aware execution models, refining block production workflows, and revisiting how state growth is priced, the upgrade seeks to remove key bottlenecks without compromising Ethereum’s security or decentralization principles.

Timeline Note: Originally expected in H1 2026, Glamsterdam has moved to H2 2026 as developers continue refining and testing its most ambitious proposals through dedicated devnets. No firm mainnet date is set as of mid-2026.

Unlike Fusaka, which enhanced Ethereum’s data availability capabilities for rollups, Glamsterdam focuses on the protocol’s execution layer and block production mechanisms. According to Ethereum’s roadmap, the upgrade aims to improve processing efficiency, expand network capacity, and support Ethereum’s long-term sustainability.

For organizations investing in Ethereum blockchain development services, Glamsterdam could reshape how scalable decentralized applications are built on Ethereum.

Glamsterdam vs. Fusaka: What’s Changing

The Headline Features Explained

1 Enshrined Proposer-Builder Separation (ePBS) – EIP-7732

Today, Ethereum’s block-building ecosystem largely relies on MEV-Boost, an off-protocol solution that uses external relays to coordinate block construction between validators and specialized builders. While effective, this architecture introduces additional trust assumptions and operational complexity.

Enshrined Proposer-Builder Separation (ePBS), proposed through EIP-7732, aims to bring this functionality directly into Ethereum’s core protocol. Rather than depending on third-party infrastructure, Ethereum would provide native mechanisms for proposer-builder coordination, improving decentralization and strengthening protocol-level guarantees.

Key implications of EIP-7732 include:

• Reduced reliance on external MEV-Boost relays, shifting critical block-building functions into the Ethereum protocol itself.
• Introduction of the Payload Timeliness Committee (PTC) to help ensure payload availability and support the protocol’s timing requirements.
• Dual-deadline attestation logic, designed to improve coordination between block proposal and validator attestations.
• An extended payload dissemination window, increasing from approximately 2 seconds under today’s architecture to roughly 9 seconds under the proposed design, allows more time for block data propagation across the network.
• Trust-minimized builder payments, enabling value transfers between builders and proposers to occur within the protocol rather than through external arrangements.
• Safer block outsourcing for validators, allowing them to benefit from specialized block construction while relying less on off-protocol software and infrastructure.
• Operational adjustments for staking providers and validator operators, who may need to update monitoring systems and validator workflows to align with the new architecture.

By embedding proposer-builder separation directly into Ethereum, ePBS represents a significant step toward making Ethereum’s block production process more robust, scalable, and protocol-native.

2 Block-Level Access Lists (BALs) – EIP-7928

One of Ethereum’s long-standing execution bottlenecks stems from the fact that transaction dependencies are often discovered only during execution. As a result, transactions within a block are generally processed sequentially, limiting opportunities for parallelization.

Block-Level Access Lists (BALs), introduced in EIP-7928, address this limitation by providing an explicit map of the state elements that transactions will access before execution begins. This additional information enables clients to optimize execution workflows and prepare for a more parallel future.

Key implications of EIP-7928 include:

• Predefined transaction dependency maps allow execution clients to identify state access patterns before processing transactions.
• Parallel disk reads, enabling nodes to retrieve required state data for multiple transactions simultaneously instead of sequentially.
• Support for executionless synchronization approaches, where nodes can reconstruct state transitions using BAL-provided post-execution information without replaying every transaction individually.
• A lightweight commitment mechanism, with the block header containing a hash reference to the complete block access list rather than storing the entire dataset directly.
• A foundation for future parallel execution, helping Ethereum scale more efficiently as transaction volumes and gas limits increase.

BALs do not immediately transform Ethereum into a fully parallel execution environment. Instead, they establish the infrastructure necessary for progressively introducing more sophisticated execution optimizations in future upgrades.

3 Block Access List Exchange – EIP-8159 (eth/71)

To support the broader BAL initiative, Ethereum also proposes updates to its peer-to-peer networking layer through EIP-8159, commonly referred to as the eth/71 Block Access List Exchange.

This proposal serves as the networking companion to EIP-7928 by defining how execution clients exchange block access list information efficiently across the network.

Key implications of EIP-8159 include:

• A dedicated peer-to-peer protocol extension for Block-Level Access Lists, ensuring BAL data can be distributed consistently among execution clients.
• Standardized access list propagation, enabling nodes to exchange dependency information required for BAL-enabled processing.
• Improved support for advanced synchronization techniques, including executionless state update strategies built on BAL data.
• Preparation for more efficient execution workflows, complementing Ethereum’s longer-term efforts toward greater parallelization and scalability.
• A critical infrastructure component for BAL adoption, since access list distribution must occur reliably for clients to take advantage of these execution enhancements.

Together, EIP-7928 and EIP-8159 lay the groundwork for a more efficient execution layer, enabling Ethereum to evolve beyond today’s predominantly sequential processing model while preserving the network’s security and decentralization principles.

5. Real-World Use Cases

While Glamsterdam’s proposals are deeply technical, their impact extends far beyond protocol researchers and validator operators. The upgrade has the potential to influence how decentralized applications are designed, deployed, and scaled across the Ethereum ecosystem.

High-Performance DeFi Applications

Decentralized exchanges, lending protocols, and derivatives platforms often experience periods of intense activity. By improving block production efficiency and laying the groundwork for greater execution parallelization, Glamsterdam could help Ethereum support increasingly sophisticated financial applications without compromising security.

Enterprise-Grade Blockchain Solutions

Organizations adopting Ethereum blockchain development services for supply chain management, asset tokenization, identity systems, and business process automation require infrastructure that can evolve with growing demand. Glamsterdam’s focus on Ethereum L1 scaling strengthens the long-term viability of enterprise applications built directly on Ethereum.

Advanced Smart Contract Ecosystems

Applications involving complex state interactions, such as gaming platforms, on-chain social networks, and decentralized marketplaces, can benefit from improved execution efficiency and greater gas predictability. These enhancements could influence how teams approach Ethereum smart contract development, enabling richer user experiences and more scalable application architectures.

Cross-Layer Application Development

As Ethereum continues to operate within a rollup-centric ecosystem, developers increasingly build solutions that span both Layer 1 and Layer 2 environments. Features that simplify deployment consistency and improve the efficiency of the underlying protocol can streamline Ethereum blockchain development across multiple networks.

Infrastructure and Node Services

Blockchain infrastructure providers, validator operators, and analytics platforms depend on efficient synchronization and sustainable node requirements. Glamsterdam’s emphasis on improved state management and more efficient processing can contribute to a healthier and more decentralized network infrastructure.

For businesses exploring Blockchain Development Services, Glamsterdam represents more than a protocol upgrade – it signals Ethereum’s continued evolution into a platform capable of supporting the next generation of decentralized applications at scale.