The Ethereum roadmap keeps moving. Following the Fusaka upgrade, which shipped PeerDAS and laid the groundwork for expanded blob capacity, the community's attention has shifted to Glamsterdam: a major protocol upgrade targeted for H1 2026 that takes direct aim at L1 scaling, MEV reform, and long-term network sustainability.

Glamsterdam is a portmanteau of "Amsterdam" (the execution layer upgrade, named after a previous Devconnect location) and "Gloas" (the consensus layer upgrade, named after a star). Where Fusaka focused on foundational data availability refinements, Glamsterdam is an L1-first upgrade. It restructures how blocks are built, how transactions are processed, and how the network prices permanent data storage.

Key takeaway: Glamsterdam introduces structural changes to Ethereum's engine, not just incremental patches. For onchain builders, the most important shifts are parallel transaction processing, the enshrinement of proposer-builder separation, and a new multidimensional gas pricing model for state creation.

This post breaks down each major component of the Glamsterdam upgrade: what it changes, why it matters, and what different groups in the ecosystem need to do before mainnet activation.

Key Features and Enhancements

Glamsterdam is a collection of Ethereum Improvement Proposals (EIPs) organised around three goals: scaling the L1, ensuring network sustainability, and improving the experience for users and developers. The official Ethereum roadmap page describes it as designed to "clear the path for the next generation of scaling" by reorganising how the network processes transactions and manages its growing database.

The upgrade centres on three pillars:

• Scale L1 and enable parallel processing through enshrined proposer-builder separation and block-level access lists

• Ensure network sustainability by repricing state creation and state access to reflect real hardware costs

• Improve resilience and developer experience through fairer validator exits, cheaper ETH transfers, and better cross-chain tooling

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

Today, Ethereum validators rely on external software (MEV-Boost) and third-party relays to outsource block building to specialised actors. This off-protocol arrangement creates centralisation risk at the relay level and forces validators to rush through transaction broadcasting in a tight 2-second window.

EIP-7732 formally separates the job of the block proposer (who selects the consensus block) from the block builder (who assembles the execution payload), and enshrines this hand-off directly into the protocol. It also introduces the Payload Timeliness Committee (PTC) and dual-deadline logic, allowing validators to attest to the consensus block and the execution payload separately.

The practical result: the data propagation window expands from 2 seconds to roughly 9 seconds, giving the network significantly more headroom to handle larger payloads and more blobs for Layer 2 networks. Third-party relays are no longer required, though builders and proposers may still use off-protocol middleware for features not yet enshrined in the core protocol.

Block-Level Access Lists (BALs) — EIP-7928

Today's Ethereum processes transactions one by one because the network does not know which accounts a transaction will touch until it has actually run. This sequential constraint is the primary bottleneck limiting L1 throughput.

EIP-7928 introduces Block-Level Access Lists: a pre-declared map stored in each block that details every account and storage slot accessed during execution, along with the final post-execution values. Because the network can see upfront which transactions do not overlap, nodes can perform parallel disk reads and process non-conflicting transactions simultaneously.

BALs also unlock executionless sync: because the final results of transactions are included in the access list, new nodes can copy those values directly rather than replaying every transaction from scratch. This makes it significantly faster and cheaper for new nodes to join the network.

The companion proposal, EIP-8159 (eth/71 Block Access List Exchange), upgrades the peer-to-peer protocol so nodes can actually share these lists over the network. Both proposals are required for all execution layer clients.

Network Sustainability: Repricing State

As Ethereum scales toward a 200M gas limit floor, the cost of creating and reading permanent data on the network needs to reflect the actual burden that data places on node hardware. Two EIPs in Glamsterdam address this directly.

State Creation Gas Cost Increase — EIP-8037

Adding new accounts, tokens, and smart contracts creates permanent data (known as "state") that every node must store indefinitely. Under the current model, fees for creating state are inconsistent and often too low relative to the long-term storage burden they impose. Contract deployment, for instance, is significantly cheaper per byte than creating storage slots, creating an imbalance that could make state growth unsustainable at higher gas limits.

EIP-8037 harmonises these costs by introducing a fixed cost per state byte (CPSB), targeting a predictable state database growth rate of 120 GiB per year. This ensures that standard physical hardware can continue running the network efficiently as capacity increases.

The EIP also introduces a reservoir model that separates accounting for computational work and long-term data storage. Rather than both drawing from the same gas limit, state gas charges draw from a dedicated state_gas_reservoir. This means developers can deploy larger, more complex smart contracts without the sheer size of their data capping out the block gas limit, provided they fund the reservoir for storage costs.

State-Access Gas Cost Update — EIP-8038

As Ethereum's state has grown, reading old data has become heavier for nodes to process. Fees for state-access operations have remained static, meaning some commands are now underpriced relative to the compute work they require. For example, EXTCODESIZE and EXTCODECOPY are underpriced because they each require two separate database reads.

