Ethereum Targets 200M Gas in October 6 Sepolia Upgrade

Sepolia’s October 6 fork requires both Ethereum clients

The Glamsterdam upgrade specification records activation at epoch 353,024, corresponding to slot 11,296,768. An epoch groups validator slots; the published UTC time makes that network milestone usable as an operator deadline.

Glamsterdam combines Amsterdam changes on Ethereum’s execution layer with Gloas changes on its consensus layer. Execution software processes transactions and state, while consensus software coordinates validators and agreement over blocks. Updating one side leaves the other side’s compatibility unresolved.

Teku’s 26.9.1 release explicitly identifies itself as required for Sepolia’s upcoming Gloas fork. It also fixes synchronization and out-of-memory behavior, including cases where a node could incorrectly report itself synchronized after stopping far behind the chain head.

Those fixes make version selection more consequential than checking whether a process starts. A running service can still give operators an incomplete picture of readiness if its synchronization state is wrong.

The release also says Teku will stop publishing binaries to Cloudsmith in upcoming versions. Operators whose deployment automation depends on that channel will need to adjust it to use GitHub release distributions. That is separate from the fork date but relevant to keeping future updates available.

Mainnet ETH holders have no required action for this Sepolia announcement. Infrastructure teams should match their deployed network and client releases to the actual activation being supported, rather than treating every Ethereum installation as subject to the same deadline.

Prysm and Teku need explicit 200M gas preferences

Prysm’s 7.2.0 release notes expose a timing mismatch: the upstream Sepolia gas schedule was added after that release was cut. The software supports the fork, but its validator preference remains at 60 million gas unless the operator changes it.

The notes direct operators targeting 200 million to use version 2 proposer settings with a gas_limit value of 200000000, or configure the preference through the keymanager interface. They warn that --suggested-gas-limit applies to earlier MEV-Boost registrations and has no effect after Gloas.

Prysm also rejects unknown keys in proposer settings loaded from a file or URL. Reviewing those settings is therefore part of the upgrade, rather than an optional cleanup after installing the binary.

Teku has a similar default-setting issue. Its command-line documentation lists 60000000 as the builder-registration gas default. The Foundation’s notice instructs validators targeting 200 million to set --validators-builder-registration-default-gas-limit=200000000 explicitly.

The larger number measures a block’s aggregate gas capacity, not transactions per second or a transfer’s dollar fee. It follows earlier testing that supported a 200M gas limit, while actual block limits still depend on proposer preferences and protocol validity rules.

EIP-8261 describes the schedule as optional client guidance. It preserves operator overrides and does not make a scheduled maximum a consensus rule. Blocks above or below the recommendation remain valid if they satisfy existing gas-limit rules.

The specification also retains the block-by-block adjustment bound of roughly one part in 1,024. A published 200 million target therefore should not be read as proof that every block instantly reaches that capacity at the fork.

EIP-8261 recommends looking up the active schedule for each proposal or registration duty. Caching a value when the service starts can defeat the intended epoch-based switch. The operational distinction is between software recognizing the fork, preferences selecting a target, and the chain’s observed blocks demonstrating what limit is actually being used.

Glamsterdam changes block building and application gas costs

The principal consensus change, EIP-7732, brings the exchange between a block proposer and a builder into Ethereum’s protocol. The builder commits to a transaction payload and later reveals it, while the protocol handles payment to the proposer.

It also separates consensus checks from transaction execution checks. A subset of validators receives a duty to attest whether the promised payload and related blob data arrived on time. This changes the work performed by validator and builder infrastructure, even when a user’s wallet experience looks familiar.

EIP-7928’s block-level access lists address a different bottleneck. They record accounts and storage accessed during execution, together with resulting state changes, enabling clients to read data and validate work in parallel. The lists are enforced at block level, unlike earlier optional transaction access lists.

Capacity comes with changed resource pricing. EIP-8037 separately meters new persistent state and raises creation costs to constrain database growth as block limits increase. More aggregate room for work does not imply every individual operation becomes cheaper.

EIP-8038 changes state-access and write charges. Its compatibility guidance calls for updated wallet and node gas estimation; estimates using old parameters can leave transactions with insufficient gas. Sepolia gives application teams a place to verify those paths before mainnet deployment.

That testing needs to cover the transaction path through both the application and its RPC provider. A wallet can present an unchanged interface while relying on a node to calculate the gas needed. Successful estimation under the older rules alone does not establish that the same transaction will complete after repricing.

The test also sits within Ethereum’s broader development sequence. The separate Hegotá staking-reward burn proposal was withdrawn; its outcome does not change which proposals are scheduled for Glamsterdam.

Alternative.me’s Bitcoin-focused Fear and Greed Index read 65, or Greed, on October 4, compared with 67 the previous day. It describes broader market sentiment, rather than Ethereum client readiness.

As of October 4 at 16:07 UTC, Hoodi and mainnet activation dates remained undecided. The next evidence to watch is Sepolia’s actual fork, block-limit behavior, validator participation and application test results, followed by separate deployment notices for the remaining networks.