Glamsterdam went live on Sepolia, then Hoodi was postponed: what Ethereum RPC users should do

Two dated events from the Ethereum Foundation blog, one fork that happened and one that did not, and a short list of checks for anyone who reads chain data or sets gas limits.

Endpoint and plans: Ethereum RPC endpoint.

Two things happened to Glamsterdam in October, and they point in opposite directions. On 2026-10-06 the upgrade activated on the Sepolia testnet. On 2026-10-22 the Ethereum Foundation postponed the Hoodi activation that was due four days later. If you only read headlines you saw "Glamsterdam is live on a testnet" and may have concluded that a mainnet date is close. The primary sources say something narrower, and the gap between the two is where an integration team should spend its time.

This is a news-desk post, so it is dated and sourced to what we fetched on 2026-11-01. Where a fact comes from a secondary outlet, we say so.

What happened, in order

The Foundation's testnet announcement scheduled Sepolia at epoch 353,024, slot 11,296,768, which is 2026-10-06 at 13:53:36 UTC. It listed the headline changes as enshrined proposer-builder separation (EIP-7732) and block-level access lists (EIP-7928), plus a block of gas and state repricing EIPs including EIP-8037 and EIP-8038. ForkLog reported the fork as activated on 2026-10-06 and said the target gas limit used in testing rose from about 60 million to 200 million. The Foundation post itself is a schedule, so the "it activated" part rests on that outlet and on the other reports we found, not on a Foundation after-action note.

On 2026-10-16 the Foundation announced Hoodi for 2026-10-26 at 17:42:48 UTC (epoch 132,352, slot 4,235,264), again with the gas limit raised to 200M at the activation epoch. Mainnet was explicitly not scheduled.

On 2026-10-22 an update replaced that announcement. The Foundation wrote that core developers chose to postpone "to allow for further investigation of interactions of EIP-8037 with mainnet smart contracts." The postponement removes the scheduled execution and consensus activations and the planned 200M gas limit on Hoodi, and the post adds that it "rolls back the configuration for a future upgrade; it does not revert Hoodi's chain history." The page states: "A new activation date has not been set."

The agenda for the execution call on the same day, 2026-10-22, is a useful cross-check. It lists "Security concerns about EIP-8037 and EIP-8038" raised in a public comment and a security firm's write-up, and it lists mainnet date candidates of December 1, 8 or 9 as a heads-up item. Read that carefully: it is an agenda line, written before the postponement, and not a decision. Nothing we found sets a mainnet date.

What the repricing means for RPC users

The part of Glamsterdam that touches ordinary application code is not proposer-builder separation. It is gas. The Foundation's repricing post of 2026-08-24 says EIP-8037 changes the cost of creating state (new accounts, new storage slots, deployed bytecode) and meters it separately, while EIP-8038 raises the cost of accessing state: it "increases the cost of accessing state (SSTORE, SLOAD, cold account access, EXTCODESIZE/EXTCODECOPY)." The schedule is derived from a target of roughly a 3x increase in base throughput. The post gives no new per-opcode numbers, and we are not going to guess them.

Two sentences from that post matter for anyone who runs infrastructure. First: "Both EIPs require eth_estimateGas and related handling to account for the new cost rules." Second, the warning that cached gas constants will underestimate and cause failed transactions. Replaying historical mainnet transactions under the new schedule, the Foundation found four outcomes: no change, succeeds with changes, fixable with a higher gas limit, and potentially broken. Most flagged cases were fixable with a higher limit and the large majority of contracts were unaffected. The potentially broken ones rely on hard-coded gas: fixed stipends such as the 2,300 gas of Solidity's transfer and send, hard-coded gas values in calls, logic that branches on gasleft(), and presigned transactions with fixed gas limits.

The headroom arithmetic is worth doing once, because the gas-limit number and the gas-cost number move together. Going from 60M to 200M is a factor of 3.33 on block capacity. The repricing is aimed at roughly 3x throughput. If costs rise with capacity, a transaction that touches new state can be charged materially more gas than it is today while the block still has room for it. That is the intended design, and it is also exactly how a hard-coded limit that was fine for years turns into an out-of-gas revert.

What to do before there is a date

The concrete step is a replay, not a code change. Our eth_estimateGas reference already tells you to treat the result as an upper bound from a simulated execution and to add a margin of 10 to 20 percent. That margin is a good alert threshold for this exercise:

  1. Take a day of your own mainnet transactions, grouped by the contract and function they call.
  2. Estimate each against mainnet state, and against a Glamsterdam test network once you can run against one. The Foundation points to the glam-devnet-8 network ("Platåberget") for testing fixes and to an affected-contracts search for L1 contracts.
  3. Record the ratio of the two estimates per function. A ratio above about 1.2 means the old margin no longer covers you. A ratio that is large only for functions that create state is the signature of EIP-8037.
  4. Grep your code and your contracts for fixed gas arguments, transfer/send, and gasleft() branches. These are the cases the Foundation names as potentially broken.
  5. If you sign transactions ahead of time, such as vault withdrawals or scheduled batches, find out which ones carry fixed gas limits.

None of this needs a Glamsterdam endpoint to start. Steps 1, 4 and 5 are mainnet-only. Read the gas estimate vs gas used explainer first if the distinction between the two is not already second nature.

Operators have a different list. The Hoodi post of 2026-10-22 told node and validator operators to check both execution and consensus clients for instructions that reflect the postponement before October 26, and to verify that release notes explicitly confirm the removal. The earlier announcement's client table is superseded. Application developers were told not to plan Hoodi testing around October 26, and mainnet users and ETH holders had nothing to do.

What we have and have not verified

We read the Foundation posts of 2026-08-24, 2026-09-17 (listed on the blog index as 2026-09-28), 2026-10-16 and 2026-10-22, and the call agendas on the public project-management repository. We did not run a Glamsterdam client or test against a Glamsterdam network. Our Ethereum limits page is where the mainnet request limits live. We have not measured how any of the repriced opcodes change estimates, so this post makes no claim about the size of the change, only about where to look.

When this is the wrong approach

A replay program is the wrong investment in three cases. If you only read data, with no signing and no gas estimation, Glamsterdam repricing does not touch you, and the monitoring work is finding out whether your block-by-block cost accounting assumes today's gas schedule. If you use account abstraction through a bundler, the bundler owns estimation and you should ask the vendor for its test plan rather than build your own. And if your transactions are all plain transfers of the native asset that create no state, the two repricing EIPs named above are not the ones that apply to you, so a day of replay will mostly tell you nothing. Other EIPs in the same fork touch gas, so read the full list before you rule yourself out.

It is also wrong to treat the October dates as a schedule. A testnet that forks and a testnet that is postponed in the same month tell you the work is not finished. The December candidates in the agenda are candidates. Plan the replay for when it suits you, and plan the production change for when there is an announced mainnet slot.

Sources

All fetched 2026-11-01.