Ethereum client Prysm shipped a patch for Glamsterdam’s Sepolia test on October 5, raising validators’ default gas limit to 200 million from the fork. The release it replaced would have left those validators at 60 million unless operators changed the setting themselves.
The gas limit caps how much computation each Ethereum block can hold. The 200 million setting is Sepolia’s scheduled default in this client, part of the capacity increase developers are testing before any mainnet decision. The patch also changes how validators configure external block builders. Under EIP-7732, Glamsterdam moves that builder role into the protocol. v7.2.1 only changes how Prysm reads the settings.
Offchain Labs, which maintains Prysm, published v7.2.1 on GitHub on October 5 at 21:18 UTC. Glamsterdam was scheduled to activate on the Sepolia testnet at 13:53:36 UTC on October 6, according to the release notes. Prysm is consensus-layer software, which validators run to propose and attest to blocks.
What Prysm v7.2.1 Changes
The release notes say v7.2.1 focuses on configuring Gloas builders in the validator client. Gloas is the consensus-layer half of Glamsterdam; Amsterdam is the execution-layer half.
The release adds Sepolia’s gas limit schedule, so validators default to 200 million gas from the fork at epoch 353,024. The notes say this requires no action from operators.
Operators who want a different limit can set gas_limit in their proposer settings, use the keymanager API, or pass the --suggested-gas-limit flag. Under v7.2.1, that flag also applies after the fork, where it overrides the schedule. The validator client now logs a warning when the flag is set on a network with Gloas scheduled and when its value exceeds the highest scheduled limit.
Why v7.2.0 Defaulted to 60 Million Gas
Prysm’s previous release, v7.2.0, scheduled the Sepolia fork and was published on September 28. Its notes state that Sepolia’s Gloas configuration, published upstream on September 24, added an EIP-8261 schedule raising the network gas limit to 200 million at the fork.
That schedule landed after v7.2.0 was cut and was not included in it. As a result, validators on v7.2.0 defaulted to 60 million gas in their Gloas proposer preferences.
The v7.2.0 notes told Sepolia validators who wanted to propose at 200 million to set the value explicitly in a version 2 proposer settings file or through the keymanager API. They also stated that --suggested-gas-limit would have no effect after the fork and that a follow-up release would include the schedule.
Builder Settings Change Before Updating
Under Glamsterdam’s enshrined proposer-builder separation (ePBS), specialized builders compete to supply a block’s transactions, and the protocol itself handles the exchange between builder and validator. Until now, that exchange has relied on outside software such as MEV-Boost relays.
v7.2.1 changes the format of two builder fields in proposer settings files. auth_data and builder_pubkeys, renamed from pubkeys, now take 0x-hex values instead of base64, matching the keymanager API. The release notes tell operators testing Gloas builders to update so their builder authentication is read correctly and to review their builder settings before updating.
The release also adds validator client flags that configure builders for all validators from the command line. These are --builder-urls, --builder-min-bid, --builder-boost-factor and --builder-max-execution-payment. Default builder auth_data is now derived from the builder URL’s hostname, and URLs without a hostname are rejected.
On the beacon node, a new --builder-bid-timeout flag sets how long to wait for builder bids. The default wait doubles to 600 milliseconds from 300 milliseconds.
Partial Data Columns Now On by Default
v7.2.1 also turns on partial data columns by default. This feature lets nodes share blob data at the level of individual cells rather than whole columns. Blob data is the temporary data that layer-2 networks post to Ethereum, which nodes distribute through a system called PeerDAS.
Under the change, nodes send and receive the cells they hold instead of complete columns. Operators can revert to full-column sharing with --disable-partial-data-columns. The older --partial-data-columns flag is deprecated and has no effect.
The release also lists fixes for producing the first Gloas block and for replaying historical states when certain stored records are missing.
What Glamsterdam Brings to Sepolia
The Ethereum Foundation scheduled Glamsterdam’s Sepolia activation for epoch 353,024, slot 11,296,768, as The Crypto Times reported on September 29. The upgrade includes EIP-7732, which brings proposer-builder separation into the protocol, and EIP-7928, which adds block-level access lists.
The v7.2.0 notes required Sepolia operators to update before the fork and to run an execution client that supports Amsterdam on Sepolia.
Hoodi and Mainnet Dates Not Yet Set
According to the v7.2.0 release notes, Gloas is not yet scheduled for the Hoodi testnet or for the mainnet. Operators on those networks are told to update on their regular schedule.
The 200 million gas schedule in v7.2.1 applies to Sepolia only. No gas limit for the mainnet under Glamsterdam has been announced.
Also Read: Ethereum Foundation Explores Native Assertions for Safer Transactions
