Ethereum’s Glamsterdam upgrade: what changes for infrastructure

Ethereum names its upgrades with a system. Consensus layer forks take star names in alphabetical order: Altair, Bellatrix, Capella, Deneb, Electra, Fulu. Execution layer forks take the names of cities that hosted Devcon or Devconnect: Berlin, London, Shanghai, Cancun, Prague, Osaka.

Since the Merge, both layers upgrade together, so their names get merged into one. Shanghai plus Capella became Shapella. Prague plus Electra became Pectra. Fulu plus Osaka became Fusaka, which went live on mainnet on December 3, 2025.

The next star in the sequence is Gloas. The next city is Amsterdam, which hosted Devconnect in 2022. Put them together and you get Glamsterdam: the upgrade Ethereum core developers have called the largest protocol change since the Merge, targeted for the second half of 2026.

This post covers what Glamsterdam changes, why it matters, and what you should do about it if you run apps, indexers, or validators on Ethereum.

Where Glamsterdam sits on the roadmap

Fusaka focused on data. Its headline feature, PeerDAS, lets nodes verify blob data by sampling small pieces of it rather than downloading everything, which opened the door to raising blob capacity for Layer 2 rollups. Fusaka also raised the default block gas limit to 60 million. We covered that upgrade in detail in our Fusaka breakdown.

Glamsterdam turns to the base layer itself. Its two goals: change how blocks are built, and change how blocks are executed. Every upgrade since Pectra has followed a “headliner” process where core developers pick one or two high-impact EIPs to anchor the fork, then evaluate everything else around them. Glamsterdam’s two headliners are locked in:

• EIP-7732: Enshrined Proposer-Builder Separation (ePBS) on the consensus layer
• EIP-7928: Block-Level Access Lists (BALs) on the execution layer

The remaining EIPs are a mix of gas repricings and quality-of-life changes. The full candidate list lives in the EIP-7773 meta thread on Ethereum Magicians, and Forkcast tracks the live inclusion status of each proposal.

Headliner 1: ePBS moves block building into the protocol

To understand ePBS, you need to know how an Ethereum block gets made today.

In theory, the validator selected to propose a block builds it too. In practice, most proposers outsource that work. Specialized builders compete to assemble the most profitable block possible — profit that comes largely from MEV, the extra value extracted by choosing which transactions to include and in what order. The proposer simply sells the right to publish its block to the highest bidder.

But there’s a trust problem on both sides: the builder won’t reveal its block early, because the proposer could steal the profitable transaction ordering inside it, and the proposer won’t commit to a block without a guarantee of getting paid. A middleman called a relay solves this — most commonly through software called MEV-Boost. The relay holds the builder’s block, shows the proposer only the bid amount, and has the proposer sign a commitment to a block it has never seen. Only then does the relay release the block’s actual contents and pass the payment along.

This system works, but it depends on off-protocol middleware and a small set of trusted relays sitting at the center of block production. If a relay fails or misbehaves, the protocol has no way to enforce the deal.

EIP-7732 writes the proposer-builder split into consensus rules. The proposer selects a consensus block that commits to a builder’s bid. The builder then reveals the execution payload later in the slot, and the protocol itself guarantees the payment. A new committee of validators, the Payload Timeliness Committee (PTC), attests to whether the builder revealed the payload on time. Relays become optional rather than load-bearing.

So far this sounds like a trust fix, not a scaling fix. Why does it matter for throughput? The scaling win comes from the schedule change. Splitting consensus from execution lets validators attest to each part on separate deadlines within the 12-second slot. According to ethereum.org, this expands the data propagation window from 2 seconds to roughly 9 seconds. That extra time is what allows bigger blocks and more blobs to travel across the network without validators falling behind, and it gives future ZK-proving workflows more room to operate inside a slot.

For the full mechanism, including the fork-choice changes and builder payment flow, the EIP-7732 specification is the reference.

Headliner 2: Block-Level Access Lists enable parallel execution

Ethereum executes transactions one at a time. The reason is simple: a node can’t know which accounts and storage slots a transaction will touch until it runs it. Two transactions might conflict, so clients play it safe and process everything sequentially. That single-threaded pipeline is a core bottleneck limiting L1 throughput.

