This EIP recommends that, starting with Gloas (EIP-7732), consensus layer clients source their gas limit preference from an optional GAS_LIMIT_SCHEDULE field in the consensus layer config.yaml instead of hardcoded, release-scoped defaults. Each entry activates at the start of its specified epoch and provides a value that plays two roles: it is the default gas limit that validator clients target in the absence of operator configuration, and the recommended maximum. The schedule is ignored before Gloas, preserving existing gas limit behavior. Operators remain free to configure any value; clients should warn when a configured preference exceeds the active scheduled value, but honor it because the maximum is a recommendation, not a rule. The schedule lives only on the consensus layer because post-Gloas the validator's preference flows through validator registrations and the builder pipeline, with no execution layer configuration involved. No consensus rules are changed: the EIP-1559 ±1/1024 elasticity rule remains the only gas-limit validity rule, and blocks above or below the scheduled value remain valid.
Today the block gas limit is set by each block proposer, driven by validator client "preferred gas limit" settings, client default configurations, and builder bids, with the ±1/1024 elasticity rule from EIP-1559 moving the realized limit block by block.
The pain point this EIP addresses is that gas limit defaults are release-scoped rather than epoch-based: a new default activates whenever an operator happens to update their node, not at a network-coordinated epoch. This creates a concrete coordination problem for large increases. Suppose clients want to raise the default from 60M toward a substantially higher value at a future epoch:
There is also no single place where "the gas limit the network should run at" is written down: moving the network today requires either every client team shipping a new hardcoded default, or a large share of operators updating flags, coordinated socially over months. EIP-7935 demonstrated that coordinating a default gas limit recommendation at a known epoch works; this EIP generalizes that approach into a reusable, machine-readable schedule, mirroring the epoch-based BLOB_SCHEDULE configuration format from EIP-7892.
With Gloas (EIP-7732), the consensus layer becomes the natural single home for this schedule: the gas limit a block is built to originates from the validator side of the builder flow, so a CL configuration entry can drive the network's gas limit end to end without any execution layer configuration.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.
This EIP changes no consensus rules. The EIP-1559 gas limit validity rules (±1/1024 elasticity, 5000 minimum) are unchanged, and a block whose gas_limit differs from the scheduled value in either direction remains valid. Everything below is recommended client and tooling behavior.
The consensus layer config.yaml MAY be extended with a GAS_LIMIT_SCHEDULE field, mirroring the BLOB_SCHEDULE mechanism in EIP-7892. Entries represent recommended gas limit changes that take effect at the start of the listed epoch:
GAS_LIMIT_SCHEDULE:
- EPOCH: 500000 # Gloas activation epoch
GAS_LIMIT: 60000000
- EPOCH: 520000 # A later scheduled increase
GAS_LIMIT: 75000000
- EPOCH: 540000 # Another scheduled increase
GAS_LIMIT: 90000000
EPOCH and GAS_LIMIT are uint64 values; GAS_LIMIT matches the type of ExecutionPayload.gas_limit in the consensus specifications.
The field is OPTIONAL: CL clients MAY add support for it, and clients that do not recognize it ignore it, per the existing convention for unknown configuration keys. Supporting clients MUST ignore the schedule for duties before GLOAS_FORK_EPOCH. A client that is not using the parameter because the duty is pre-Gloas, the field is absent, or no schedule entry is active simply keeps its existing gas limit behavior.
Each entry independently schedules a recommended gas limit change at its EPOCH. An entry MAY align with a protocol upgrade, but the schedule itself does not create or require a fork.
Define:
def get_scheduled_gas_limit(epoch: Epoch, config: Config) -> Optional[int]:
if epoch < config.GLOAS_FORK_EPOCH:
return None
active_entries = [
entry for entry in config.GAS_LIMIT_SCHEDULE
if entry.EPOCH <= epoch
]
if not active_entries:
return None
# Latest schedule entry whose EPOCH <= epoch
return max(active_entries, key=lambda entry: entry.EPOCH).GAS_LIMIT
For CL clients that support GAS_LIMIT_SCHEDULE, an active scheduled value serves as both the default gas limit and the recommended maximum:
get_scheduled_gas_limit(epoch) returns a value, the client SHOULD use it as the gas limit preference, where epoch is the epoch of the slot the registration or proposal applies to. Before Gloas or when no entry is active, the client SHOULD retain its existing default behavior. Clients SHOULD NOT introduce a separate release-scoped default for epochs covered by an active schedule entry.configured gas limit 100000000 exceeds the recommended maximum of 90000000 at epoch 540000. Exceeding the recommendation is thereby a deliberate, visible operator decision rather than a silent one.gas_limit does not exceed the scheduled value for the bid's slot.The schedule only delivers its benefit if the effective default changes exactly at the configured epoch boundary, which requires new client logic: today, gas limit defaults are read once (at startup, or when a validator registration is created) and held constant. Under this EIP, the scheduled value SHOULD be looked up per duty against the epoch of the slot being proposed or registered for, never against wall-clock time or a value cached at startup. A running node then switches its preference at the first slot of the configured epoch with no restart, follow-up release, or operator action. Since validator registrations are re-issued periodically, registrations naturally roll over to a new scheduled value as duties cross the activation epoch.
Because the schedule is keyed by epoch, a release shipped months before an entry activates keeps using the current value until that epoch, then switches automatically. This makes it safe to ship large future increases well ahead of time: early updaters do not begin voting toward the new value before its configured activation epoch.
Starting with Gloas (EIP-7732), the gas limit a block is built to originates on the consensus layer side of the builder flow — the validator's preference, expressed through validator registrations and the payload bid path — rather than from execution layer configuration. The schedule therefore lives only in the CL config.yaml; no execution layer chain-configuration counterpart is needed, and EL gas limit flags retain their existing pre-Gloas and local-tooling meaning. This EIP does not change gas limit selection before Gloas.
Illustrative preference selection:
def effective_gas_limit_preference(
operator_preference: Optional[int],
existing_default: int,
epoch: Epoch,
config: Config,
) -> int:
scheduled = get_scheduled_gas_limit(epoch, config)
if scheduled is None:
return operator_preference if operator_preference is not None else existing_default
if operator_preference is None:
return scheduled
if operator_preference > scheduled:
log.warning(
f"configured gas limit {operator_preference} exceeds the recommended "
f"maximum of {scheduled} at epoch {epoch}"
)
return operator_preference
The realized network gas limit continues to move under the EIP-1559 ±1/1024 rule, so a scheduled increase plays out as a gradual, bounded ramp starting at the activation epoch rather than an instant step.
Keying the default on the duty's epoch rather than the release version decouples shipping a new gas limit from activating it. This directly resolves the large-increase dilemma described in the Motivation: clients can ship the schedule entry for a big raise arbitrarily early, and no node will begin voting toward it until the configured epoch. An entry can align with a hard fork when desired, but the mechanism itself is only an epoch-based client configuration.
The number the community coordinates on for an epoch is the number the network runs at and the number operators are asked not to exceed. A single dial means there is no second parameter to negotiate or get out of sync, and no untested operating region between a default and a higher ceiling. Operators who want to run below it can; running above it is possible (nothing in consensus prevents it) but happens against a clear warning, which is a much stronger signal than today's silently configurable free-for-all.
Post-Gloas, the CL is authoritative for the gas limit in practice: the validator preference drives registrations, builder bids, and payload construction. A parallel execution layer schedule would be redundant configuration that could only ever agree with or diverge from the CL's — and divergence is a new failure mode with no benefit. One schedule, in the layer that actually drives the value, is the minimal design. EL clients require no changes at all under this EIP.
An earlier draft of this EIP made the scheduled value a consensus-enforced maximum (and, before that, an exact-match requirement). This version is deliberately advisory:
Clamping a preference down to the scheduled value would be enforcement — just relocated from consensus into the client. Without a consensus rule behind it, that would be dishonest in both directions: it implies a network ceiling that does not actually exist (any proposer running a non-conforming client could still exceed it), and it silently overrides an explicit operator decision that produces perfectly valid blocks. It would also fragment behavior across clients, since only those that adopt the optional schedule would clamp. A prominent warning keeps the mechanism honest: the schedule shapes defaults, and exceeding the recommended maximum remains possible but becomes a deliberate, visible act instead of a silent misconfiguration.
EIP-7935 recommended a single default (60M) tied to Fusaka's activation. This EIP generalizes that one-off into a standing, machine-readable epoch schedule so future changes reuse the same mechanism instead of requiring a new EIP and a fresh round of client-default coordination.
No consensus rules change and no blocks become invalid. Pre-Gloas behavior and existing operator settings remain unchanged. For post-Gloas duties covered by an active schedule entry, unconfigured validators derive their gas limit preference from the schedule instead of a hardcoded constant, and configured values above the scheduled maximum produce a warning but are honored. CL clients that do not adopt the field, and all EL clients, are unaffected. Tooling that reads block.gas_limit is unaffected.
The ceiling is advisory. Nothing in consensus prevents a proposer from exceeding the scheduled value, so this EIP does not protect against a deliberately non-conforming actor. It does protect against the accidental paths — a default shipped early, a stale setting, an uncoordinated bump — which historically are how unintended gas limit movement happens. The ±1/1024 elasticity rule further rate-limits how fast any actor, conforming or not, can move the realized limit.
Herding on the schedule. If most validators follow the schedule, the network's gas limit becomes highly predictable, which is the goal. It also means an error in a scheduled value propagates widely; scheduled values should receive the same devnet and worst-case-block testing that gas limit increases receive today (as described in EIP-7935) before being added to a network's configuration.
Partial adoption. Because the field is optional, clients that do not support it keep their existing defaults, and their operators keep coordinating manually. The mechanism's coordination benefit is proportional to adoption; a mixed network is no worse than today, since non-supporting clients behave exactly as they do now.
Path to enforcement. If the community later wants a hard guarantee that the network cannot exceed a tested envelope, a future Standards Track Core EIP can promote this schedule's value to a consensus-enforced maximum without changing the configuration format.
Copyright and related rights waived via CC0.