Glamsterdam Explained: Every EIP in Ethereum's Next Upgrade

Glamsterdam is the next Ethereum hard fork after Fusaka, and it is shaping up as the most structural release the network has shipped in years. It moves the block-building auction into the protocol itself, puts a consensus-verified state diff inside every block, and reprices the corners of the EVM that stood in the way of much higher gas limits. Multi-client devnets have been running the full slate since June 2026, and mainnet activation is targeted for the second half of the year.

This page is the hub for the whole fork: what Glamsterdam is, where every EIP stands, and where to go deeper on the changes that matter most. Fork scope only becomes truly final when client teams cut testnet releases, so we will keep this page updated as the list firms up. Everything below is checked against the fork’s Meta EIP, EIP-7773, as of July 22, 2026.

What Glamsterdam is and where it sits

The name follows Ethereum’s fork-naming tradition. Consensus-layer upgrades are named after stars and execution-layer upgrades after Devcon cities, and since the two layers began forking together the names have merged into portmanteaus: Shanghai plus Capella became Shapella, Prague plus Electra became Pectra, Fulu plus Osaka became Fusaka, and Gloas plus Amsterdam becomes Glamsterdam.

Fusaka, which activated on mainnet on December 3, 2025, was a data-availability fork. Its headliner, PeerDAS, let validators sample blob data instead of downloading all of it, which opened the door to much higher blob throughput for rollups. Glamsterdam turns the attention back to layer 1 itself: how blocks get built, how fast the EVM can execute them, and how much gas a block can safely carry. The ethereum.org roadmap page files it under scaling the L1, and the devnets are testing gas limit configurations reaching toward 200 million, more than triple today’s mainnet limit.

Glamsterdam is also one station on a much longer line. The protocol’s multi-year direction, with lean consensus, post-quantum signatures, and a slimmer state model, is a story of its own; we cover it in our lean Ethereum roadmap explainer. This post stays on the fork that is actually next.

The timeline

Devnets have been running the complete Glamsterdam feature set since June 2026, and as of this writing the fork is in its final devnet phase. The next step is the public testnets, Holesky and Hoodi, which is where slot timings, gas schedules, and the remaining parameters get their last tuning under realistic conditions. Mainnet comes after the testnet forks hold stable.

No dates are locked. The Meta EIP still lists every activation epoch as undecided, and client teams have consistently framed the second half of 2026 as the target rather than a promise. Coverage that quotes a specific week is guessing. When a mainnet epoch is announced, it will land in the client release notes and on the Ethereum Foundation blog first; until then, you can watch the clock tick on our live Glamsterdam countdown, which we update as the schedule firms up.

The scope at a glance

Ethereum forks are assembled in public, and the vocabulary matters for reading any Glamsterdam news. An EIP is first Proposed for Inclusion, becomes Considered for Inclusion (CFI) once client teams agree it is a serious candidate, and is Scheduled for Inclusion (SFI) when it is committed to the fork and implemented on devnets. Ten EIPs are currently scheduled for Glamsterdam:

The shape of the list tells its own story: one enormous consensus change, one enormous execution change, and eight smaller execution EIPs that mostly exist to make the fork’s throughput ambitions safe.

EIP-7732: the block auction moves into the protocol

Today roughly nine out of ten validators outsource block building through MEV-Boost, a system held together by unpaid, trusted relays that shuttle blind headers between builders and proposers and vouch for payment. EIP-7732, enshrined proposer-builder separation, moves that entire market on-chain. Builders become staked entities in their own beacon chain registry, their signed bids commit to an exact payload hash, and payment is deducted from their on-chain balance the moment a proposer includes the bid, whether or not the payload ever appears. With payment enforced by the protocol, nobody needs a relay to escrow trust.

The consequence that ripples furthest is timing. The beacon block stops carrying the execution payload; the payload is revealed mid-slot and attested by a new Payload Timeliness Committee of 512 validators, while regular attesters vote on the consensus block without executing anything. That stretches the propagation-critical window from about two seconds to about nine, which is what allows blocks to get much bigger, and it compresses the window in which builders assemble blocks on fresh state to roughly four to six seconds. For builders it means posting real capital and learning a new auction; for searchers it means every deadline in the pipeline moves earlier. We take the whole change apart, slot anatomy included, in our ePBS deep dive.

EIP-7928: every block ships its own state diff

The execution headliner is quieter but arguably more practical. Under EIP-7928, every block carries a Block-Level Access List: a complete, consensus-verified record of every address the block touched, every storage slot written with its post-value, every slot read, and every balance, nonce, and code change, each keyed to the transaction that caused it. The block header commits to the list’s hash, and every validating node rebuilds it during execution; a block whose list does not match reality is invalid.

The protocol wants BALs because they remove the information barrier that forces the EVM to run transactions one at a time. With access sets declared and enforced up front, clients can prefetch state, execute non-conflicting transactions in parallel, and split state-root computation across cores, which is the groundwork the 200 million gas ambition rests on. Data consumers should want them for a different reason: a verified state diff in every block replaces a whole category of expensive trace-based re-execution. The change is further along than most people realize; Geth already builds and verifies BALs ahead of the fork. What is in a BAL, what it replaces, and what it deliberately does not do is covered in our Block-Level Access Lists explainer.

The repricing slate that makes 200M gas thinkable

Four of the scheduled EIPs are gas repricings, and they read as a single project: close the gaps that would make a 150 to 200 million gas block dangerous before raising the limit toward those numbers.

