Ethereum’s Oct. 6 Sepolia fork: why 200M gas needs a setting

Illustration: Conceptual validator test network; the equipment shown is not a real Sepolia node or Ethereum Foundation facility.

Ethereum’s Glamsterdam upgrade is scheduled for the Sepolia testnet on October 6. Node operators face a software deadline, while a 60 million gas default in two validator clients could make the network’s 200 million gas test harder to judge.

Ethereum is preparing to activate its Glamsterdam upgrade on Sepolia at 13:53:36 UTC on October 6 (9:53:36 a.m. Eastern). This is a testnet change. The Ethereum Foundation has not announced activation dates for Hoodi or mainnet, and ordinary ETH holders have no upgrade step to take now. Operators running Sepolia nodes and validators do: the Foundation’s activation notice says they need compatible execution and consensus software before the fork.

The timing makes this more than a routine version update. Glamsterdam changes how blocks are built and checked, while its new gas rules change what some applications can do within a transaction. There is also a narrower measurement problem hiding in the client release notes: the upgrade’s Sepolia gas-limit schedule calls for 200 million gas, but the listed Prysm and Teku validator releases can propose blocks using a 60 million gas default unless the operator explicitly changes the setting. A node can be ready for the fork without taking part in the larger-capacity test the operator thought it was running.

The 200M plan and the 60M default measure different things

In its Prysm 7.2.0 release notes, the client team says Sepolia’s 200 million gas-limit schedule landed after that release was cut. Prysm therefore defaults to 60 million in its post-fork proposer preferences. Its older --suggested-gas-limit option applies to pre-Gloas builder registrations and will not set the post-fork limit. Prysm documents a version 2 proposer setting or a keymanager API request for operators who want to set 200 million explicitly.

The Ethereum Foundation’s client table and operator guidance also lists Teku 26.9.1 as Sepolia-compatible, but says its default remains 60 million unless the operator sets --validators-builder-registration-default-gas-limit=200000000. These are specific versions and settings, not a claim that every Glamsterdam client has the same behavior. Operators should check the release notes for the version they actually run, including any newer release before October 6.

TECHi’s calculation makes the scale of the mismatch clear: 60 million is 30% of 200 million, leaving a 140 million gas difference in the proposed limit. Conversely, 200 million is about 3.33 times 60 million. Those are comparisons of configuration values, not a forecast of transactions per second, gas fees, or ETH’s price. Actual network behavior depends on which validators propose blocks, their settings, demand, client performance, and whether the upgrade completes cleanly. A 60 million proposal does not, by itself, prove a failed fork.

What Glamsterdam changes beyond the gas limit

The headline protocol change is enshrined proposer-builder separation, or ePBS. It moves the proposer-builder exchange into Ethereum’s consensus rules, with a builder committing to an execution payload and revealing it later. A separate payload timeliness check adds duties for validator and builder tooling. The Foundation says the design gives validators more time to verify the execution payload; that is an engineering aim, not a measured Sepolia result yet.

Another change, block-level access lists, records state touched during a block so clients can do more work in parallel. The upgrade also reprices state creation and access. In replay tests of historical mainnet transactions, Ethereum researchers found that the large majority were unaffected, but a small set depended on old gas assumptions. Some transactions completed after a gas-limit increase; a smaller potentially broken group required developers to inspect fixed stipends, hardcoded gas values, or logic based on remaining gas. The published guide gives no universal percentage of contracts that will break, so a broad failure claim would overstate the evidence.

That distinction matters for applications. A wallet or service that still estimates gas using old constants might reject a transaction locally or submit one that runs out of gas, even if the underlying contract can work with a higher limit. The Foundation directs builders to its affected-contract search and to test their own contracts and gas estimation against the new schedule. A clean fork would not settle every application-compatibility question.

Who needs to act before October 6?

Sepolia node operators should install releases that expressly support the scheduled Glamsterdam fork on both the execution and consensus sides. Sepolia validators must also update their validator client and review proposer and builder settings, particularly if their test intends to use a 200 million gas limit. Prysm and Teku operators need the version-specific setting described above. Application and wallet teams should test gas estimation and contracts that rely on hardcoded limits or unusual state access. These are separate checks; upgrading one client does not prove the full stack is ready.

Mainnet users and ETH holders need not change wallets or move funds because of this Sepolia announcement. The Foundation says it will announce mainnet timing separately. Claims that October 6 is an Ethereum mainnet launch, or that it automatically changes ETH’s investment case, confuse a test with a deployment.

For the separate investment question, TECHi’s ETH futures analysis, Ethereum ETF staking coverage, and 2026 Ethereum outlook examine market pricing and ownership channels. None establishes what the Sepolia test will deliver.

The useful evidence after activation will be whether Sepolia continues finalizing with the new clients, what gas limits validators actually propose, and which applications need fixes under the repriced rules. For now, the firm fact is the scheduled testnet activation. The 200 million figure is a configuration goal to observe, not a result already delivered.

Those observations answer different questions. Continued finalization would show that participating clients agreed on the new rules. Blocks proposed nearer the scheduled limit would give engineers a better stress test of execution and validation at that scale. A contract failure would need its own diagnosis: an outdated gas estimate, a hardcoded limit, and a protocol bug are not interchangeable explanations. Watching all three measures is more informative than treating the fork as a single pass-or-fail headline. It also gives the Ethereum teams evidence to use before they set dates for other networks.