Ethereum Prepares for 200M Gas Limit as Layer 1 Scaling Moves Ahead

Ethereum’s Glamsterdam upgrade is preparing the network to consider much larger blocks, but the much-cited 200 million gas figure is not a confirmed mainnet setting. It is an option that Sepolia validators can choose after the fork.

That distinction matters. A larger gas limit can make more room for transactions when demand rises, but it does not make block times faster. And the proposal still has a familiar Ethereum wrinkle attached: the network gets there through operator choices and client defaults, rather than one centrally imposed switch.

What 200 Million Gas Means on Sepolia

The Ethereum Foundation has confirmed that Prysm 7.2.0 and Teku 26.9.1 support the Glamsterdam fork on Sepolia. Both clients default to a 60 million gas limit after activation. Validators that want to propose blocks with a 200 million gas limit must configure that preference explicitly.

For Prysm, that means using version 2 proposer settings or the keymanager API. Teku requires the --validators-builder-registration-default-gas-limit=200000000 flag. The Foundation also says the old --suggested-gas-limit option has no effect after Gloas.

So, 200 million gas is a configured validator preference in this testnet context, not a number the Ethereum Foundation has scheduled as Sepolia’s network-wide result. How much capacity Sepolia actually reaches will depend on how many validators adopt it and how the network’s gas limit moves from there.

Glamsterdam is still moving through testing. Sepolia activation is set for epoch 353,024, slot 11,296,768, on October 6, 2026 at 13:53:36. The Foundation says Hoodi and mainnet activation times have not been decided. There is no confirmed mainnet gas target in the announcement.

The Schedule Behind the Push

The relevant improvement is EIP-8261, the Gas Limit Schedule. It is still in peer review and was created on May 11, 2026.

The proposal introduces an optional GAS_LIMIT_SCHEDULE field for consensus-layer client configuration. Each entry would begin at a specified epoch and serve two purposes: it would be the default target when an operator has no configuration, and the recommended maximum.

That sounds more fixed than it is. EIP-8261 does not change consensus rules or make the scheduled value a hard block limit. Blocks above or below the scheduled value would remain valid under the existing EIP-1559 elasticity rule. A scheduled increase would also arrive gradually rather than as an instant jump.

The motivation is practical. Current gas-limit defaults are tied to client releases, so a new default can take effect whenever an operator updates software. That is not the same thing as coordinating a network-wide increase at a known epoch. EIP-8261 proposes a machine-readable schedule so validators can aim for the same change at the same point in the chain.

More Capacity, Not Faster Blocks

Glamsterdam’s wider scaling story is not built around one gas number. The upgrade combines the Amsterdam execution-layer changes with Gloas at the consensus layer. Its headline changes include enshrined proposer-builder separation and block-level access lists.

The Ethereum Foundation says these changes are intended to support greater Layer 1 throughput while keeping block validation practical for node operators. Block-level access lists, for example, record accounts and storage locations touched during a block, allowing clients to read state and validate transactions in parallel.

Gas accounting also changes. EIP-8037 increases and separately meters the cost of creating state. EIP-8038 updates state-access costs. Other changes touch transaction gas, calldata, access lists and block accounting. The package also removes refunds from block gas accounting and removes the SELFDESTRUCT burn.

These changes suggest an effort to use the chain’s capacity more efficiently, not simply pack more work into every block.

Fees Still Depend on Demand

More gas capacity can ease congestion and reduce pressure on transaction fees when demand rises. It does not automatically make transactions cheaper. The brief provides no fee data, usage figures or measured Layer 2 effects tied to a 200 million gas target, so the size of the benefit remains unquantified.

The 200 million figure also has a ceiling of sorts. EIP-7825 sets a protocol-level cap of 16,777,216 gas for an individual transaction, regardless of the block gas limit. A larger block budget therefore creates room for more aggregate activity, not permission for one operation to consume the whole block.

There is another useful marker in the earlier roadmap. EIP-7935 set the previous default step at 60 million gas, up from mainnet’s 36 million. That proposal treated 150 million gas as an important threshold for possible adversarial block-size concerns, because the then-current worst-case block size was approaching the consensus-layer gossip limit.

The choice is not simply “more is better.” Ethereum is balancing execution capacity against node workload, block propagation and the costs of building and validating blocks.

What Is Confirmed for Glamsterdam

The Sepolia fork has a fixed activation point, supported client releases and an active bug bounty for Glamsterdam specifications and EIPs. The Foundation’s release table includes consensus-layer clients from Grandine, Lighthouse, Lodestar, Nimbus, Prysm and Teku, alongside six execution-layer releases.

But the evidence supports a narrower conclusion than the headline suggests: Glamsterdam gives validators a way to coordinate gas-limit preferences and test a much larger capacity target on Sepolia. It does not yet confirm a 200 million mainnet gas limit, a mainnet activation date or the fee effect of either.

For Ethereum users, the next meaningful evidence will be how much of that optional capacity validators actually activate, and what Sepolia reveals about execution, validation and fees.