EIP-7928 addresses this directly. Every block gets a Block-Level Access List: a record of every account and storage slot the block’s transactions touch, along with the resulting state values. Crucially, the BAL isn’t organized by transaction — it’s organized by address, with each account appearing exactly once, and every transaction that touched it referenced inside.

That map changes what clients can do:

• Parallel disk reads and validation. A node knows upfront which transactions are independent, so it can execute non-overlapping ones at the same time and pre-load all required state in one pass. This cuts worst-case block validation time.
• Executionless sync. Because BALs include post-execution state values, a syncing node can update its records from those results without replaying every transaction. Syncing gets much faster.

BALs matter beyond their direct effect. BALs are what make raising the gas limit further technically safe. Today, transactions execute sequentially, so worst-case validation time scales roughly linearly with the gas limit, and every node must finish validating a block within its 12-second slot. Push the gas limit up without changing how validation works, and slower nodes risk missing that window, forcing them out of sync or off the network entirely.

BALs change the constraint: by letting nodes parallelize execution across non-overlapping transactions and skip re-execution during sync, they cut the time needed to process a given amount of gas. That headroom is what makes a higher limit sustainable. The limit sits at 60 million gas after Fusaka. Once BALs are live, 200 million becomes a realistic target, though no such increase is part of Glamsterdam itself. Gas limit changes on Ethereum happen through validator signaling, and they only happen safely when nodes can keep up.

The EIP-7928 specification lays out the exact data structure, if you want to go deeper.

The gas repricing bundle

Beyond the headliners, Glamsterdam carries a set of repricing EIPs, organized under the meta proposal EIP-8007, that adjust gas costs to match what operations actually cost the network. Two changes stand out.

Resource-based intrinsic transaction gas (EIP-2780). Every Ethereum transaction has paid a flat 21,000 gas base cost since genesis, regardless of what it does. EIP-2780 breaks that flat fee into measured components — a base transaction cost, recipient account access, the value write, and the new EIP-7708 transfer log — so each transaction pays for what it actually uses. Under the current draft, a plain ETH transfer to an existing account still totals 21,000 gas, but transactions that do less pay less: a zero-value transaction drops to 15,000 gas and a self-transfer to 12,000. Note that this EIP is still a draft and its numbers have already been revised several times (earlier versions cut a simple transfer to as little as 6,000 gas), so treat any specific figure as provisional and check the official specification at https://eips.ethereum.org/EIPS/eip-2780 for the current values.

More expensive state creation

Permanent storage is the resource Ethereum nodes can least afford to give away, and current pricing undercharges for it. These proposals raise the cost of creating new states so the network’s database grows at a sustainable rate. (EIP-8037 and related proposals).

The direction of the whole bundle: computation gets cheaper, permanent state gets more expensive. If your contracts are storage-heavy, re-benchmark your gas assumptions on a testnet before mainnet activation.

Smaller changes worth knowing about

Two more proposals in the Glamsterdam scope deserve attention from anyone building on Ethereum:

EIP-7708: ETH transfers emit logs. Today, native ETH movements produce no events. A plain transfer, or ETH moved inside a contract call, leaves nothing for eth_getLogs to find, which is why wallets, exchanges, and indexers reconstruct ETH flows by tracing every transaction. EIP-7708 makes value-transferring operations emit a log in the same shape as an ERC-20 Transfer event. Once it’s live, tracking ETH becomes a standard log query.

EIP-7954: bigger contracts. The maximum contract code size, capped at 24 KiB (24,576 bytes) since 2016, would rise to 64 KiB (65,536 bytes), and the initcode limit would rise from 48 KiB to 128 KiB, giving developers more room before they have to split logic across multiple contracts.

Two ideas you may have heard about did not make this fork. Fork-Choice Inclusion Lists (FOCIL, EIP-7805), a censorship-resistance mechanism, was considered but kept out of the headliner set to contain scope. A proposal to shorten slot times to 6 seconds (EIP-7782) was declined for Glamsterdam. Both remain candidates for future upgrades.

Timeline: where things stand

