The Ethereum Foundation has set October 6 as the activation date for the Glamsterdam upgrade on Ethereum's Sepolia testnet, giving node operators a deadline to update their software and application teams a public network on which to test the changes. Ordinary ETH holders have no action to take for this activation. For readers less familiar with Ethereum's development cycle, a testnet is a parallel network where client teams and application developers rehearse protocol changes before changes reach Ethereum's main network, so this activation is a coordination milestone in the run-up to any mainnet scheduling rather than a change to the live chain.

According to the announcement published on the Foundation's blog, Glamsterdam prepares Ethereum to handle more work while changing the gas charges for certain operations. The public test will let developers check whether applications still execute correctly and estimate fees accurately under the new rules.

Will Glamsterdam change what users pay?

The effect depends on the transaction. Creating an account, deploying contract code or adding storage leaves information that Ethereum's nodes must retain, and Glamsterdam changes the gas charged for that work as well as for accessing existing records.

EIP-8037 increases and separately accounts for state creation costs, while EIP-8038 updates charges for reading and writing stored information. An application that creates substantial new storage will therefore face a different cost profile from a simple payment.

For a plain ETH transfer to an existing ordinary account, the current transaction-gas specification (EIP-2780) keeps the charge at 21,000 execution gas. That figure measures the work charged to the transaction; the amount actually paid still depends on the price of gas when it is submitted.

Ethereum's fee documentation explains that the final charge depends on gas consumed and the price per unit, with demand influencing pricing. More capacity can reduce competition for block space, while higher charges for particular operations can increase their gas consumption. A claim that Glamsterdam will make every transaction cheaper would overlook that distinction.

Why Ethereum is changing the work behind each block

Increasing capacity also increases the work nodes must perform: receiving transaction data, checking it and maintaining Ethereum's records. Glamsterdam addresses the time available for those checks and how client software organizes access to the data. Balancing those two pressures — fitting more useful work into each block while keeping the time needed to verify it manageable — is the constraint the upgrade is designed around, and it is why the scaling and repricing changes land together.

Block builders: bringing the handoff into the protocol

Specialized builders already choose and arrange transactions for many validators. Enshrined proposer-builder separation (ePBS) moves the commitment, delivery and payment mechanism for that relationship into Ethereum's protocol.

Under the design, a validator proposing a block selects a builder's commitment to supply particular transaction data, and the builder then delivers it. Separating consensus checks from execution checks gives validators more time to verify the data, while the protocol handles payment for the exchange.

Access lists: helping nodes organize validation

Block-level access lists record the accounts and storage touched during execution, together with the resulting values. Client software can use that record to load data in parallel and organize compatible validation work in parallel.

The list is produced from execution data and must itself be checked. It helps nodes identify dependencies between transactions; it does not predict their effects before the builder executes them, and the performance improvement depends on how clients implement these capabilities.

Together, these changes create room for greater execution capacity. Gas repricing addresses the accompanying database burden: allowing more activity is easier to sustain when operations that create or access stored data are charged in proportion to their resource demands.

A fixed gas allowance can become an application problem

Consider a contract that gives an internal operation a fixed amount of gas. If that operation becomes more expensive, it may exceed the allowance and fail, and giving the overall transaction more gas does not necessarily change a limit written into the contract itself.

This is why testing needs to go beyond checking whether the network activates successfully. A wallet may need to revise its fee estimates, while a contract with a hardcoded allowance may require a different fix.

The Foundation's repricing impact analysis replayed historical mainnet transactions under the proposed gas schedule. In the transactions tested, the large majority produced unchanged outcomes. Some affected transactions completed after the supplied gas limit was increased, while a smaller group remained potentially broken even with a substantially higher limit. Developers can use the Foundation's affected-contract search to investigate addresses and failure types. Teams maintaining wallets, transaction services and node tooling also need to update gas estimation rather than rely on cached cost assumptions. With October 6 now fixed, the observable checkpoints between the testnet activation and any future mainnet scheduling are concrete: whether wallet and tooling releases ship updated gas estimation, and whether teams behind contracts surfaced by the search deploy fixes of their own.

Who needs to act?

Sepolia operators and validators: Install compatible execution and consensus clients. Validators must update their beacon node and validator client, and review the new ePBS duties and builder-tooling requirements.

Application developers: Test execution and gas estimates under the revised rules, especially where contracts use fixed gas values.

Mainnet users and ETH holders: No action is required for this testnet activation. Mainnet instructions will accompany a separate announcement.

A successful activation will show that clients follow the new rules together. The application testing that follows will show whether wallets estimate fees correctly and affected contracts operate reliably — both are necessary before the proposed scaling improvements can deliver a dependable service to mainnet users.