This is a technical follow-up to the October 1 Glamsterdam schedule draft. The new information concerns differences between Prysm client versions, not a new decision on a mainnet upgrade.
The Ethereum Foundation announced on September 28, 2026, that Glamsterdam’s consensus-layer upgrade, Gloas, and execution-layer upgrade, Amsterdam, will activate on Sepolia on October 6 at 13:53:36 UTC. Dates for Hoodi and mainnet have not yet been determined. The EF also noted that although Prysm v7.2.0 supports the testnet fork, the proposer gas limit will still default to 60M after activation. To propose 200M blocks, validators must explicitly configure proposer settings or use the keymanager API; `--suggested-gas-limit` will no longer take effect after Gloas activates.
The official Prysm v7.2.1 release notes (2026-10-05) subsequently stated that the new version adds a Sepolia `GAS_LIMIT_SCHEDULE`, so validators will default to 200M gas from the start of that fork. To use a different value, validators must still set it through proposer settings, the keymanager API, or an applicable parameter override. In other words, v7.2.1 fixes the schedule’s default configuration, but that does not mean all Prysm nodes will upgrade automatically. Validators still need to check their client version, proposer settings, and compatible execution-layer version.
My assessment: This looks more like a testnet operations and compatibility reminder than a sign that Ethereum scaling has been delivered. If nodes run mixed versions or retain an explicit 60M setting, they may use different proposer parameters during testing, increasing the troubleshooting burden. Even if Sepolia successfully reaches 200M gas, that does not mean mainnet block capacity will increase in tandem or fees will fall immediately. The implications for $ETH still depend on test results, subsequent protocol decisions, and mainnet plans; the version fix should not be treated as a short-term fundamental catalyst.
For now, Sepolia validators should first check the Prysm v7.2.1 release notes and the EF client matrix to verify compatible consensus- and execution-layer versions. They should check whether proposer settings, keymanager configuration, or command-line parameters override the default schedule. After upgrading, they should monitor fork synchronization, block proposals, and whether gas limits are consistent. Non-validators and ordinary mainnet holders do not need to move funds or adjust their wallets because of a testnet version change.
Going forward, watch whether Sepolia activates as scheduled, whether block gas limits change according to the schedule, how different clients participate and produce blocks, and whether the EF separately sets dates for Hoodi or mainnet. If the testnet fork is delayed, clients prove incompatible, or the mainnet plan does not adopt the relevant schedule, then the assessment that “the test configuration is progressing smoothly” will no longer be supported. Its long-term impact on the network merits reassessment only once test results are stable and a clear mainnet process is in place.
Sources: Ethereum Foundation, “Glamsterdam Testnet Announcement” (2026-09-28): https://blog.ethereum.org/2026/09/17/glamsterdam-testnet-announcement . Official Prysm GitHub v7.2.1 release (2026-10-05): https://github.com/OffchainLabs/prysm/releases/tag/v7.2.1 . The Ethereum Foundation’s client version notes are also included in the testnet announcement.
The Ethereum Foundation announced on September 28, 2026, that Glamsterdam’s consensus-layer upgrade, Gloas, and execution-layer upgrade, Amsterdam, will activate on Sepolia on October 6 at 13:53:36 UTC. Dates for Hoodi and mainnet have not yet been determined. The EF also noted that although Prysm v7.2.0 supports the testnet fork, the proposer gas limit will still default to 60M after activation. To propose 200M blocks, validators must explicitly configure proposer settings or use the keymanager API; `--suggested-gas-limit` will no longer take effect after Gloas activates.
The official Prysm v7.2.1 release notes (2026-10-05) subsequently stated that the new version adds a Sepolia `GAS_LIMIT_SCHEDULE`, so validators will default to 200M gas from the start of that fork. To use a different value, validators must still set it through proposer settings, the keymanager API, or an applicable parameter override. In other words, v7.2.1 fixes the schedule’s default configuration, but that does not mean all Prysm nodes will upgrade automatically. Validators still need to check their client version, proposer settings, and compatible execution-layer version.
My assessment: This looks more like a testnet operations and compatibility reminder than a sign that Ethereum scaling has been delivered. If nodes run mixed versions or retain an explicit 60M setting, they may use different proposer parameters during testing, increasing the troubleshooting burden. Even if Sepolia successfully reaches 200M gas, that does not mean mainnet block capacity will increase in tandem or fees will fall immediately. The implications for $ETH still depend on test results, subsequent protocol decisions, and mainnet plans; the version fix should not be treated as a short-term fundamental catalyst.
For now, Sepolia validators should first check the Prysm v7.2.1 release notes and the EF client matrix to verify compatible consensus- and execution-layer versions. They should check whether proposer settings, keymanager configuration, or command-line parameters override the default schedule. After upgrading, they should monitor fork synchronization, block proposals, and whether gas limits are consistent. Non-validators and ordinary mainnet holders do not need to move funds or adjust their wallets because of a testnet version change.
Going forward, watch whether Sepolia activates as scheduled, whether block gas limits change according to the schedule, how different clients participate and produce blocks, and whether the EF separately sets dates for Hoodi or mainnet. If the testnet fork is delayed, clients prove incompatible, or the mainnet plan does not adopt the relevant schedule, then the assessment that “the test configuration is progressing smoothly” will no longer be supported. Its long-term impact on the network merits reassessment only once test results are stable and a clear mainnet process is in place.
Sources: Ethereum Foundation, “Glamsterdam Testnet Announcement” (2026-09-28): https://blog.ethereum.org/2026/09/17/glamsterdam-testnet-announcement . Official Prysm GitHub v7.2.1 release (2026-10-05): https://github.com/OffchainLabs/prysm/releases/tag/v7.2.1 . The Ethereum Foundation’s client version notes are also included in the testnet announcement.