Ethereum’s EIP-8488 Draft Would Split Gas Schedules by Contract

EIP-8488 remains an open Ethereum improvement proposal, and its activation would place newly deployed smart contracts on a separate V2 gas schedule while keeping existing contracts on the legacy schedule.

The draft does not change Ethereum’s rules today. It proposes a future activation designed to allow gas costs to be repriced for new contracts without altering the pricing terms of contracts already deployed.

The activation boundary

The dividing line would be deployment timing relative to activation. Existing contracts would retain their legacy gas schedule. Contracts deployed after activation would use a V2 opcode set with prices defined by EIP-8037 and EIP-8038.

The proposal states:

“After activation, newly deployed contracts would use a V2 opcode set priced under EIP-8037 and EIP-8038.”

This separation would let Ethereum revise gas pricing for future deployments while preserving the gas-cost assumptions of contracts already deployed. A repricing would apply to the relevant schedule without automatically changing the schedule for existing contracts.

Restricted opcodes and version checks

Within the V2 opcode set, the draft excludes GAS and GASLIMIT. The operational consequence is direct:

• A new V2 deployment that includes GAS would revert.
• A new V2 deployment that includes GASLIMIT would revert.

Those failures would occur at deployment rather than leave a contract running with unsupported instructions. Developers would have to remove or replace the excluded opcodes in V2 deployments, while legacy contracts would continue to operate under their existing schedule.

The draft also introduces DELEGATECALL_V2, a versioned delegated-call opcode. It would fail immediately if the target contract’s code_version is below 2. This creates an explicit compatibility condition for delegated execution: a V2 call could not proceed against a target marked below version 2.

The failure is immediate, according to the proposal, so a call to an incompatible target would stop before carrying out the delegated operation.

What does this change for developers and operators?

For developers, EIP-8488 changes planning for new deployments. A project deploying after activation would need to account for V2 gas pricing under EIP-8037 and EIP-8038, exclude GAS and GASLIMIT, and check the code_version of every target it expects to reach through DELEGATECALL_V2.

For operators, the proposal preserves the gas schedule of existing deployments. It also creates a distinction between legacy contracts and contracts deployed under V2, giving maintainers room to adjust gas costs for new code without revising the schedule attached to older deployments.

The relevant distinction is therefore which contracts a repricing would affect: under the draft, deployment timing determines the schedule, while the target’s code_version determines whether DELEGATECALL_V2 can proceed.

The remaining gates

EIP-8488 remains open for review. The draft summary specifies no activation date, and the proposal has not changed Ethereum’s rules. Adoption and implementation would still need to occur before the V2 opcode set or the separate schedule became operative.

The next milestone is review and adoption, because only activation would make the two-schedule structure operative for new contracts on Ethereum.