EIP-8261 Gas limit schedule
No call decision · Fees & gas · EIP status Last Call · created 2026-05-11
Recommends putting an epoch-based gas limit schedule in the consensus layer config file, so that validators' default gas limit and recommended maximum change automatically at set times. It does not change consensus rules.
Why it is needed
Today the default block gas limit is tied to client releases. A new default turns on not at a time set by the network but at the moment an operator updates the node. This creates trouble when trying to raise the limit substantially. If a release with the new default ships before the activation time, nodes that update early start voting to raise the limit right away, before the network has agreed it is safe. Conversely, shipping a release right after activation and asking all operators to update quickly is cumbersome and slow. Creating a temporary flag for every increase shifts the coordination burden onto individual operators. On top of that, there is no single place that states the gas limit the network should run, so raising the limit today requires months of social coordination, with every client team shipping a new default or many operators changing their settings. EIP-7935 showed that coordinating default recommendations at a set epoch in Fusaka works, and this EIP generalizes that into a reusable schedule.
What changes
Today
- The default gas limit is hardcoded in client releases, so the new value turns on the moment an operator updates the node
- A large increase requires months of social coordination across every client team's release and operator updates
- There is no single place that states the gas limit the network is targeting
- Setting a value higher than the recommendation is applied silently, with no warning
After EIP-8261
- Write the recommended gas limit for each epoch in advance in the GAS_LIMIT_SCHEDULE field of the consensus layer config.yaml
- Even if a release ships months early, the switch to the new value happens only at the set epoch, so nodes that update early do not vote ahead of time
- A running node automatically changes its preferred value at the first slot of that epoch, without a restart or an additional release
- If a configured value exceeds the recommended maximum, a warning log is emitted, so running above it becomes an intentional and visible decision
Who is affected
- Validators and node operators: Without separate configuration, the value in the schedule becomes the default gas limit. You can keep using any value you want, and only values above the recommended maximum are applied with a warning.
- Consensus layer client teams: It is an optional field, so each team can adopt it independently. Instead of reading it once at startup, they need logic that looks up the schedule by epoch on every duty.
- Builders and relays: While a schedule entry is active, they must create and prefer bids whose gas limit does not exceed the recommendation for that slot.
- Execution layer client teams: No change is needed. The existing gas limit flag keeps its meaning for pre-Gloas use and local tooling.
In depth
GAS_LIMIT_SCHEDULE field structure
The GAS_LIMIT_SCHEDULE field MAY be added to the consensus layer config.yaml. Each entry consists of two uint64 values, EPOCH and GAS_LIMIT, and GAS_LIMIT has the same type as ExecutionPayload.gas_limit in the consensus spec. The format is modeled directly on the BLOB_SCHEDULE mechanism of EIP-7892. The field is optional, so clients that do not support it ignore it, following the usual convention for unknown config keys. Clients that do support it MUST ignore the schedule for duties before GLOAS_FORK_EPOCH. The get_scheduled_gas_limit function returns the value of the entry with the largest EPOCH at or below the given epoch, and returns None before Gloas or when no entry is active. Entries may coincide with protocol upgrades, but the schedule itself neither creates nor requires a fork.
One value serves as both the default and the recommended maximum
The active schedule value plays two roles. Without an operator setting, clients SHOULD use that value as their gas limit preference, and SHOULD NOT keep a separate per-release default for epochs the schedule covers. If an operator setting exceeds the schedule value, there is no way to enforce the limit, so the client respects the setting but MUST log a clear warning such as configured gas limit 100000000 exceeds the recommended maximum of 90000000 at epoch 540000. A value below the schedule behaves as it does today. Builders SHOULD make bids that do not exceed the schedule value for the slot, and relays SHOULD prefer such bids. The default and the cap are tied to a single value because there is no second parameter to negotiate separately or let drift apart, and no unvalidated operating range appears between the default and the cap.
Epoch-based switching logic
Today, the default gas limit is read once at startup or when a validator registration is created, and then fixed. Under this EIP, the schedule value SHOULD be looked up per duty, based on the epoch of the slot being proposed or registered, and clients MUST NOT use wall-clock time or a value cached at startup. A running node then changes its preference at the first slot of the configured epoch, with no restart, follow-up release, or operator action. Validator registrations are reissued periodically, so once a duty passes the activation epoch it moves to the new value naturally. Because the schedule is tied to an epoch, a release shipped months before activation keeps using the existing value until that epoch and then switches automatically, which lets a large increase be rolled out safely in advance.
Why the schedule lives only in the consensus layer
From Gloas (EIP-7732) onward, the gas limit a block aims for is set on the validator side of the builder flow, that is, through the validator registration and payload bid path, and execution layer configuration plays no part. So the schedule is placed only in the consensus layer config.yaml, and no corresponding setting is created in the execution layer. A parallel schedule in the execution layer would be a redundant setting that can only match or disagree with the consensus layer value, and a disagreement would be a new failure mode with no benefit. Placing a single schedule in the layer that actually moves the value is the minimal design. Execution layer clients need no changes for this EIP, and the existing gas limit flags keep their meaning for pre-Gloas use and local tooling. The way the gas limit is chosen before Gloas is also left unchanged.
Why this is a recommendation and not a consensus rule
An early draft made the schedule value a consensus-enforced maximum (and before that, a value that had to match exactly), but this version deliberately stays a recommendation. A recommendation needs neither a fork nor an Engine API change, so consensus layer teams can adopt it independently and gradually. The choice of gas limit ultimately remains with the proposer, so validator sovereignty is preserved, and what this EIP changes is the default and social convention. Early voting and consecutive release problems are default management problems, and defaults are client behavior, so a recommendation is enough to solve them. A clamp that cuts an excess setting down to the schedule value was also ruled out. Without a consensus rule it would make a network cap appear to exist when none does, silently override the explicit decision of an operator who is producing valid blocks, and split behavior because only adopting clients would clamp. Later, if the community wants it, a separate Standards Track Core EIP can raise the same schedule value to a consensus-enforced maximum without changing the config format.
Security considerations
Because the cap is only a recommendation, it cannot stop a proposer who deliberately exceeds the schedule value. What it does prevent are the accidental paths that have historically caused unintended gas limit changes: prematurely shipped defaults, stale configuration, and uncoordinated increases. The ±1/1024 elasticity rule further limits how fast anyone can move the actual limit. If most validators follow the schedule, the network gas limit becomes very predictable. That is the goal, but it also means an error in a schedule value spreads widely, so values put in the schedule should go through devnet and worst-case block testing like that described in EIP-7935. Because the field is optional, clients that do not adopt it keep the existing default and their operators keep coordinating manually as they do now. A mixed network is no worse than today, and the coordination benefit scales with the adoption rate.
Status and call decisions
This EIP is of type Informational, its status is Last Call, and the deadline is 2026-11-01. Consensus rules and block validity do not change at all, and the EIP-1559 ±1/1024 rule and the minimum of 5000 remain the only gas limit validity rules. The 08.13 ACDE #243 call confirmed that EIP-8261, the in-client gas limit schedule, proceeds as an optional parameter of the consensus layer configuration. This means a schedule that raises the gas limit in stages after a fork can be put in place in advance.