On November 6, the Ethereum Foundation issued a direct request to the smart contract developers and auditors behind deployed Ethereum projects: verify how planned specification changes for the network's next major upgrade, Glamsterdam, would affect their work. To support that check, the Foundation published a list of eight invariants that it has identified as breaking under the planned changes.

Invariants are properties that a protocol or application is expected to maintain under every valid execution — for example, guarantees about transaction validity, state handling, or execution outcomes that deployed contracts and their audits rely on. When a network's specification changes, invariants that previously held can break, potentially invalidating assumptions that production systems have been built on. That is the concern the Foundation's notification addresses, and the reason it asked external teams to review the eight flagged cases against their own codebases. Deployed Ethereum contract code does not change when the protocol does, so any guarantee a project relies on has to be re-checked by the team behind it rather than absorbed by the upgrade itself.

Glamsterdam is the codename for Ethereum's next major network upgrade, planned to follow Fusaka. Ethereum coordinates such upgrades through a public specification process in which protocol changes are discussed among client teams, researchers, and application developers before being incorporated into the upgrade's specifications. The upgrade continues the protocol's long-standing naming convention, taking its name from Amsterdam. Under this process, specification-level changes can affect execution and consensus rules, which in turn can affect the guarantees that smart contracts depend on. Because the notice covers planned specifications rather than rules already in force, the assessment is taking place ahead of the changes taking effect, while they are still moving through Ethereum's public process.

The Foundation's November 6 outreach targeted exactly this interface between protocol changes and deployed software. Developers and auditors were asked to assess, for their own deployments, which of the eight identified invariant breaks apply and what the practical consequences would be once the Glamsterdam specification changes take effect. As the upgrade moves forward, the concrete signals to watch are how those reviews map the eight flagged breaks onto deployed projects and how the Glamsterdam specifications continue to evolve through the public process.

This report was first published by COINOTAG on November 9, 2026: Ethereum Foundation Flags 8 Invariants That Break Under Glamsterdam. The complete article is available via Coinotag: full version.