Ethereum Glamsterdam – What We Know So Far About the Next Hard Fork after Fusaka

Ethereum’s Glamsterdam is the next big hard fork slated for 2026. It will continue Ethereum’s focus on improving Layer-1 scalability and resiliency, indirectly multiplying L2 and ZK rollup benefits.

Ethereum Glamsterdam hard fork: Key takeaways

Ethereum’s next major upgrade after Fusaka is code-named Glamsterdam (Gloas + Amsterdam), which is expected by the first half of 2026.

The Glamsterdam hard fork is now in the early coordination phase, but core Ethereum developers have aligned on the high-level priorities.

Two headliner EIPs confirmed to be included are EIP-7732 (Enshrined Proposer-Builder Separation, or ePBS) and EIP-7928 (Block-level Access Lists).

These two features define Glamsterdam’s core focus: keep Ethereum censorship-resistant and make the network faster.

All other proposals, currently a list of over 25 EIPs, will be evaluated after these headliners are ready.

Some high-impact changes discussed cover realigning gas costs, smoother developer workflows, better interoperability, essential infrastructure for long-term L1 scale, and even post-quantum security.

As GetBlock continues preparing our Ethereum infrastructure for upcoming protocol changes, we’re closely following Glamsterdam. Stay updated with our latest insights.

What is the Glamsterdam Ethereum upgrade?

Glamsterdam is a planned Ethereum hard fork — a synchronized software release that changes how the network operates.

It packs a whole set of changes to the core Ethereum protocol that affect both:

the Consensus Layer (CL) – how blocks are produced and finalized

the Execution Layer (EL) - what transactions do and how nodes process them

After detailed community discussions on concrete changes, client teams test and implement the specs; Ethereum node operators, validators, exchanges, and wallets must update their node software before the activation.

Running a wallet or DeFi application? Ethereum upgrades can interrupt transaction flows if your nodes lag behind. GetBlock keeps RPC endpoints stable with automatic failover and version parity to the mainnet, so your users never see downtime. If you want the same infrastructure reliability for your blockchain product, contact our team.

Ethereum Gloas-Amsterdam hard fork scope

The full scope of Glamsterdam is still taking shape. The upgrade’s headliners – ePBS and BALs – are already set. Together, they target more streamlined block production and network performance.

Source: Forkcast

We gathered a list of major EIPs (Ethereum Improvement Proposals) that can make it into the final set of the Glamsterdam fork.

EIP	Main Focus	Projected Benefits	Current Status
EIP-7928 (BALs)	Block-level read/write lists	Throughput scaling	Headliner; high priority
EIP-7732 (ePBS)	Improve the block production process	Reduce reliance on relays and censorship risk	Headliner; may be staged
EIP-7805 (FOCIL)	Enforced transaction inclusion rules	Stronger inclusion guarantees & censorship resistance	Contender
EIP-8007 (Gas Repricing)	Gas-model reform	Better reflect compute costs	Proposed
EIP-7791 / EIP-7843 / EIP-5920	New opcodes	Better developer experience	Proposed
EIP-2926 / EIP-6873 / EIP-7919	Code merkleization, preimage retention, Pureth	Stateless and Verkle migration prep	Proposed
EIP-7980 / EIP-7932	New signature schemes	Interoperability, security	Proposed

See EIP-7773 for a full list of candidates. The Forkcast website is a convenient place to track the live status of each proposal.

Confirmed “headliner” EIPs for Glamsterdam Ethereum

To keep major upgrades focused, Tim Beiko and the core-dev process leads have proposed a “headliner” framework: choose at most two high-impact EIPs – one for each layer, Execution and Consensus.

The two headliners for Glamsterdam are now locked in. ePBS (EIP-7732) on consensus and BALs (EIP-7928) on execution.

EIP-7732 – ePBS (enshrined Proposer-Builder Separation)

ePBS splits the consensus block from the execution block, where a proposer and builder each handle their part instead of trusting centralized relays. Instead, they can interact directly since builders who were off-protocol become first-class protocol participants.

Ethereum devs agree this is a high-priority change to decentralize block building, make MEV flows transparent, and transactions less censorable.

The update also enables asynchronous workflows where payloads and consensus info can be processed on different schedules. Each part can be tuned separately for 100% efficiency. Ethereum users will feel the changes indirectly via better throughput and consequently lower fees.

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

BALs make a block declare its read/write footprint up front (accounts and storage slots), so clients can validate blocks much faster.

In practice, BALs reduce gas costs for applications that touch the same accounts repeatedly (e.g. DeFi protocols) and can make some gas behaviour more predictable.

The feature may also be an important stepping stone toward more aggressive parallelization and zk-style design.

Other major proposals under consideration

