ACDT #94 · EIP-8037 refund excluded from Glamsterdam
AllCoreDevs - Testing #094 · 2026-08-31
Decided not to revive the self-destruct gas refund
Decided to exclude from Glamsterdam the EIP-8037 change that would revive state gas refunds for the create-then-self-destruct pattern on temporary contracts. The decision on the larger issue, whether to fix the cross-frame gas laundering bug, was deferred to the September 4 ACDC.
Why it matters
Services that use a pattern of creating a contract and destroying it immediately, such as deposit address sweeping, will not get state gas refunded in Glamsterdam, so their costs rise. Adopting the cross-frame bug fix would push the Sepolia fork from late September to late October, which could put the December mainnet target at risk.
Decisions
- Exclude 8037 refund: Decided not to include in Glamsterdam the change (EIPs PR #12249) that refunds state gas when a temporary contract is created and self-destructed in one transaction. The reasons are implementation complexity and the direction of deprecating self-destruct, and users of this pattern will pay state gas even though they do not grow state.
- Snap2 shadow fork: Decided to start the Snap2 test shadow fork on Sepolia first rather than mainnet, with the mainnet shadow fork to follow. This saves cost by layering the test onto the Sepolia shadow fork that is already planned.
Discussion
Should the self-destruct state gas refund be revived?
After the pattern of creating a contract and destroying it in the same transaction came to cost state gas without a refund under EIP-8037, a proposal resurfaced to revive the refund that was removed in April.
Outcome: Excluded from Glamsterdam 01:01:26
Cross-frame gas laundering bug: fixing it means a one-month delay
A spec bug was found where EIP-8037's invariant that regular gas cannot be converted into state gas breaks at frame boundaries. The fix is a consensus-breaking change, so it became tied to the fork schedule.
Does non-finality testing need heavy EL state?
Ahead of DevNet 9, the 1,000-node non-finality devnet launching tomorrow, cost and practicality clashed over whether ePBS validation needs large execution layer state.
Inclusion list P2P size limit: 8KB or 41KB?
Over the increase to the signed inclusion list P2P message size proposed by the absent Barnabas, the exact upper bound calculation and the worst-case propagation cost became the point of debate.
Glossary
- SFI: Scheduled for Inclusion: the status in which inclusion in the next fork is confirmed
- CFI: Considered for Inclusion: the status in which inclusion in the fork is under formal review
- PFI: Proposed for Inclusion: the status in which inclusion in the fork has been proposed and accepted as a candidate
- DFI: A state where inclusion was declined or the proposal was dropped from candidacy
- State gas: A separate gas account introduced by EIP-8037 that applies only to operations that grow state
- Shadow fork: A testnet that clones the state of the real network to try out forks in advance
- Inclusion lists (FOCIL): A transaction list mechanism in which validators force transactions into the next block
- ACDC: The AllCoreDevs Consensus call, focused on the consensus layer. It is held every Thursday