Ethereum Foundation deploys Glamsterdam upgrade to test optional 200 million gas limit on Sepolia

• Glamsterdam activates on Sepolia on Oct. 6 at 13:53:36 UTC, combining the Amsterdam execution upgrade with the Gloas consensus upgrade.
• EIP-8261 sets an optional 200 million gas schedule, but Prysm 7.2.0 and Teku 26.9.1 both default to 60 million unless validators manually reconfigure.
• Ethereum’s gas limit has already risen from 30 million in February 2025 to 60 million under Fusaka, and Hoodi and mainnet Glamsterdam dates remain undecided.

• 200M optional gas target Glamsterdam schedules, over 3x the 60M default
• 60M gas limit clients still ship with unless validators opt in manually
• Oct. 6 Sepolia activation date, set roughly eight months after Fusaka’s 60M rollout

The Ethereum Foundation said in its testnet announcement that node operators must update both their execution and consensus layer clients before the Sepolia fork, and that stakers must also upgrade their beacon node and validator software. The announcement makes clear that simply installing compatible software will not move Sepolia toward the 200 million gas figure on its own. Glamsterdam’s headline features are enshrined proposer-builder separation and block-level access lists, changes the Foundation says are designed to support greater Layer 1 throughput while keeping block validation manageable for node operators.

Glamsterdam Bundles ePBS and Access Lists Into One Sepolia Fork

Glamsterdam merges the Amsterdam execution-layer upgrade with the Gloas consensus-layer upgrade into a single coordinated fork. Its two headline changes are proposer-builder separation, brought directly into Ethereum’s consensus protocol rather than relying on trusted middleware, and block-level access lists, which let clients read state and validate transactions in parallel.

The Foundation frames both as groundwork for higher execution capacity without making block validation impractical for ordinary node operators.

Hoodi and mainnet activation dates have not been set; Tuesday’s fork covers Sepolia only, with no action required from mainnet users or ETH holders.

EIP-8261 Makes 200 Million a Recommendation, Not a Rule

The 200 million figure comes from EIP-8261, which lets consensus-layer clients source their gas-limit preference from an epoch-based schedule instead of hardcoded, release-scoped defaults. The proposal does not change Ethereum’s consensus-validity rules: EIP-1559’s existing elasticity mechanism remains the only gas-limit rule, and blocks above or below the scheduled value stay valid either way.

That design solves a coordination problem the proposal spells out directly. If clients ship a new higher default ahead of a planned activation epoch, early-updating nodes start voting the limit up before the network has agreed the value is safe; if the default ships only after activation, adoption is slow and operationally awkward.

EIP-8261 mirrors the epoch-based blob schedule format introduced in a separate configuration standard and generalizes an approach already tested through a prior gas-limit coordination, giving Ethereum a single machine-readable place to record “the gas limit the network should run at” rather than requiring every client team to hardcode a new number.

In practice, this turns Sepolia into a coordination test that was first reported by CryptoSlate: the realized gas limit will move only as far as validators choose to push it, not jump to 200 million automatically. The open question the document leaves unresolved is how quickly validator operators will actually adopt the higher preference once Glamsterdam goes live, since the schedule only warns clients when a configured value exceeds the recommendation rather than clamping it.

Validators Must Flip a Setting or Stay at 60 Million

Prysm 7.2.0 and Teku 26.9.1 both support the Sepolia fork, but the Foundation confirmed both continue defaulting to 60 million gas after activation unless an operator explicitly reconfigures. Prysm validators must use version 2 proposer settings or the keymanager API, since the older suggested-gas-limit flag has no effect after Gloas.

Teku validators can override the default through their validator configuration.

That manual step is the whole experiment. Sepolia’s gas limit rises only as fast as validators choose to configure it.

Fusaka already introduced a 16.7 million gas cap on any single transaction, a safeguard that stays in place regardless of how high the overall block limit climbs. That means a higher block limit mainly creates room for more aggregate activity, such as decentralized exchanges and other high-demand DeFi protocols like those reviewed in Aave governance’s recent proposal, rather than letting any individual smart-contract call expand without limit. Client teams such as Geth, which recently shipped history-pruning options in its v1.17.7 release, will need comparable Sepolia-ready builds before the test can draw conclusions across the full client set.

The CCS read. We read this as Ethereum testing its appetite for throughput before committing capital-intensive infrastructure to it. Staking providers and validator operators now carry an operational decision that doubles as a vote on scaling speed, and their default inaction, since 60 million requires no configuration change, could understate real demand for 200 million until mainnet forces the question.

Hoodi and mainnet activation dates remain undecided, and the Ethereum Foundation says those will be announced separately once client teams agree on timing. Validator participation in the 200 million preference on Sepolia is the signal developers will watch before deciding how far, and how fast, to push the same change toward mainnet.