EIP-8038 increases the gas constants for state-access opcodes to align with modern hardware performance and current state size. Beyond sustainability, accurate pricing also strengthens network resilience: artificially cheap data-reading operations can be exploited in denial-of-service attacks that spam the network with thousands of complex read requests in a single block.

Network Resilience: Fairer Validator Mechanics

Two proposals in Glamsterdam address how validators enter and exit the network, closing a loophole introduced by the Pectra upgrade and preventing disruption during mass slashing events.

Exclude Slashed Validators from Proposing — EIP-8045

Under the current protocol, a validator that has been slashed (penalised for misbehaviour) can still be selected to propose future blocks in the lookahead schedule. Because blocks from slashed proposers are automatically rejected as invalid, this causes the network to miss slots. During a mass slashing event, multiple missed slots in sequence can significantly delay network recovery.

EIP-8045 filters slashed validators out of the proposer selection process entirely. Only healthy validators are eligible for future duties, maintaining chain quality during disruptions.

Let Exits Use the Consolidation Queue — EIP-8080

The Pectra upgrade raised the maximum effective balance for validators from 32 ETH to 2,048 ETH. A side effect of this change is that high-balance validators can exit the network faster than smaller validators by routing through the consolidation queue, creating an uneven playing field.

EIP-8080 democratises the consolidation queue by allowing standard exits to use spare capacity when it is available, applying a "3 for 2" exchange rate: for every 2 unused consolidation slots, the network can safely process 3 standard exits. During high-demand periods, this can increase exit speed by up to 2.5x without compromising network security.

User and Developer Experience Improvements

Glamsterdam also bundles several quality-of-life improvements that reduce costs for everyday users, simplify cross-chain development, and make onchain data easier to track.

Reduce Intrinsic Transaction Gas — EIP-2780

Every Ethereum transaction currently carries a flat base gas fee, regardless of how simple or complex it is to process. EIP-2780 reduces that base fee to reflect only the essential work the network actually does for a basic ETH transfer: verifying a digital signature and updating a balance.

The result is that simpler transaction paths become significantly cheaper: a self-transfer costs only 12,000 gas, while a plain ETH transfer to an existing account remains 21,000 gas but is now built from accurately-priced components rather than a single legacy constant. A state-gas surcharge applies to transfers that create brand-new accounts, where the network must write a permanent new record, ensuring lower base fees do not cause unchecked state growth.

Deterministic Factory Predeploy — EIP-7997

Users with smart contract wallets across multiple EVM-compatible chains often end up with a completely different address on each network. This is confusing and can lead to accidental loss of funds.

EIP-7997 solves this by formally requiring a minimal CREATE2 factory at address 0x4e59b44847b379578588920cA78FbF26c0B4956C on every participating EVM-compatible chain. Developers can use this universal factory to deploy their applications and smart contract wallets to the exact same address on every chain, eliminating the need for custom chain-specific code and making cross-chain wallets significantly easier to build and manage.

ETH Transfers and Burns Emit a Log — EIP-7708

Unlike ERC-20 token transfers, regular ETH transfers between smart contracts do not emit a standard log event. This makes them difficult for exchanges, bridges, and wallets to track reliably without custom tracing tools.

EIP-7708 mandates that a standard log event is emitted every time a non-zero amount of ETH is moved or burned. For teams building deposit detection, bridge monitoring, or balance tracking, this removes a long-standing blind spot in Ethereum's event system.

eth/70 Partial Block Receipt Lists — EIP-7975

As block capacity increases, the lists of receipts for transactions in a block are growing large enough to cause sync failures between nodes. EIP-7975 introduces a pagination system for the network's communication protocol, allowing nodes to request block receipt lists in smaller, more manageable chunks. This is now required for all execution layer clients and paves the way for Ethereum to safely increase block capacity in future upgrades.

Key EIPs in the Glamsterdam Upgrade

Here is a summary of the primary EIPs included in or under active consideration for the Glamsterdam upgrade. For the latest status on each, the Glamsterdam upgrade on Forkcast is the most up-to-date tracking resource.

Glamsterdam Upgrade Timeline

Ethereum has moved to a predictable, roughly biannual upgrade schedule. The Protocol Priorities Update for 2026 confirmed Glamsterdam as the next major milestone following Fusaka. Based on current core developer consensus, the upgrade is targeted for H1 2026, though specific activation dates for testnets and mainnet are subject to change based on devnet testing progress.

Key phases to watch:

• Devnet testing (ongoing): Core developers are actively stress-testing proposals including bals-devnet and epbs-devnet iterations. Different client teams (Geth, Besu, Prysm, and others) must demonstrate interoperability before scope is frozen.

• Scope freeze: The final set of EIPs will be locked in once proposals pass interoperability testing. Features not ready by the freeze may be deferred to a subsequent upgrade (currently referred to as "Hegota").

• Testnet activations: Testnet forks will precede mainnet, announced via the Ethereum Foundation blog and the EthStaker mailing list.

