The most consequential question about Ethereum’s Glamsterdam upgrade is not whether average transaction fees will fall. It is whether the same deployed smart contract can follow a different execution path after gas is repriced. On October 22, 2026, Ethereum developers postponed the planned October 26 Hoodi testnet activation so they could investigate interactions between EIP-8037 and contracts already operating on mainnet. That decision makes compatibility risk a present engineering problem, not a theoretical objection to scaling [1]. Mainnet has no confirmed activation date, and no evidence cited here establishes a live mainnet exploit caused by these proposed rules.
The issue is subtle: Ethereum may execute unchanged contract bytecode while the amount of gas available after a failed external call changes. Contracts that equate a small gas remainder with an unsuccessful operation, or rely on a failure handler running out of gas itself, can behave differently. The Ethereum Foundation’s transaction replay work suggests most applications are unaffected, but the small vulnerable class matters disproportionately when contracts control transfers, bridge messages, vault withdrawals and liquidation workflows [2].
Why Was Glamsterdam’s Hoodi Activation Postponed?
The announced sequence was straightforward until the security review. Glamsterdam activated on Sepolia on October 6. The Ethereum Foundation subsequently scheduled a Hoodi test for October 26, alongside a proposed jump to a 200-million gas limit on that network. During All Core Developers Execution meeting #248, developers decided not to proceed. The Foundation’s October 22 notice says the Hoodi schedule, including the gas-limit increase, was removed and a replacement epoch had not yet been selected [1][3]. That is a testnet scheduling change, not a rollback of settled history or cancellation of Glamsterdam as a program.
Glamsterdam combines execution-layer changes called Amsterdam with consensus-layer work called Gloas. The headline scaling features include enshrined proposer-builder separation (ePBS), which changes how payload builders and validators coordinate, and block-level access lists under EIP-7928, which let clients identify and potentially parallelize account and storage work [3][4]. These infrastructure changes are not the same thing as EIP-8037’s state-gas reservoir. Analysts should resist treating “the upgrade” as a single gas-price tweak.
The Foundation’s August compatibility guidance classified historical-transaction replays into unchanged transactions, transactions that still succeed but differ, transactions fixed by raising the gas limit, and transactions that remain potentially broken after a substantial increase. It did not publish a credible count showing that every contract in the last category was exploitable. Some flagged outcomes concern service interruptions, not theft [2].
How Does Separate State Gas Change Contract Behavior?
Today developers often think of a transaction as carrying a single spendable gas budget. EIP-8037 would distinguish execution work from the cost of creating new persistent state. State creation first consumes a separate reservoir; execution gas remains visible through the EVM GAS opcode, returned to Solidity as `gasleft()`. The reservoir can be passed through contract calls and replenished when state changes are undone. EIP-8038 separately reprices state-access operations [5][6].
A simple storage example conveys the economic scale. A fresh cold slot costs 22,100 gas under the prior schedule discussed by ChainSecurity. Under the proposed model, a cold fresh-slot write involves 12,100 execution gas and 97,920 state gas, for 110,020 in the illustrated configuration. The total exceeds the earlier price by nearly fivefold, but execution gas alone can be lower if the reservoir covers the state charge [6]. That is why a check looking only at the amount returned by `gasleft()` can become misleading.
Suppose a parent contract calls a processor, and the processor fails due to an inadequate budget. The parent catches the error and writes a permanent `failed[id]` record. Under the old gas schedule, the remainder might not be enough to perform that write, causing the whole transaction to revert. Under the new dual accounting rules, the reservoir can pay the large state component, allowing the failure record to persist. A previously retryable operation may be marked permanently failed. This is a control-flow change, not proof that ETH has already been stolen.
ChainSecurity identifies a further hazard around frames that undo newly created state. Revert or exceptional halt can restore state-gas accounting, so gas available to an outer failure handler can differ from developers’ assumed worst case. The resulting failure is context dependent: what gas enters each nested frame, whether the reservoir was funded, and whether the fallback storage slot is new all matter [6]. Developers cannot diagnose the issue by looking at gas price in gwei alone.
Which Smart Contracts Are Most Exposed?
The sensitive patterns are not limited to one Solidity compiler version. They are designs that embed an execution-cost assumption into an invariant. Fixed 2,300-gas ETH transfer stipends can fail if the receiving contract needs more work; hardcoded call limits can become insufficient; checks that compare `gasleft()` before and after a call can misclassify out-of-gas events; and presigned deployment transactions cannot change their fixed gas cap after signing [2][5].
| Contract Pattern | Possible Post-Fork Difference | Developer Response |
| Fixed-gas value transfer | Recipient no longer completes | Test receiving contracts and fallback paths |
| Callback with low-gas guard | Failure is recorded, not reverted | Model the full nested call and reservoir |
| `gasleft()`-based access rule | Boundary changes with gas schedule | Replace resource-based assumptions |
| Hardcoded deployment transaction | Factory deployment can run out of gas | Regenerate where technically possible |
| Wallet or RPC gas estimator | Underestimation creates failed transactions | Update estimator and cache assumptions |
One category deserves special attention: applications that record an irrevocable failure, use-once nonce or missed execution window. If a relayer has permission to submit an intentionally underfunded request, a gas-dependent guard may let it consume a message or mark an instruction used without the intended asset transfer. That resembles insufficient-gas griefing. Whether an attacker can exploit it depends on permission controls and actual code, and may require no privileged key if a public relayer path exists [6].
The chart is a qualitative review checklist, not an empirical ranking or estimate of exploit incidence. Its purpose is to separate straightforward cost increases from invariants that can alter asset movement or retryability. An ERC-20 balance-transfer call that simply reverts on insufficient gas is operationally different from a vault that catches the revert and irreversibly modifies accounting.
Could Gas Repricing Cause Actual Losses?
Yes, but only through a demonstrated interaction between the new rules and the contract’s own logic. The chain does not spontaneously delete an ERC-20 balance because an opcode costs more gas. A more plausible sequence is a state machine accepting an incomplete action, a retry flag being consumed, or a keeper failing to execute a liquidation until collateral deteriorates. In an extreme integration, a wrongly committed bridge message might create a mismatch between recorded obligations and the token movement actually completed. These are potential mechanisms; they are not documented Glamsterdam incidents.
This distinction is familiar from unrelated contract vulnerabilities: an Ethereum-compatible implementation bug can cause a loss even when the base blockchain continues producing blocks. Dave Finances’ analysis of the Cosmos EVM flaw across six blockchains provides context on shared execution-layer dependencies; it does not imply that Cosmos and Glamsterdam share a defect.
Developers should distinguish three dimensions of loss. The first is direct execution cost, such as extra gas paid for state growth. The second is failed-transaction and opportunity cost, such as missed arbitrage or delayed settlement. The third is correctness risk: assets moving, claims being recorded or permissions changing contrary to the intended state machine. Only the third normally justifies describing a repricing event as a potential smart-contract security vulnerability.
What Does the New Gas Price Mean in Dollars?
A large increase in gas units does not necessarily imply a proportionate dollar fee change, because the market’s base fee adjusts to demand and capacity. As an illustrative calculation, 110,020 gas at 0.08 gwei corresponds to about 0.000008802 ETH before priority fees; 22,100 gas at the same rate is 0.000001768 ETH. If ETH were $3,000 (a deliberately hypothetical price), those amounts would be about $0.0264 and $0.0053. The absolute fee is small in this low-fee assumption, even though the ratio is large.
At a hypothetical 20 gwei, however, the 110,020-gas operation would be 0.0022004 ETH, or $6.60 at the same assumed ETH price. Neither scenario forecasts post-upgrade base fees or ETH prices. EIP-8037’s authors warn that creation-heavy applications may see higher fees while scaling eventually increases total throughput [5]. It is wrong to infer that every token swap becomes five times as expensive.
For a hypothetical protocol performing 80,000 new cold storage writes per day, an incremental 87,920 gas units per write would add roughly 7.03 billion gas units of gross metered work per day, assuming no offsetting optimization and comparing the full new-versus-old total. At a constant 1 gwei that represents 7.03 ETH daily. The assumption exaggerates uniformity: in practice state reuse, warmed slots, code patterns, parallel block accounting and fee changes would alter the result.
Why Does the Upgrade Still Matter for Scaling?
The case for repricing comes from node resource economics. EIP-8037 documents that persistent-state growth increased sharply after Ethereum’s gas limit rose from 30 million to 60 million. Its specification seeks to harmonize what the chain charges for additional state bytes, targeting sustainable growth as block limits increase. Expensive state creation is therefore partly intended to prevent subsidized permanent storage from overwhelming ordinary node operators [5].
The Ethereum Foundation’s roadmap for the longer-term Lean Ethereum overhaul places Glamsterdam within a series of changes meant to make the chain more scalable without simply asking everyone to run ever-larger hardware. A better block validation pipeline and more accurate resource pricing can coexist with short-run migration costs for application builders.
Enshrined proposer-builder separation also matters to transaction markets because validators, block builders and inclusion policies influence ordering and latency. That is adjacent to, but not synonymous with, the execution-cost risks explored in our sandwich attack analysis. No published evidence permits estimating future MEV revenue from the Hoodi delay alone.
How Should Developers Test Existing Contracts?
A practical workflow begins with inventory rather than emergency upgrades. Collect deployed addresses for vaults, routers, keepers, relay hubs, callbacks, factories and account-abstraction modules. Identify fixed gas parameters, use of `gasleft()`, low-level calls that capture `success`, and storage writes after external calls. Then replay representative successful and unsuccessful transaction sequences under old and proposed fork rules using up-to-date clients or the development environment identified by the Ethereum Foundation [2].
The critical assertion should be economic, not merely technical: if an action fails, should the original asset balance, nonce, withdrawal eligibility and retry flag be unchanged? Instrument storage diffs, event logs, token balances and traces. Fuzz the caller’s supplied gas and nested call depth; test with empty and already-created storage slots; inspect proxy upgrades and keeper interfaces separately. A test that only confirms the normal success path misses the precise case that motivated the postponement.
Next, remediate according to the failure class. A frontend gas-limit increase can repair ordinary out-of-gas transactions. A fixed-stipend fallback may require a contract change. A design using gas exhaustion as its sole protection against malicious relayer behavior needs a logic-level defense, such as explicit request state and verifiable completion. Immutable contracts with no upgrade path may require routing changes, a migration or a risk disclosure; the correct option depends on the underlying authority model.
Do Ethereum Rollups and Wallets Face the Same Risks?
A common source of confusion is the relationship between Ethereum mainnet and Ethereum-compatible rollups. An L2 may run familiar Solidity and EVM bytecode, but its transaction fee model, opcode pricing and upgrade schedule are not automatically identical to mainnet. EIP-8037 explicitly notes that presigned deterministic factories could fail to deploy on a new chain adopting the repricing before those factories exist, while preexisting deployments on Ethereum mainnet are not affected in the same way. Builders should therefore test the target chain’s rules and deployment history rather than assuming one mainnet result proves universal compatibility [5].
Rollups still interact with Ethereum for settlement, verification and data availability. Changes to L1 execution expenses can affect the cost of posting or finalizing batches even if the rollup never adopts the same state-gas schedule. This is an indirect economic channel rather than evidence that L2 contract execution will suddenly change at the Ethereum fork. A bridge or settlement contract deployed on L1 merits its own compatibility assessment, especially when an L2’s withdrawal completion depends on an L1 callback that might run out of gas.
Wallet and indexing infrastructure also require attention beyond the headline security research. EIP-7708 adds ETH transfer logs, and changes to access lists and transaction accounting can affect assumptions in event processors and gas-estimation software. An indexer may start receiving new protocol-level evidence of value movement without that implying an additional payment; dashboards that sum native transfers and related accounting records indiscriminately risk double-counting activity. Ethereum users need wallet software that follows the updated estimation rules, while validators require compatible execution and consensus clients. The upgrade is not simply something an application operator can handle by raising the frontend’s gas slider [3][5].
What Should ETH Holders Watch Before Mainnet Activation?
For most ETH holders, no wallet migration is justified by a testnet delay alone. Monitor the Foundation’s official activation notice, supported node releases, contract-team test results and independent security reports. For tokens held inside vaults or bridges, look for team-specific compatibility statements covering failure paths, not just reassuring claims that transfers worked on Sepolia.
A genuine safety milestone would be resolution of the EIP-8037 interaction, reproducible tests showing old and new failure invariants agree, and successful subsequent testnet activation. An adverse signal would be repeated postponements or reproducible failures in economically significant deployed contracts with no migration path. Until mainnet activation is scheduled, “Glamsterdam will break Ethereum” is an unsupported extrapolation; “the team has found material compatibility cases worth delaying for” is accurate.
Methodology and Limits
This analysis uses the Foundation’s October 22 postponement notice, its August repricing compatibility study, primary EIP specifications and ChainSecurity’s October 13 technical write-up. Gas arithmetic applies cited proposed values but ignores per-call incidental costs, transaction context and evolving code revisions. Illustrative dollar figures and scenario rankings are editorial models, not market predictions, on-chain exploit measurements or an investment recommendation. As of October 24, Hoodi has no replacement date and Ethereum mainnet has no confirmed Glamsterdam activation date.
Sources and Verification
1. Ethereum Foundation — Glamsterdam on Hoodi Postponed, Oct. 22, 2026 — superseding activation notice.
2. Ethereum Foundation — Glamsterdam Repricing Impact, Aug. 24, 2026 — contract replay and failure classes.
3. Ethereum Foundation — Hoodi Testnet Announcement, Oct. 16, 2026 — specifications and earlier schedule.
4. Ethereum Foundation — Sepolia Upgrade Announcement — upgrade components.
5. EIP-8037 — State Creation Gas Cost Increase — dual gas metering and state costs.
6. ChainSecurity — Glamsterdam: When Spent Gas Comes Back, Oct. 13 — documented failure-handler scenarios.
7. EIP-8038 — State Access Gas Cost Update — state-access repricing.
8. EIP-7928 — Block-Level Access Lists — block-level data access.
9. EIP-7732 — Enshrined Proposer-Builder Separation — consensus design.
10. EIP-7773 — Glamsterdam Network Upgrade — fork coordination and component tracking.
11. EIP-150 — Gas Cost Changes — call-forwarding mechanics.
12. Ethereum.org — Glamsterdam Roadmap — nonauthoritative update cadence versus dated Foundation notices.
13. CoinDesk — Developers Delay Hoodi, Oct. 23, 2026 — independent contextual reporting.
Johan Shamshad is a financial markets writer at Dave Finances covering cryptocurrencies, trading platforms, brokers, fintech, financial regulation, and developments across global markets. He previously worked at Gulf News, adding newsroom experience to his coverage of fast-moving financial and digital-asset markets.
His work focuses on identifying market-moving events, company developments, regulatory changes, product launches, and shifts in trading and financial infrastructure.
Johan contributes news and analysis designed to help readers understand not only what happened, but why a development matters and how it may affect the wider financial landscape. You can reach out to him via his social media accounts:
Linkedin: https://www.linkedin.com/in/johan-shamshad-742851262/
X: https://x.com/Yasmine_FX
Investing: https://www.investing.com/members/contributors/279781574