As of mid-2026, Glamsterdam is in the “devnet” phase: Small test networks where client teams hammer the new rules with edge cases to see what breaks. A new round of testing, devnet-6, is coming next. EtherWorld’s State of Upgrade series tracks this work in detail.

From here, the process is: keep testing on devnets, then move to public testnets, then finally set a mainnet launch date. Developers are aiming for the second half of 2026, but nothing is locked in yet — the plan can still change.

One thing is certain: testnets always launch before mainnet. If you’re building on Ethereum, that gap is your window to catch problems while they’re still cheap to fix.

What Glamsterdam means for you

• If you hold ETH: nothing. Your balance, your addresses, and your keys are unaffected. There is no token migration of any kind, and anyone who tells you to “upgrade your ETH” for Glamsterdam is running a scam.
• If you run validators or nodes: client updates, on a deadline. Glamsterdam changes both layers, so execution clients (Geth, Nethermind, Besu, Erigon, Reth) and consensus clients (Lighthouse, Prysm, Teku, Nimbus, Lodestar, Grandine) all ship mandatory releases.

Fork weeks are when self-managed infrastructure hurts most. Fusaka’s own activation is the recent example: the execution layer went smoothly, but a Prysm resource-exhaustion bug caused 248 missed blocks across 42 epochs, dropped network participation to 75%, and cost validators roughly 382 ETH in lost rewards. We looked at that incident in our comparison of Ethereum node clients. Glamsterdam touches far deeper consensus code than Fusaka did.

This is the main reason to run on managed infrastructure through a fork like this one. Chainstack handles client updates, monitoring, and recovery across 70+ chains, so a fork means zero maintenance work on your side. Global Nodes route your requests across geo-balanced instances, which also means a single misbehaving client version in one region doesn’t take your app down. If you need a specific client, region, or configuration, Dedicated Nodes give you an exclusive machine with full archive and debug and trace access.

If you build apps or indexers: two concrete work items.

First, EIP-7708. If your product tracks ETH balances or transfers today, you’re probably calling trace methods like debug_traceTransaction to catch internal transfers. Chainstack exposes debug and trace APIs on archive nodes for exactly this workload, and that keeps working. But once transfer logs go live, you can move that pipeline to plain eth_getLogs queries, which are cheaper and simpler. Plan the migration; keep tracing for pre-Glamsterdam history.

Second, gas assumptions. EIP-2780 restructures how the cost of a transaction is calculated, and the state repricing EIPs change deployment and storage costs. Hardcoded gas values in contracts, relayers, and wallets need a review. The way to do this properly is to run your test suite against a Glamsterdam testnet as soon as one is live. You can deploy Sepolia and Hoodi testnet nodes on Chainstack in a couple of minutes and fund your test accounts from the free Sepolia and Hoodi faucets.

If you’re planning for scale: the combination of BALs and the wider ePBS propagation window points at a higher-throughput L1 in 2027 and beyond. More throughput means more blocks, more state, and more RPC volume for anyone indexing the chain. If your workload is heading that direction, flat-fee options like Chainstack’s Unlimited Node, with no per-request billing, make cost planning simpler than metered pricing as volume grows.

Closing thoughts

Glamsterdam is a builder-and-operator upgrade. Users won’t see a new feature the day it activates. What changes is the machinery underneath: block production moves into the protocol, execution gains a dependency map that permits parallelism, and gas prices shift toward the true cost of each resource. Those three changes are what allow the gas limit, blob counts, and L1 throughput to keep climbing after 2026 without pricing out node operators.

The practical takeaway fits in three lines. Watch Forkcast for scope and dates. Test your gas assumptions and ETH-tracking logic on the testnets as soon as they fork. And make sure whoever runs your nodes, whether that’s you or Chainstack, has a clear plan for fork week.

If you’d rather spend that week building instead of babysitting clients, spin up an Ethereum node on Chainstack and let the upgrade happen underneath you.

FAQ

Additional resources

• Build better with Ethereum
• Ethereum Fusaka: infra upgrade for real scaling
• How to get an Ethereum RPC endpoint (2026 guide)
• Best Ethereum RPC providers in 2026
• How to deploy a self-hosted Ethereum node with Chainstack
• Ethereum RPC for forensics and compliance analytics: best providers 2026