• Mainnet activation (H1 2026): Target window based on current roadmap planning.

Dates are subject to change. The Glamsterdam Forkcast page and the Glamsterdam Meta EIP (EIP-7773) are the most reliable places to track the latest status.

How Glamsterdam Impacts You

The Glamsterdam upgrade is a technical hard fork with real-world implications across every role in the Ethereum ecosystem. Here is what it means for each group:

• For users: No action required. ETH balances and assets are completely unaffected. The most direct benefit is more accurately priced transactions: EIP-2780 decomposes the flat 21,000 base fee into measured components, so simpler transactions pay less while state-creating ones are priced correctly. Longer term, the parallel processing groundwork laid by BALs should contribute to lower per-transaction costs as the network's gas limit increases safely.

• For developers and L2 teams: Review your gas usage. EIP-8037 and EIP-8038 change the cost of state creation and state-access operations, which will affect contract deployment costs and applications that rely heavily on reading or writing storage. EIP-7708 is a significant quality-of-life improvement: if your app currently uses custom tracing to detect ETH deposits, you can switch to standard log monitoring. EIP-7997 simplifies cross-chain deployments by providing a universal factory for deterministic addresses across all participating EVM chains.

• For node operators: The primary action required is updating client software to a Glamsterdam-compatible version before mainnet activation. Because ePBS introduces new ways blocks are built, validated, and attested to, both execution clients and consensus clients will require updates. Staking pools will need architectural updates to enable trustless monitoring under the new builder selection process. Follow the Ethereum Foundation blog and your client team's GitHub and Discord for release announcements.

• For stakers: Update your clients to the latest versions marked with Glamsterdam support. Validate your setup on testnets before mainnet activation. The overall staking user experience improves under ePBS, with a refined builder selection process and no requirement to run external relay software for standard operations.

Scam warning: No action is required to "upgrade" your ETH. Anyone instructing you to move or convert your ETH for the Glamsterdam upgrade is attempting to scam you. Your assets will be completely unaffected by the hard fork.

What's Next for Ethereum

Glamsterdam is one step in a longer roadmap. Following Glamsterdam, Ethereum core developers have discussed a subsequent upgrade tentatively referred to as "Hegota," which may include proposals deferred from Glamsterdam's scope freeze, such as Fork-choice Enforced Inclusion Lists (FOCIL) for stronger censorship resistance.

The broader direction is clear: Ethereum is building toward a parallelised, high-throughput L1 that keeps home staking viable while scaling to handle significantly more activity. Glamsterdam's combination of ePBS, BALs, and sustainable state pricing creates the structural foundation for the next generation of gas limit increases.

For teams building on Ethereum, the upgrade represents both a preparation task and an opportunity. Contracts that are well-designed around minimal state creation and non-overlapping storage access will benefit most from the parallel execution environment BALs enable. Now is a good time to audit gas usage, review deployment patterns, and test against Glamsterdam devnets before the scope is frozen.

FAQs

What is the Glamsterdam upgrade?

Glamsterdam is an upcoming Ethereum hard fork targeted for H1 2026. It is named from the combination of "Amsterdam" (execution layer upgrade) and "Gloas" (consensus layer upgrade). The upgrade focuses on scaling the L1 through parallel transaction processing, enshrining proposer-builder separation, repricing state creation and access, and improving the experience for users, developers, and node operators.

When is the Glamsterdam upgrade scheduled?

Glamsterdam is targeted for H1 2026. Specific testnet and mainnet activation dates have not yet been finalised. The Glamsterdam Forkcast page and the Ethereum Foundation blog are the best places to track confirmed dates as devnet testing progresses.

Will Glamsterdam lower transaction fees?

It depends on the transaction type. EIP-2780 decomposes the flat 21,000 intrinsic gas cost into resource-based components, so simpler paths (such as self-transfers) pay less, while transactions that create new accounts pay a state-gas surcharge reflecting their long-term storage cost. Longer term, the parallel processing infrastructure introduced by Block-Level Access Lists (EIP-7928) prepares the network for higher gas limits, which should reduce per-transaction costs as capacity grows.

Do I need to do anything with my ETH for the Glamsterdam upgrade?

No. ETH balances and existing smart contracts are completely unaffected by the hard fork. Anyone asking you to "upgrade" or transfer your ETH for Glamsterdam is attempting to scam you.

What does ePBS mean for MEV and block building?

Enshrined Proposer-Builder Separation (EIP-7732) brings the proposer-builder relationship directly into the Ethereum protocol, removing the need for trusted third-party relays like MEV-Boost. This reduces centralisation risk at the relay level, makes builder payments trustless, and expands the block propagation window from 2 seconds to roughly 9 seconds.

What comes after Glamsterdam?

The next planned upgrade is tentatively referred to as "Hegota." It may include proposals deferred from Glamsterdam, such as Fork-choice Enforced Inclusion Lists (FOCIL) for censorship resistance. Specific details are still under discussion by core developers.