Glamsterdam Upgrade: Ethereum’s Scaling Plans and Market Impact
Glamsterdam is Ethereum’s next major upgrade. Planned for Q4 2026, it would change block production, support parallel processing, and revise network costs. An X post from the $SSV Network argues that the upgrade could help Ethereum scale and eventually lift ETH’s value. I’m not convinced by the second part. Better plumbing can make Ethereum more useful without moving the token price much at all. It happens.
Ethereum’s official roadmap lists a wider H2 2026 window. The mainnet launch depends on completed specifications, compatible clients, security reviews, and reliable public testnets. Glamsterdam actually combines two upgrades. “Gloas,” named after a star, covers the consensus layer; “Amsterdam,” named after a former Devconnect host city, covers the execution layer. Gloas changes how validators coordinate and agree on the chain. Amsterdam deals with transactions and smart contracts. They ship together, but they solve different problems.
Testing is already underway. In May, the Ethereum Foundation reported successful multi-client devnet tests of the external-builder pipeline across nearly every client. Developers have also settled on a future gas-limit target of 200 million after Glamsterdam. That number needs context. It is a goal—not the current limit, and not a guarantee that the upgrade reaches it immediately. Before naming a mainnet fork date, developers want a stable, complete devnet and compatible client releases. Security reviews must be finished. Public testnets must also prove dependable. Is that overly cautious? Not for a network worth more than $400 billion.
One of Glamsterdam’s largest changes is EIP-7732. It introduces enshrined Proposer-Builder Separation, or ePBS, and moves more of the block-production process into Ethereum’s consensus rules. Most Ethereum proposers currently depend on external builders and trusted relays to assemble execution payloads. Under ePBS, a builder would commit to a payload and payment before the consensus proposer selected a bid. A Payload Timeliness Committee would then verify that the payload appeared on schedule and that the blob data was available.
The design separates consensus checks from execution checks. Most summaries stop there and call it a capacity upgrade. That is only half right. Validators would also inherit work involving builder commitments and payload verification, plus stricter timing demands. Large staking pools may have to revise their monitoring and builder-selection systems, while node operators will need compatible execution and consensus clients. Sounds routine? It won’t feel routine when thousands of operators have to keep it working every day. Good protocol design can still be miserable to operate at scale.
EIP-7928 introduces another substantial change: Block-Level Access Lists, or BALs. These lists record the accounts and storage locations touched by a block, as well as their values after the transactions run. Ethereum currently discovers many dependencies while transactions are executing. That makes parallel processing difficult: clients cannot always know in advance which transactions will touch the same state. BALs expose more of that information beforehand. Clients could identify independent transactions, perform some database reads simultaneously, and parallelize portions of validation and state-root calculation.
My take: BALs are probably the piece throughput-focused investors should watch most closely. They could also support executionless state updates, allowing a syncing node to read recorded results rather than replay every transaction. EIP-8159 would provide the network method for sharing the lists. But let’s not turn that into a promised transaction-speed figure. Performance still depends on the client software and each block’s contents. The gas limit after activation matters too. Could fees fall? Yes. Must they? No. Precise forecasts about the user experience are premature.
Extra capacity comes with a difficult tradeoff: Ethereum’s permanent database, known as its state, could grow far more quickly. EIP-8037 proposes a fixed charge for every new byte of state. Counter to the usual “more capacity is better” pitch, unchecked growth could raise storage costs and make home nodes harder to run. That would weaken decentralization. EIP-8037 therefore targets average state growth of 120 GiB per year at a reference block gas limit of 150 million. The constraint is intentional.
The proposal could make accounts, storage slots, or contract code more expensive to create while permitting larger contract deployments. Separate state metering would prevent state creation and ordinary computation from competing within one transaction gas limit. EIP-8038 remains under consideration and would charge more for reading or changing existing state, reflecting the burden imposed on nodes. If it enters the final upgrade, database-heavy applications could face meaningful cost changes. I’d retest the real workloads. Old gas estimates won’t be enough.
Existing contracts should still work after Glamsterdam, and developers will gain new tools. EIP-7954, for instance, increases the maximum contract size. EIP-7708 standardizes logs for non-zero ETH transfers and burns. Two other proposals remain under discussion: EIP-2780 would reduce the intrinsic gas cost of simple ETH transfers, while EIP-7997 would let developers deploy contracts at the same address across participating EVM networks.
Compatibility does not mean nothing changes. Contracts may keep running even as their costs or fee estimates shift; indexers and tracing tools can change around them as well. Application teams should test each one before activation. Validators and node operators must update both client types, since an old execution or consensus client may stop following the upgraded chain. Ethereum’s official guidance will identify supported releases. I’ll be honest: public testnet results are a much better readiness signal than hopeful dates posted months ahead.
ETH holders do not need to take any action. Their balances will remain accessible, and Ethereum’s roadmap warns that requests to exchange ETH for a replacement token are scams. Skip the token swap. Investors should instead watch the final EIP list and multi-client devnet stability. Security reviews matter. So do public testnet results. Why does the fork date matter? Because a confirmed mainnet date says more about actual progress than an unofficial launch quarter circulating on social media.
Glamsterdam aims to increase capacity without making node hardware impractical. It changes block coordination and lays groundwork for more parallel execution. That matches Ethereum’s current scaling plans, but it promises neither cheaper transactions nor wider adoption. It certainly does not promise a higher ETH price. Yes, that sounds conservative after describing substantial technical gains. Both things can be true. The investment case requires a clean launch followed by measurable improvements; for now, Glamsterdam remains an ambitious protocol project with an unknown effect on ETH.
What this means
Glamsterdam makes Ethereum’s priorities fairly clear: increase capacity without forcing ordinary node operators off the network. ePBS changes block construction. BALs could allow clients to do more work in parallel. If both perform as planned, Ethereum may process heavier traffic more efficiently. Still, validators could end up carrying additional responsibilities. This is not merely a workload-reduction story.
For ETH investors, a successful upgrade would strengthen the case that Ethereum can remain competitive as a smart-contract platform. The network might become more appealing to institutions as well. My take hasn’t changed: that is not a confident price forecast. Better infrastructure does not automatically create more ETH demand, and traders often price upgrades months before users experience the results. With this much technical work scheduled for 2026, I’d give testnet performance more weight than early excitement.
The next milestones are a stable full devnet and compatible releases from the Ethereum Foundation and its client teams. Public testnets will show whether the design survives outside controlled development environments. Finished security reviews carry equal weight. One serious bug—or a delay at either stage—could damage confidence and push back the launch. No shortcuts here.
EIP-7732 and EIP-7928 deserve close attention because ePBS and BALs account for much of Glamsterdam’s expected capacity increase. Inclusion alone proves little. Both must work across different clients under genuine testnet conditions. A confirmed mainnet fork date, expected during H2 2026, will give traders a more definite event to price. But the evidence that matters comes after activation. How much more work did blocks handle? How well did nodes cope? Did users actually pay less? Until those answers arrive, ETH price forecasts are mostly guesswork.