Glamsterdam Planning Definition

Glamsterdam planning is the phase where Ethereum core teams and the wider community decide which technical changes will ship in the next major hard fork after Fusaka. The work centers on selecting and bundling Ethereum Improvement Proposals (EIPs) for a target mainnet upgrade expected in 2026.

Background and timing

Glamsterdam follows the Fusaka upgrade. As Fusaka moved through devnets and public testnets in the second half of 2025, the discussion shifted to what should come next. Developers used regular AllCoreDevs meetings to start lining up candidates for Glamsterdam while finalizing Fusaka’s scope and testing.

What gets planned

During this phase, contributors review EIPs that touch different parts of the stack. The evaluation focuses on feasibility, security impact, interactions between proposals, and how realistic the delivery timeline looks when all pieces are combined into a single fork. The planning process aims to keep Ethereum secure and decentralized while improving performance and usability.

How decisions are made

Ethereum uses an open process. Engineers debate proposals on calls and in public forums, weigh trade-offs, and gather feedback before anything becomes “in scope.” The end result is a curated set of EIPs that client teams implement and test across devnets and testnets before mainnet activation.

Proposals discussed for Glamsterdam

ePBS as a core direction

One major theme is enshrined in proposer-builder separation (ePBS), tracked as EIP-7732 on the consensus side. In mid-August 2025, meeting summaries highlighted ePBS as a core item to anchor the next phase of roadmap work. An initial implementation window was discussed for early 2026.

Block-level access lists

On the execution layer, Block-Level Access Lists (EIP-7928) surfaced as a candidate to improve how transactions declare resources they’ll touch, which can help clients and builders optimize block construction. This was also called out as a core proposal for Glamsterdam.

Six-second slots, then re-scoping

Early conversations around cutting slot time to six seconds appeared in news coverage, framed as a way to speed up the user experience. Later dev notes indicated that the specific six-second slot item (EIP-7778) was removed due to conflicts with other priorities, keeping the door open to revisit timing only after foundational pieces like ePBS and access lists stabilize.

EIP-7702 “Fossil”

Another idea, informally referred to as “Fossil” under EIP-7702, was flagged for evaluation only after the ePBS and access-list work settles. In other words, it is a follow-on candidate rather than a first-wave change.

Performance levers under review

Outside of specific EIP numbers, two broad levers showed up across reports: cutting block time and revisiting the gas limit. Some community updates noted support building toward a higher gas cap alongside the slot-time discussion, though scope setting for Glamsterdam continues to converge around ePBS and access lists first.

Link to Fusaka

Glamsterdam planning runs in parallel with late-stage Fusaka work. As Fusaka’s schedule shifted and additional devnets were spun up to fix test issues, core developers used the same calls to prepare Glamsterdam’s starting lineup, ensuring the next fork is ready to pick up once Fusaka ships.

Tracking progress

Most decisions surface through AllCoreDevs updates and recaps shared by client leads and community writers. Glossary pages and news posts provide snapshots of which proposals are “in,” which are deferred, and which still need more research or testing before they can make a fork.