News analysis ·

Glamsterdam reaches Hoodi: what the Ethereum upgrade changes

Glamsterdam is set for the Hoodi testnet on October 26. We explain ePBS, block access lists, the gas repricing and what node operators and developers must check.

Linocut of a crane lowering a sealed red crate into an empty stone block frame in a chain of blocks, an hourglass standing beside it

Glamsterdam, the next Ethereum network upgrade, now has a date on a second test network. The Ethereum Foundation scheduled it for the Hoodi testnet on October 26, 2026, 17:42:48 UTC, after it went live on Sepolia on October 6. This article looks past the date at what the upgrade rewires inside a block, and at the quieter gas changes that could catch smart contracts off guard.

The change in one paragraph

Glamsterdam is two forks shipped together: Amsterdam on the execution layer, where transactions run, and Gloas on the consensus layer, where validators agree on blocks. Its two headline features are enshrined proposer-builder separation, known as ePBS, and block-level access lists. Both change how a block is built and checked, and the Ethereum Foundation frames them as groundwork for more throughput on layer 1. Alongside them comes a repricing of gas, the fee unit that measures how much work an operation costs the network. On Hoodi the gas limit, the cap on total work per block, rises to 200M at the activation epoch, the same ceiling Sepolia already uses.

Under the hood: who builds, who checks, what gets read

Today, the validator chosen to propose a block usually buys a ready-made block from a specialised builder, and the deal runs through trusted middleware that sits outside the protocol. EIP-7732 pulls that arrangement into Ethereum's own rules.

  • Commit, then reveal. The proposer puts a builder's commitment into the block. The builder reveals the actual payload afterwards, and the protocol itself pays the proposer.
  • Split validation. Consensus checks and execution checks are separated, which gives validators more time to verify the payload.
  • A timeliness committee. A payload timeliness committee attests whether the builder's payload and its blob data showed up on time.
  • Access lists in every block. EIP-7928 makes each block carry a list of the accounts and storage slots it touched, plus the state changes after each transaction.
  • Repriced state. EIP-8037 raises the cost of creating new state and meters it separately; EIP-8038 updates the cost of reading and touching existing state.

The access lists matter because a client no longer has to discover, one transaction at a time, which parts of state a block needs. With the list in hand, it can read from disk, validate transactions and compute state roots in parallel. That is the practical link between a bookkeeping change and the higher throughput the Foundation is aiming for.

Why the gas repricing is the part to test first

For application teams, the gas changes are the more immediate thing to test. Besides state creation and state access, the base charge every transaction pays changes, as do the prices for calldata and access lists and the way a block tallies its gas. A contract that worked yesterday can behave differently once the same operation costs a different amount.

The Ethereum Foundation names the patterns most exposed: code that hardcodes a gas limit, passes a fixed stipend, or makes assumptions about how much gas is left in a call. A simple way to read that warning: any line of code that passes a fixed amount of gas to another call is betting on today's prices. If the callee's work becomes more expensive, the call can run out of gas and fail, even though nothing in the contract itself changed. The Foundation points developers to a repricing impact guide for finding affected contracts, and Hoodi is where that testing can happen on a second public network.

Who is affected

Ethereum upgrades are opt-in. Client developers coordinate the change, and validators and non-staking nodes decide to run the new software. Any node still running old software drops off the upgraded chain once activation passes.

Node operators on Hoodi need to update both their execution and consensus clients before the October 26, 2026 activation. Validators must update both the beacon node and the validator client. The Foundation says to use only releases whose notes explicitly confirm Hoodi Glamsterdam support.

Smaller items touch developers and stakers too: logs for plain ETH transfers, an opcode that returns the slot number, a bigger contract size cap, a factory contract with deterministic addresses and new stack instructions. On the consensus side, slashed validators can no longer propose, and exit and consolidation churn goes up. EIP-7773 tracks the full list.

When is the Ethereum upgrade on mainnet?

There is no mainnet date yet. Client teams will choose it, and a separate announcement will set it. The Ethereum Foundation was direct about the scope of this notice: "This announcement covers Hoodi; it does not schedule a mainnet upgrade." Nothing needs to be done on mainnet because of it.

In the meantime, the Ethereum Bug Bounty Program covers the Glamsterdam specifications and EIPs, and client builds become eligible once they appear in the release tables. Those tables will fill in as compatible versions are confirmed.

Sources

AI wrote this summary from the primary documents and reports cited above. It went live automatically after checks that figures match those sources and nothing is copied; there was no human review. It explains a protocol or rule change and is not investment advice.

← All posts