Beyond the headliners, many other EIPs are being shaped for Glamsterdam. These signal that developers are exploring dozens of tweaks to fine-tune Ethereum’s performance and security.

Proposals reviewed below remain in “Proposed” or “Considered For Inclusion (CFI’d)” status.

FOCIL (EIP-7805) – Fork-choice Enforced Inclusion Lists

Adds rules that force builders to include specific transactions in a block, making it harder to censor or exclude them.

FOCIL complements ePBS by constraining builder behavior and has strong community backing for boosting censorship resistance.

Gas pricing reforms (meta EIP-8007)

Core devs are grouping a set of gas-repricing EIPs that aim to align gas with real node and compute costs. Proposals include:

Lower base tx cost (EIP-2780) – Lowers the fixed intrinsic gas per transaction.

Higher storage costs (EIP-8037 / EIP-8032 / EIP-8038) – Raise the cost of creating and keeping on-chain state.

Opcode repricing (EIP-7904 and others) – Expensive compute, like hashing and precompiles, will cost more to reflect real work.

Calldata / access-list floor (EIP-7981 and calldata floor proposals) – Per-byte and access-list floors to prevent block stuffing.

Block gas accounting fixes (EIP-7778) – Eliminate refund tricks that let blocks appear to carry more work than they should.

The goal is to discourage wasteful state growth, make simple transfers cheaper, and keep persistent storage and heavy computation more expensive.

New opcodes and EVM tweaks

Glamsterdam may introduce new EVM instructions. Proposals under review suggest including:

GAS2ETH opcode to create a native on-chain way to share or redirect fees (EIP-7791);

PAY as a safer ETH transfer opcode (EIP-5920);

SLOTNUM to read the current slot instead of relying on timestamps (EIP-7843);

CALLF/RETURNF structured call opcodes for cleaner, more efficient function-call semantics inside EVM bytecode.

Other suggested changes include raising (EIP-7907) or removing contract size limits (EIP-7903) and adding a setdelegate instruction (EIP-7819).

Future-proofing

Some proposals offer to lay the groundwork for stateless Ethereum:

EIP-2926 (code merkleization) restructures contract code into Merkle chunks to help stateless clients.

EIP-6873 (preimage retention) is about temporarily storing Merkle-Patricia preimages in state, prepping for a Verkle tree upgrade.

EIP-7919 (Pureth) adds cryptographic proofs for RPC responses, so light clients and dApps can reliably verify data from nodes.

Others propose the framework and implementations for alternative signature algorithms on Ethereum. EIP-7980 adds Ed25519, widely used in other ecosystems, for better interoperability. EIP-7932 suggests an upgrade path to quantum-resistant schemes.

Declined EIPs

Six-Second Slots (EIP-7782) was shelved from Glamsterdam. This proposal would shorten Ethereum’s 12-second slot time. It was discussed as a prominent candidate but ultimately declined, given its complexity and concerns that it would increase the load on ETH nodes.

However, the idea of shorter slots has not been abandoned and may be revisited in future upgrades, as reducing finality is still important for Ethereum.

When to expect Galmsterdam: Activation date and timeline

Exact dates for the Glamsterdam hard fork haven't been set. The upgrade is expected to follow the successful activation of Fusaka in December 2025. With that, the most likely window is the first half of 2026. The timing, however, depends on testnet rehearsals.

Ethereum roadmap after Pectra and Fusaka to Glamsterdam in 2026

Where the Gloas-Amsterdam upgrade stands now:

As of late 2025, client teams are integrating headliner changes into test builds.

The formal submission window for Glamsterdam EIPs closes one week after Fusaka’s date is locked.

As the headliners move through testing, client teams and core devs will create a shortlist of EIPs to test before confirming the final bundle.

Glamsterdam will be rolled out to Ethereum in stages: internal devnets, public testnets, and mainnet activation only after successful testing.

Wrapping up: Why Glamsterdam matters

The Ethereum Foundation’s 2025–26 roadmap builds on three key things: make Ethereum’s base layer faster, keep improving blob capacity for L2s, and improve user and developer experience.

After years of L2-focused work with Dencun, Pectra, and Fusaka, the ecosystem now seems to be focusing on an L1-first hard fork with Glamsterdam. Repeated emphasis on “cannot compromise on security” is still the highest priority. It makes Ethereum stronger today and bolder scaling moves possible tomorrow.

Ethereum’s protocol will keep changing with every new upgrade, but the infrastructure that apps, users, and developers depend on must remain stable and predictable. GetBlock is committed to remaining that stable, engineer-first infrastructure partner for L1 and L2 development. Discover what that looks like for your stack or reach out to our team to see how GetBlock infrastructure can support your product.