# What Is the Ethereum Glamsterdam Upgrade?

The Ethereum Glamsterdam Upgrade is a major planned protocol upgrade (hard fork) targeted for Q3 2026. Following Ethereum's naming convention, "Glamsterdam" is a portmanteau combining Gloas (the consensus layer upgrade, named after a star) and Amsterdam (the execution layer upgrade, named after a host city).

It builds directly on the December 2025 Fusaka upgrade—which introduced PeerDAS for rollup data availability—and shifts focus toward scaling Ethereum's Layer 1 (L1) execution performance and consensus architecture.

## Core Objectives

Glamsterdam focuses on three main goals:

1. Parallelizing Transaction Processing: Moving away from single-threaded, sequential transaction execution to simultaneous, multi-threaded execution.

2. Expanding Block Capacity: Splitting block creation and verification duties to allow larger blocks without straining node bandwidth.

3. Preventing State Bloat: Repricing gas costs for state creation and storage access to align with long-term hardware costs and unlock future gas limit increases safely.

## Key Upgrade Metrics at a Glance

The graph below highlights two fundamental parameters being transformed in the Glamsterdam upgrade: the targeted L1 block gas limit capacity and the block payload propagation time window provided under Enshrined Proposer-Builder Separation (ePBS).

## Key Improvements & EIPs

| EIP | Name | What It Does |

|---|---|---|

| EIP-7732 | Enshrined Proposer-Builder Separation (ePBS) | Integrates proposer-builder separation directly into the core protocol, replacing third-party middleware (like MEV-Boost relays). It extends the block payload propagation window from 2 seconds to ~9 seconds via a Payload Timeliness Committee (PTC), reducing MEV exploitation by up to 70% and removing single-lane bottlenecks. |

| EIP-7928 | Block-Level Access Lists (BALs) | Mandates pre-execution access lists in block headers that declare which state accounts transactions will touch. This allows nodes to execute non-conflicting transactions simultaneously in parallel and enables executionless sync for faster node setup. |

| EIP-8037 & EIP-8038 | State Gas Repricing | Reprices state-creation and storage-access opcodes to reflect real hardware storage costs, curbing database growth (targeting max ~120 GiB/year state bloat). |

| EIP-7708 | Standardized ETH Transfer Logs | Generates standard event logs for every native ETH transfer/burn, eliminating the need for custom transaction-tracing in exchanges, wallets, and bridges. |

| EIP-7997 | Universal CREATE2 Factory | Ensures deterministic smart contract deployment addresses across all EVM-compatible networks. |

## Key Takeaways for Users and Operators

* Throughput & Capacity: L1 block gas limits are targeted to increase from ~60 million up to 200 million gas per block, with throughput targeted toward 10,000 transactions per second (TPS).

* For ETH Holders: No action is required. Balances, tokens, and existing smart contracts remain completely unaffected. Beware of scams claiming you need to "convert" or "upgrade" your tokens.

* For Stakers & Node Operators: Client software for both the Execution Layer (EL) and Consensus Layer (CL) must be updated before mainnet activation to remain in sync with the network.