The Ethereum Foundation called on smart contract developers and auditors on November 6, 2026, to examine eight gas-related assumptions that could fail under the planned Glamsterdam upgrade. The warning centers on EIP-8037 and EIP-8038, which change how Ethereum charges for creating and accessing blockchain state. Security researchers have identified projects whose existing contracts could behave unexpectedly under the proposed rules, prompting core developers to keep the Glamsterdam upgrade off the Hoodi testnet while the concerns are assessed.
This is a compatibility and security warning about a future protocol change, not evidence that Ethereum mainnet has already activated the new gas rules or that every smart contract is vulnerable. The latest development is the Foundation’s public audit request and its eight-part review checklist. The Hoodi postponement itself was announced on October 22.
Why Is the Ethereum Foundation Calling for Glamsterdam Audits?
In its November 6 research announcement, the Ethereum Foundation said ChainSecurity had identified projects that rely on assumptions, or invariants, that EIP-8037 and EIP-8038 would break. Those findings led All Core Developers to delay the relevant hard-fork process and not activate Glamsterdam on Hoodi until the issues are resolved. The team said work on the later Hegotá upgrade continues in parallel.
The Foundation is working with ChainSecurity and Dedaub while conducting internal audits. But even a coordinated security review cannot inspect every deployed application, its integrations and its off-chain services. The Foundation therefore published a public repository of eight broken gas invariants and asked other developers and auditors to examine their own systems. The repository says most findings identified so far concern INV-4 and INV-7: fixed gas budgets and gas reserves or stipends that may no longer be adequate.
The exact outcome remains open. Core developers want feedback to decide whether to modify EIP-8037 or EIP-8038, retain them as proposed or take other steps. The published request is not a statement that the issues have all been fixed, nor does it set a new activation date.
What Do EIP-8037 and EIP-8038 Change About Gas?
Gas measures the resources used by Ethereum transactions and smart contracts. The EIP-8037 specification would make creating new blockchain state more expensive, including new accounts, storage slots and deployed contract code. It also introduces separate accounting for state creation and execution, allowing some transactions to use a dedicated state-gas reservoir. The aim is to prevent database growth from becoming a bottleneck as Ethereum’s execution capacity increases.
EIP-8038 addresses a different cost: reading and updating existing state. It increases selected account-access and write charges to reflect the work required by a larger database. Not every operation increases in price; the proposal leaves some warm and cold storage-access constants unchanged. The combined changes nevertheless affect the gas budgets on which certain contracts and supporting services rely.
The Foundation’s auditor repository gives a concrete illustration using its pinned Amsterdam test specification: a cold write that creates a new storage slot rises from 22,100 gas under Osaka to 110,020 total gas under the tested Amsterdam schedule. The latter combines 2,100 for access, 10,000 for writing and 97,920 of state-creation gas. A warm change to an existing slot rises from 2,900 to 10,100. These are specification-based comparisons, not estimates of dollar transaction fees, and the values could change if developers revise the proposals.
One crucial distinction is how the bill is paid. Under the proposed model, a transaction gas limit above 16,777,216 can create a separate state-gas reservoir; state creation draws on that pool before using normal execution gas. Below that threshold, state charges come from the gas reported by gasleft(). In other words, a larger total gas charge does not always mean a caller needs the same amount of immediately available execution gas.
Which Eight Glamsterdam Gas Assumptions Could Break?
Ethereum’s official auditor checklist distinguishes price-related problems from changes in accounting. The summary below reflects the project’s INV-1 through INV-8 categories; the consequences depend on a contract’s actual code and transaction conditions.
| Invariant | Assumption to review | Potential failure |
|---|---|---|
| INV-1 | An out-of-gas subcall makes the whole operation fail | With a state-gas reservoir, the caller may still have enough gas to permanently record the failed attempt. |
| INV-2 | Clearing newly created storage cannot immediately restore gas | A storage reset may refill gas during execution, affecting failure-handling logic. |
| INV-3 | Gas consumed by a reverting call stays spent | Restored state gas can change how much work the calling contract can do after a revert. |
| INV-4 | A fixed gas budget remains sufficient | Deployments, new balances and other state operations may run out of gas at old limits. |
| INV-5 | gasleft() always decreases |
Gas-based billing or refund calculations can become unreliable when gas is restored. |
| INV-6 | Gas retained after a failed subcall cannot fund further work | A failure handler may complete and mark an item final rather than reverting. |
| INV-7 | Existing reserves and transfer stipends cover required writes | Fixed reserves, relayer allowances or 2,300-gas stipends may be insufficient. |
| INV-8 | A mined EIP-7702 delegation must have taken effect | A delegation reverted for insufficient gas may leave a signed authorization reusable. |
The list is a security-review framework, not a claim that every contract uses all eight patterns. The repository reports that the most common findings so far involve INV-4 and INV-7. Teams should prioritize those patterns without overlooking the less obvious accounting cases.
Why Can an Out-of-Gas Failure Become a Smart Contract Risk?
Consider a contract that calls another service and, if the call fails, writes a permanent marker saying the task was processed. That design may assume an underfunded call also leaves too little gas to write the marker, forcing the entire transaction to revert and preserving the opportunity to retry. ChainSecurity’s technical analysis explains why that assumption can fail when state-creation charges move between gas pools or are refunded during execution.
Under certain conditions, the inner call can run out of gas while the outer contract still has enough execution gas and state-gas credit to finish its failure handler. The result can be more dangerous than an ordinary reverted transaction: the contract may treat an uncompleted action as permanently handled. That could matter to batch processors, claim systems, cross-contract settlement flows and any application that disables retries after a failed external call. Those are examples of code patterns to investigate, not assertions that specific named protocols have lost funds.
Another issue arises when a contract charges a user by subtracting two gasleft() readings. If state-gas accounting restores gas between the measurements, the difference can misrepresent the actual work. Similarly, a relayer or automation service with a signed, hard-coded gas limit might deliver less gas than a post-upgrade operation requires, even though it worked before. A simple increase in the transaction’s outer gas limit will not necessarily repair a fixed allowance embedded inside a contract or signed message.
The EIP-7702 delegation case deserves separate review by wallet developers. The Foundation’s checklist warns that if a delegation runs out of gas and rolls back while its transaction is still mined, the signed authorization may remain reusable. Wallet setup functions and off-chain confirmation logic should not assume that inclusion of the transaction alone proves the delegation succeeded. The proper response depends on the implementation and should be tested against the relevant failure path.
What Should Ethereum Developers and Auditors Check First?
Start with the deployed contracts and execution paths that can permanently change state after an external call fails. Then inspect the infrastructure around them: wallets, relayers, automation bots, transaction signers and backend systems that estimate gas or interpret receipts. The Foundation expressly warns that off-chain components may be affected as well.
- Find fixed values: Search for hard-coded gas limits, low-level calls that pass a fixed budget, fixed forwarding overhead, 2,300-gas stipends and signed payloads with nonadjustable gas assumptions.
- Review failed-call handling: Check whether a failed call can mark a task complete, consume a nonce, finalize a claim or suppress retries. Do not infer the reason for a failure solely from remaining gas.
- Audit gas accounting: Identify reliance on
gasleft()differences, same-transaction storage creation and clearing, or expected gas behavior across reverted calls. - Examine wallet authorization flows: For EIP-7702 integrations, verify that setup and delegation actually took effect instead of assuming transaction inclusion is sufficient.
- Reproduce behavior under both schedules: Use supported Glamsterdam test environments and current implementation rules to compare success, revert, storage writes and retryability with existing behavior.
- Document and report real impact: Record the affected code, invariant, failure conditions and potential fix; coordinate sensitive findings responsibly before broad disclosure.
The Foundation’s repository offers instructions for AI-assisted code searches, but an automated match is a starting point, not proof of exploitability or proof that a repair is correct. The earlier Ethereum Foundation repricing guide reported that most historical transactions were unaffected and many flagged failures could be addressed with larger gas limits. The November security review targets the harder cases in which the assumptions behind an application may need more than a parameter adjustment.
Developers who find an affected project are asked to contact glamsterdam@ethereum.org with enough technical detail to help validate the issue. The checklist requests private email reports rather than public issue disclosures so teams have an opportunity to address vulnerabilities before they are broadly exposed.
Is Glamsterdam Delayed, and When Will Ethereum Mainnet Upgrade?
The chronology matters. Glamsterdam activated on the Sepolia testnet on October 6, 2026. On October 22, Ethereum developers postponed the planned October 26 Hoodi activation to investigate interactions between EIP-8037 and existing contracts. The revised Hoodi schedule has no replacement activation time. The November 6 announcement adds the public checklist and an explicit request for audit findings; it does not represent a second newly canceled October event.
As of the Foundation’s November 6 update, no confirmed Glamsterdam mainnet activation date has been announced. Core developers have not declared the entire upgrade abandoned, and work on Hegotá continues. The extent of the application-layer risk and any resulting specification amendments remain questions for the next development discussions.
Ethereum users do not need to migrate ETH or connect a wallet to an unfamiliar site because of this announcement. The identified concerns relate to how particular code paths might behave if the proposed changes are activated. A request to share seed phrases or approve transactions in the name of a Glamsterdam security upgrade should not be treated as an official requirement.
What Does the Glamsterdam Audit Request Mean for Ethereum?
Glamsterdam’s gas repricing is intended to make Ethereum’s larger execution capacity more sustainable by matching resource charges more closely to storage and database work. The security review shows why such changes must be evaluated against deployed applications, not only against theoretical opcode costs. Even when the underlying EVM upgrade behaves as specified, application code may have assumed that certain gas balances, failure paths or prices would never change.
For developers, the immediate priority is to identify assumptions, replay sensitive paths and preserve recovery options when calls fail. For node and validator operators, the relevant activation guidance must come from a new official testnet or mainnet announcement, not the superseded Hoodi timetable. For ordinary users, the published evidence supports heightened code-review diligence, not a claim that Ethereum mainnet is already compromised.
The bottom line: On November 6, the Ethereum Foundation made Glamsterdam’s gas-compatibility issue a public audit effort centered on eight documented invariants. EIP-8037 and EIP-8038 could improve how Ethereum prices state creation and access, but they also change conditions relied upon by some smart contracts. Hoodi remains postponed while developers assess those risks, and a final mainnet timetable has not been announced.