Should we accept L1 gas repricing repeatedly breaking L2 stacks and immutable contracts?
Protocol design · 2 participants · 3 quotes · 2026-10-26 ~ 2026-10-26
donnoh_eth of L2BEAT said the EIP-8037 repricing breaks most OP Stack chains again, expressing frustration that L1 keeps breaking the stacks above it. The EF's nero_eth answered that this is not about accepting breakage but a trade-off, where the sweet spot lies between the flexibility to reprice for future demand and the certainty that the foundation will not change.
Background
EIP-8037 (increase in state creation gas costs) and EIP-8038 (update to state access gas costs) are Glamsterdam core EIPs proposed by Maria Silva and others, and they recalculate the gas costs of SSTORE, account creation, code deployment, and similar operations to curb state growth. This repricing lets gas already spent be returned mid-transaction so that gasleft() can increase, which breaks the invariants of existing contracts that hardcode forwarded gas or measure consumption by the gas difference before and after a call. Audits by ChainSecurity and Dedaub found that many contracts, including OP Stack, are affected, and core developers are postponing the Hoodi testnet fork while they analyze the scope of impact. EIP-8037 and EIP-8038 are both in Last Call.
Why it matters
As Fusaka and now this repricing confirm that L2 stacks pay the cost of L1 repricing first, coordinating the interests of L1 and L2 has become a point of contention. Where to set the sweet spot between flexibility and certainty determines both how well the promise about deployed code is kept and how aggressive future state growth curbing policy will be.
Resolution
At ACDE #248 (2026-10-22), the Hoodi Glamsterdam hard fork was canceled indefinitely, and at ACDT #102 (2026-10-26), it was decided to postpone the Hoodi fork by at least two weeks while awaiting the ChainSecurity and Dedaub audit results, with the default path being that affected contracts fix themselves and spec changes kept as a last resort.
Key points
- Who should bear the cost when L1 breaks deployed contracts and L2 stacks?
- Where is the sweet spot between repricing flexibility to meet future demand and the guarantee that the foundation will not change?
- How can repeated breakage of L2 fraud proof systems be prevented, following the tx gas limit conflict during Fusaka?
Against — It is a problem that L1 keeps breaking its own stack
donnoh.gwei 💗
- Most OP Stack chains are broken again by EIP-8037. They were already broken once during Fusaka, when the transaction gas limit conflicted with fraud proof systems.
- L1 keeps breaking your things, and if you are a developer or an advocate of immutable contracts, it is bound to be frustrating.
Neutral — It is a trade-off, not an argument for accepting breakage
Toni Wahrstätter ⟠
- I am not arguing that we should accept breaking things. This is a trade-off, and the sweet spot lies somewhere between being flexible enough to adapt to future demand (for example, repricing) and providing certainty that the foundation will not change beneath your feet.
- EIP-8037 lets gas already spent be returned mid-tx so that gasleft() can increase, which breaks assumptions of existing contracts, for example by making a gas counter underflow and revert, or by running paths that should be unreachable so that the tx appears to have succeeded.