EIP-7778 changes how gas counts toward the block limit. Refunds, like the ones earned for clearing storage, still reduce what a transaction pays, but they no longer shrink the transaction’s footprint in the block’s accounting, so a block can no longer pack more real execution work than its limit implies. EIP-7976 raises the floor cost of calldata, continuing the work EIP-7623 started in Pectra, which keeps the worst-case size of a data-stuffed block bounded as the limit climbs. EIP-7981 raises the price of EIP-2930 access lists so that declaring state access costs something closer to what it makes every node actually do. And EIP-8037 makes creating new state, fresh accounts and fresh storage, more expensive, because state growth that is manageable at 60 million gas per block becomes a flood at three times that.

None of these are exciting on their own, and that is the point. The gas limit itself is not set by the hard fork; validators vote it block by block. The repricing slate is what makes voting it sharply upward defensible.

Quality-of-life changes for contract developers

The remaining four scheduled EIPs land closer to everyday contract work. EIP-7954 lifts the maximum size of deployed contract code, a cap that has sat at 24 KiB since 2016 and has forced large protocols into awkward proxy-and-library contortions. EIP-8024 adds SWAPN, DUPN, and EXCHANGE, stack instructions that reach deeper than the sixteen slots today’s SWAP and DUP can touch; they were designed for the EOF project, and this EIP salvages them in a backward-compatible form that compilers can use to bury “stack too deep” errors. EIP-7843 adds a SLOTNUM opcode that exposes the current beacon chain slot to the EVM, giving contracts a native clock at slot granularity instead of inferring it from timestamps.

EIP-7708 may be the sleeper of the fork for anyone running data pipelines: every ETH value transfer, including plain sends and transfers made inside contract calls, emits a log. Today native ETH movements are invisible to log-based indexing, and catching internal transfers means tracing entire blocks. After 7708, ETH becomes trackable the way ERC-20 tokens always have been, with a log per transfer, which collapses a lot of tracing infrastructure into a simple subscription; the pipeline pattern is the one described in our Ethereum webhook guide.

Still being decided, and what got cut

Beyond the ten scheduled EIPs, nine more currently sit in the Considered for Inclusion bucket: EIP-2780 (reduce intrinsic transaction gas, which would cut the flat 21,000 gas base cost), EIP-7610 (revert contract creation into non-empty storage), EIP-7688 (forward-compatible consensus data structures), EIP-7997 (a deterministic deployment factory baked into the protocol), EIP-8038 (a state-access repricing companion to 8037), EIP-8045 (exclude slashed validators from proposing), EIP-8061 (increase exit and consolidation churn), EIP-8246 (remove the SELFDESTRUCT burn), and EIP-8282 (builder execution requests, an ePBS-adjacent piece). The honest way to read that list is as a set of maybes: CFI items ride along only if they do not endanger the headliners, and some of them will slip to the next fork. Treat any article that presents them as confirmed with suspicion.

The declined list is longer, 41 EIPs, and two entries explain the fork’s shape. FOCIL, EIP-7805, the fork-choice-enforced inclusion list design, was the other finalist for the consensus-layer headliner slot; the 2025 debate came down to censorship resistance first versus restructuring the block pipeline first, and ePBS won the seat. EOF, EIP-7692, was declined here after being dropped from earlier fork plans as well, with EIP-8024 rescuing its most-wanted opcodes. Neither proposal is dead, but neither is in Glamsterdam, whatever older articles suggest.

What Glamsterdam means for latency-sensitive users

If you run a searcher, a trading bot, or anything else that races the chain, the fork’s changes point in one direction: more data per block, less time per decision. ePBS compresses the window for building on fresh state to a few seconds and makes the mid-slot payload reveal the moment that matters, so every network round-trip in your loop gets more expensive relative to the budget. BALs add tens of kilobytes to every block, and a gas limit heading toward 200 million multiplies both block size and the value of reading it without crossing the internet. The fork rewards code that sits where the data lands.

That is the model BLAZED.sh is built on: your containers and scripts deploy onto hosts running fully synced Ethereum nodes and talk to them over a local socket, with sub-10ms RPC round-trips and an unfiltered view of the mempool from the node your code sits on. Ethereum mainnet is the only chain live on the platform today, and it happens to be exactly the chain Glamsterdam rewires. The window before the fork is the right time to move latency-sensitive workloads next to the node, rehearse on the public testnets when they fork, and let everyone else discover the new timing constraints on mainnet.

FAQ

When does Glamsterdam go live?

Mainnet activation is targeted for the second half of 2026, but no epoch is set; the Meta EIP still lists all activation times as undecided. Devnets have run the full slate since June 2026, and the public testnets Holesky and Hoodi fork next. Our Glamsterdam countdown tracks the current target.

What are the headline changes in Glamsterdam?

EIP-7732, enshrined proposer-builder separation, on the consensus layer, and EIP-7928, Block-Level Access Lists, on the execution layer. The first moves the block-building auction into the protocol; the second puts a consensus-verified state diff in every block and lays the groundwork for parallel execution.

Is the Glamsterdam EIP list final?

The ten Scheduled for Inclusion EIPs are committed and running on devnets, and removing one at this stage would be unusual. The nine Considered for Inclusion EIPs are genuinely undecided, and details of every EIP can still change until the testnet forks settle. This page is updated as the scope moves.

Does Glamsterdam raise the gas limit?

Not directly; the gas limit is voted by validators, not set by forks. But the slate is built to make a much higher limit safe: BALs unlock parallel execution, ePBS extends the propagation window, and the repricing EIPs close the worst-case vectors. Devnets are testing configurations reaching toward 200 million gas.

Conclusion

Glamsterdam is two big ideas and a supporting cast: put the block auction in the protocol, put a state diff in every block, and reprice whatever stands between Ethereum and a much higher gas limit. Ten EIPs are locked, nine are maybes, and the calendar still says H2 2026 without a date. We will keep this page current as testnets fork and the scope hardens; for the deep ends of the two headliners, start with our ePBS deep dive and the Block-Level Access Lists explainer.