Glamsterdam: the complete guide for Ethereum developers
Author: Alchemy

Glamsterdam just went live. Ethereum's next network upgrade activated on the Sepolia testnet, October 6, at 13:53:36 UTC, the first public testnet to run it and one of the last rehearsals before mainnet. We've been preparing for this upgrade for weeks, stress-testing our infrastructure against Glamsterdam devnets so you can keep building without interruption. Here's what we've done and what it means for you.
Key things to know:
- Glamsterdam activated on Sepolia, combining enshrined proposer builder separation (EIP-7732) and block level access lists (EIP-7928) with a repriced gas model for state growth (EIP-8037)
- Sepolia is testing a 200 million gas limit, more than 3x today's mainnet limit, to validate the upgrade's scaling changes
- EIP-8037 is the one developers will notice most: contract deployments and other storage-heavy writes now cost more gas
- We stress-tested our industry-leading bundler against Glamsterdam devnets for weeks ahead of today and shipped gas-estimation improvements so sponsored transactions keep working as the new rules take effect, all while monitoring and handling edge cases as they surface on the road to mainnet.
- Hoodi and mainnet activation dates aren't set yet; client teams will use Sepolia results to decide them
What is Glamsterdam?
Glamsterdam is Ethereum's next coordinated network upgrade. The name combines Amsterdam, the execution layer upgrade named after a past Devconnect location, and Gloas, the consensus layer upgrade. Because it touches both layers, every node operator has to update both their execution and consensus clients.
Two EIPs matter most here:
- EIP-7732 (enshrined proposer builder separation). Proposer builder separation runs today through an off-protocol relay system, MEV-Boost. EIP-7732 moves that separation into the protocol itself, splitting block building from block proposing and attesting. One effect: it stretches the network's data propagation window from about 2 seconds to roughly 9, giving blocks more room to carry data.
- EIP-7928 (block level access lists). Every block now ships with a map of which accounts and storage slots it touches, before any of its transactions execute. Once a node knows what a block will touch ahead of time, it can execute independent parts of that block in parallel instead of one transaction at a time.
What changed on Sepolia testnet
Sepolia's Glamsterdam fork is testing a 200 million gas limit, a step up meant to check how clients handle more execution work per block under the new ePBS and parallel-execution rules. Validators on some clients, including Prysm and Teku, don't pick up the higher limit automatically; node operators had to configure it ahead of the fork. This is also the first time EIP-8037 is live on a public network.
EIP-8037 changes your gas costs
EIP-8037 reprices gas for state creation, tying the cost of an operation to how much new permanent state it writes, instead of today's flatter pricing. The goal is to keep Ethereum's state database growing at a predictable rate instead of expanding unchecked as more apps deploy contracts and write storage. In practice:
- Deploying a new contract costs more gas than it did before Glamsterdam
- Any operation that writes new storage, not just contract creation, is affected
- Gas estimates built on pre-Glamsterdam assumptions can undercount the real cost once the new pricing is live
What we did to prepare
To get ahead of today's activation, we ran our industry-leading bundler against Glamsterdam devnets for weeks beforehand, specifically to see how EIP-8037's new state-gas pricing would show up in sponsored transactions before it ever reached production traffic. That testing showed us exactly where our gas estimates needed to be updated for the new rules. From there:
- We built real-time monitoring. It tracks gas costs at every step, estimation, the mempool, and block building, so we catch the impact of the new pricing immediately instead of after the fact. This doesn't change what any transaction returns or how it's processed; it just gives us better reliability and proactive visibility.
- We upgraded our own nodes ahead of this activation, across our network.
- We have a team on call, actively watching Sepolia right now for edge cases, especially around how the new rules interact with custom paymasters and batched transactions.
The result: the APIs you use, RPC, gasless transactions, and everything in between, keep working seamlessly through Glamsterdam's changes, with nothing you need to change on your end.
What this means for your app
Nothing changes in how you call our APIs. A few things worth checking now that Sepolia is live:
- Contract deployments. If your app deploys contracts per user, re-check your gas budget against Sepolia's new pricing.
- Sponsored transactions and paymasters. If you sponsor gas or run a paymaster with a fixed budget, test it against Sepolia before mainnet activation, not after.
- Gas estimation caching. If you cache gas estimates or hardcode gas limits anywhere in your stack, those numbers may now be out of date.
Happy building! Visit our support center, read the docs, or reach out to our team for specialized solutions and pricing at scale.
FAQ
What is Glamsterdam?
Glamsterdam is Ethereum's next network upgrade, combining an execution layer upgrade (Amsterdam) and a consensus layer upgrade (Gloas). It activated on the Sepolia testnet on October 6.
Has Glamsterdam activated on mainnet?
No. Today's activation is Sepolia only. Hoodi and mainnet activation dates haven't been decided; client teams will set them using results from Sepolia.
What does EIP-8037 change for developers?
It reprices gas for state creation, so contract deployments and other operations that write new storage cost more gas than before.
Does this affect how I call Alchemy's APIs?
No. We handle the node and bundler infrastructure side of the transition. If your app deploys contracts, sponsors gas, or runs a paymaster, re-test your gas assumptions against the live Sepolia network.
Alchemy Newsletter
Be the first to know about releases
Sign up for our newsletter
Get the latest product updates and resources from Alchemy
By entering your email address, you agree to receive our marketing communications and product updates. You acknowledge that Alchemy processes the information we receive in accordance with our Privacy Notice. You can unsubscribe anytime.
Related articles

Which RPC provider should you build on in Tokyo?
We benchmarked five of the RPC providers serving Tokyo across five chains. Here is how they compare, and where the differences matter for latency-sensitive teams.

Architecting Solana RPC reads for industry-leading speed and reliability
Alchemy has the lowest Solana read latency: 9.21 ms, about 26% faster than the next provider.

Alchemy launches Tokyo regional support
Node RPC, WebSockets, and Dedicated Clusters are now live in Tokyo, with up to 8x lower median latency for requests from Japan.