contracts-bedrock: remove SystemConfig batchInbox and setGasConfig

[mds1]

During U19, OPCMv2's reinit-everything path recomputed the SystemConfig batch inbox address via _chainIdToBatchInboxAddress (the new-chain scheme) instead of preserving the existing value, rotating the onchain batch inbox for all pre-OPCM chains (OP, Unichain, Mode, Metal, Zora). Nothing in the OP Stack reads it — derivation takes the batch inbox from the rollup config — so it was harmless, but it showed the onchain copy is a redundant source of truth that can silently drift. This PR removes the copy rather than fixing the reinit path. Closes #21614.

Two removals, both eliminating a duplicate write path instead of patching its symptom:

1. batchInbox() and the _batchInbox initializer param are gone, and initialize now clears the legacy slot so the stale value is zeroed for every chain at the next upgrade. OPContractsManagerV2._makeSystemConfigInitArgs no longer computes a batch inbox (the exact line that caused the U19 rotation), OPContractsManagerMigrator no longer reads and re-passes one, and the now-unused _chainIdToBatchInboxAddress helper is removed from OPContractsManagerUtilsCaller. OPContractsManagerUtils.chainIdToBatchInboxAddress stays — op-deployer still derives new-chain batch inboxes with the same convention.

2. setGasConfig and _setGasConfig are gone. setGasConfig could only write version-0 scalars (the require blocks a nonzero top byte) and did not update the basefeeScalar/blobbasefeeScalar mirrors. OPCMv2's _loadFullConfig reads those mirrors, not scalar(), so calling setGasConfig desynchronized them and the next upgrade silently reverted the operator's change — the same recompute-instead-of-preserve bug class as the batch inbox. op-node accepts version-0 scalars after Ecotone (CheckEcotoneL1SystemConfigScalar allows L1ScalarBedrock), so this was live rather than theoretical. Because _setGasConfigEcotone writes basefeeScalar, blobbasefeeScalar, and scalar atomically, removing the only other writer makes the mirrors agree with scalar by construction — no OPCM change needed.

overhead stays, now marked @custom:deprecated. setGasConfig was its only writer, so it is no longer writable, and _setGasConfigEcotone hardcodes uint256(0) in its place instead of re-emitting the stored value: op-node ignores the overhead after Ecotone, and the FEE_SCALARS payload has to stay 64 bytes, so the word cannot simply be dropped. Keeping the getter also means superchain-registry's L1 staging report, which calls overhead() on every chain, needs no change. Removing the variable outright is deliberately deferred to a future tech-debt pass rather than scope-creeping this one.

op-chain-ops/cmd/ecotone-scalar is deleted. It existed to compute the scalar argument for setGasConfig; the just ecotone-scalar recipe and the op-chain-ops README entry go with it. An old monorepo commit can be checked out if it is ever needed for historical purposes.

Semver 3.14.2 → 4.0.0, init version 3 → 4. OPCMv2 gets the dev-work patch bump to 7.2.4.

Test coverage

GPOParamsChange in op-e2e/actions/derivation/system_config_test.go had two halves, and only one of them used setGasConfig. Both survive, split in two.

The half that never touched the setter is now GPODefaultParams. It builds a Delta-only chain, sends one L2 transaction, and checks the pre-Ecotone L1 data fee end to end against the genesis gas config: L1GasPrice matches the L1 origin basefee, L1Fee == basefee * L1GasUsed * FeeScalar, L1Fee matches types.L1Cost(L1GasUsed - 2100, basefee, 2100, 1_000_000), and FeeScalar is 1. That exercises op-node deriving the fee parameters, the sequencer applying them through the L1 attributes transaction, and the values surfacing on the receipt.

The half that changed the gas config mid-chain is rebuilt on Ecotone as TestGPOParamsChangeEcotone, using setGasConfigEcotone instead of setGasConfig. It activates Ecotone as the latest fork, moves the basefee scalar 1_000_000 → 2_300_000 and the blobbasefee scalar 0 → 800_000, and checks the same three points in time the old test did: the derived scalars are unchanged in the last L2 block before the L1 origin with the update is adopted, they change in the exact block that adopts it, and they persist across a later L1 origin. At each point the receipt's L1 data fee is recomputed independently with opfees.L1CostEcotone from the fee parameters the receipt itself reports, and the receipt's L1BaseFeeScalar/L1BlobBaseFeeScalar are checked against the values written on L1. It is not parameterized over batch type, because Ecotone implies Delta and the singular-batch case is unreachable.

One assertion could not be carried over as-is: the old test compared the derived config against Genesis.SystemConfig wholesale. On an Ecotone chain that never holds, because initialize calls _setGasConfigEcotone, so the derived config is already on the versioned scalar encoding with a zeroed overhead while the genesis config still carries the pre-Ecotone encoding from the deploy config. The new test compares the scalars instead.

testFuzz_setGasConfigEcotone_succeeds now seeds the overhead slot with 2100 before calling the setter, so the event assertion proves the emitted zero is hardcoded rather than read from storage, and asserts overhead() still returns 2100 afterwards.

Why removal is safe

I audited the monorepo (Go, Rust, Solidity), superchain-registry, superchain-ops, monitorism, security-tools, op-txverify, ecosystem, specs, and docs, plus a GitHub code search across the org. batchInbox() has zero contract-level readers: op-node/cmd/batch_decoder uses rollupCfg.BatchInboxAddress, superchain-registry's staging.go uses the deploy config, and op-geth's superchain/types.go is a config struct field. No monitor reads startBlock() either — monitorism's withdrawals-v2 StartBlock is a --start.block CLI flag for backfill scanning.

No superchain-ops change needed

OPCMUpgradeV800 and OPCMUpgradeV700 both call sysCfg.batchInbox() while etching code at EOA-valued slots, but they do it from _templateSetup, which runs before the upgrade executes. The SystemConfig is still on the pre-V800 version at that point, so the getter is there, and neither template reads it afterwards. ethereum-optimism/superchain-ops#1492 was opened on the assumption that a version-tolerant read was needed and has been closed as unnecessary; its target file had also since been removed from main in ethereum-optimism/superchain-ops#1501.

Note for third parties

Reading batchInbox() or calling setGasConfig stops working at op-contracts v8.0.0. The batch inbox address remains in the superchain registry and in each chain's rollup config, which are the values the OP Stack actually uses. overhead() keeps working, but FEE_SCALARS ConfigUpdate events now carry a zero in its slot.

Companion PR: ethereum-optimism/specs#922.

[mintlify]

Preview deployment for your docs. Learn more about Mintlify Previews.

Project	Status	Preview	Updated (UTC)
Optimism-Docs	🟢 Ready	View Preview	Jul 8, 2026, 1:19 AM

[opgitgovernance]

This pr has been automatically marked as stale and will be closed in 5 days if no updates

[ajsutton]

LGTM.

[sebastianst]

🤖 GPT-5.6 says: Approved. The inline comments are non-blocking.