Prysm 7.2.1, published on October 5, adds the gas-limit schedule for Sepolia’s Gloas fork and changes several validator and data-availability defaults. Operators can follow the scheduled values automatically, but custom proposer settings and builder configurations still need deliberate review.
Sepolia’s scheduled default and override options
The release sets a 200 million gas limit from Sepolia epoch 353024, scheduled for October 6 at 13:53:36 UTC. A validator without a separate override follows that network schedule. Operators who need another value can set one in proposer settings, through the keymanager API, or with the --suggested-gas-limit flag.
A higher block gas limit expands the maximum execution work a block may contain; it does not promise that blocks will be full, fees will fall, or the same setting will reach Ethereum mainnet. Sepolia provides a place to observe client behavior and resource demands before any separate mainnet decision.
Existing overrides can produce different behavior
The automatic schedule reduces the chance that an untouched Prysm configuration proposes a lower limit during the test. It does not erase operator choices. Prysm’s release notes say --suggested-gas-limit continues to override the scheduled value from Gloas onward, and the client warns when the flag is present on a network with Gloas scheduled.
A practical upgrade review should therefore compare the running service definition, proposer-settings file, and keymanager configuration with the intended test plan. Seeing version 7.2.1 in a process list is not enough to establish which gas limit a validator will propose. The effective value depends on the schedule and any higher-priority configuration that remains in place.
The release also changes data propagation defaults
Prysm now enables partial data columns by default. Under this mode, nodes gossip data-column cells rather than requiring each participant to send and receive complete columns. Operators can return to full-column gossip with --disable-partial-data-columns. The older --partial-data-columns option is deprecated and no longer changes behavior.
This is operationally separate from the gas-limit schedule. One affects the execution capacity a proposed block advertises; the other affects how PeerDAS data is disseminated. Treating both as a single “capacity increase” would obscure different monitoring signals and rollback choices.
Builder settings need an explicit compatibility check
The update changes how proposer-settings files represent builder authentication fields. The auth_data and builder_pubkeys values now use 0x-prefixed hexadecimal notation rather than base64, matching the keymanager API. It also raises the default wait for Gloas builder bids from 300 milliseconds to 600 milliseconds and introduces additional builder controls.
For teams testing Gloas builders, these format and timing changes may be more immediate than the scheduled gas limit. A safe rollout separates three checks: confirm the client binary and release provenance, inspect overrides and builder credentials without exposing them, and watch proposal and peer-to-peer metrics after restart. The release establishes client behavior for this test; it does not by itself establish a mainnet policy.
Source: BTCUSA.