Ethereum's Glamsterdam delay: a pre-fork checklist for smart contract teams

Ethereum's next big upgrade, Glamsterdam, has hit a security pause. On October 22, 2026, core developers called off its planned October 26 activation on the Hoodi test network after the audit firm ChainSecurity showed that two proposed gas changes could alter how existing smart contracts behave. ChainSecurity says it has already found 13 real-world examples and is working through responsible disclosure with the affected projects.

If you run a product with smart contracts on Ethereum mainnet, this matters even if you never touch protocol politics. Contracts that are safe today might not be safe after the fork. Here's what changed, why it can break working code, and a checklist your team can run before a new date is set.

What Glamsterdam is trying to do

Glamsterdam is a large upgrade. CoinDesk's coverage notes that it includes a new system for choosing block builders and changes intended to let the network handle larger blocks. It completed its activation on the Sepolia test network on October 6, and Hoodi was meant to be the next public rehearsal, along with a planned increase in that network's gas limit to 200 million. Both are now postponed, and no replacement date has been announced. Ethereum's mainnet date is also unconfirmed.

Two of the proposals at the centre of the delay are EIP-8037 and EIP-8038. According to an explainer published on Ethlabs, Ethereum's state, the data every node must store, grows by about 116 GB a year today. With the gas limit rising from 60 million to 200 million, that would extrapolate to about 387 GB a year. EIP-8037 and EIP-8038 aim to slow that growth by making it more expensive to create and access state when state is growing too fast.

Why a pricing change can break safe contracts

The problem is that EIP-8037 doesn't only change prices. It changes how gas behaves inside a transaction.

The old assumption: almost no gas left after an inner failure

When contract A calls contract B and B runs out of gas, today's rules leave A with only a small slice of gas to keep going. Ethereum forwards at most 63/64 of the remaining gas to the inner call, so roughly 1/64 stays behind. Some contracts quietly rely on that. Their error-handling code, for example "record that this attempt failed" or "disable further retries", needs more gas than that slice. So when the inner call fails from running out of gas, the error handler can't finish, and the whole transaction reverts. Nothing is recorded, and the user can try again.

The new behaviour: gas can come back

Under the proposed rules, gas spent creating certain state can be restored when those changes are undone. That means an inner call can run out of gas while the outer contract still has plenty left. Now the error handler that used to fail can complete. CoinDesk's summary of ChainSecurity's analysis says this could let a contract permanently record a failure that previously would have rolled back, which an attacker might use to block retries.

The opposite risk: valid operations failing

There is also a risk in the other direction. ChainSecurity calculated that creating a new storage slot could cost 110,020 gas when a separate allowance is used up, compared with 22,100 under today's rules. A contract that sends a fixed gas amount to a call, or a frontend that estimates gas with a tight margin, could see valid operations start failing.

ChainSecurity has demonstrated the mechanisms. CoinDesk notes it has not publicly established that a major production protocol is exploitable, and nothing suggests existing contracts are being exploited today, because the rules aren't live.

A second fix, for staking deposits

In a separate issue, CoinDesk reported on October 27 that developers merged a fix to the consensus specification for a Glamsterdam deposit rule. A researcher showed that, under the draft rules, an operator who registered as a block builder with a given public key could receive a staking service's validator deposit sent to the same key, and then withdraw it. The researcher described these as conditional code findings, not confirmed live exploits, and no losses were reported. The merged change keeps validator deposits with validators. Client teams still have to implement it.

The pattern is the same in both cases: protocol changes have second-order effects on code that already exists.

A pre-fork checklist for teams with contracts on mainnet

You don't need to follow every core developer call. You do need to know whether your contracts depend on gas behaviour the fork may change.

1. Find every place you catch a failed call

Search your contracts for try/catch, low-level call with checks on the returned success flag, and any pattern where a failed external call leads to a state change, such as marking an order failed, burning a nonce or pausing a feature. These are the paths most exposed to the "error handler now has gas" problem.

2. Look for fixed gas stipends and hard-coded gas limits

Search for calls that pass a specific gas amount, such as call{gas: X}, and for any logic that assumes a storage write costs a known amount. Under the higher state-creation cost, these could start failing on valid inputs.

3. Check relayers, keepers and account-abstraction flows

Bundlers, meta-transaction relayers and keeper bots often estimate gas, then add a margin. Make sure your margins aren't based on today's storage costs, and that a failed estimate leads to a clear error, not a silent skip.

4. Review upgradeability and who holds admin keys

If a contract needs a fix before the fork, you'll need a safe way to deploy it. Confirm who controls upgrades, that the multisig signers are reachable, and that your timelock gives users notice. Unrelated to Glamsterdam, a security advisory this month described suspected compromised admin keys at a liquid-staking project, with malicious upgrade contracts deployed. Admin key hygiene is part of being ready for any change.

5. Talk to your auditor now

If your contracts were audited, ask your auditor whether they are reviewing for EIP-8037 and EIP-8038 effects. If you're preparing for a new audit, add the fork changes to the scope.

6. Test against the fork rules when clients support them

Once client teams publish builds with the final Glamsterdam rules, run your test suite and key user flows on a local fork or a test network with those rules enabled. Pay special attention to the failure paths from step 1.

7. Watch the official channels

Follow the All Core Devs meeting notes and your client teams' release announcements for a new Hoodi date. A testnet date is your signal that mainnet scheduling is getting closer.

Practical takeaways

• Glamsterdam's Hoodi test was postponed after ChainSecurity showed that EIP-8037 and EIP-8038 can change how existing contracts behave. No new date has been set.
• The main risks are error handlers that now succeed when they used to revert, and valid operations that fail under higher storage costs.
• Audit your contracts for caught failures, fixed gas amounts and tight gas estimates.
• Make sure you can safely upgrade, and that admin keys are well protected.
• Re-test against the final rules as soon as client builds are available.

---

Running a product with smart contracts and not sure where this leaves you? Book a free technical assessment, and we'll help you map which contracts and services could be affected and what to check before the fork.