Glamsterdam explained: what Ethereum’s next upgrade means for institutional stakers

Glamsterdam is Ethereum’s next hard fork after Fusaka. It changes how blocks are built, proposed, validated, and spread across the network.

Two changes lead it. Enshrined proposer-builder separation (ePBS, EIP-7732) moves the handoff between block builders and validators into the protocol. That handoff has run through off-protocol software since the Merge in 2022. Block-level access lists (BALs, EIP-7928) give Ethereum the map it needs to process transactions in parallel.

Together, they change the validator’s job and set up the next round of gas limit increases.

Glamsterdam went live on the Sepolia testnet on October 6, 2026. Hoodi follows on October 26. No mainnet date is set, per the EF Hoodi announcement. Here’s what’s shipping, where the schedule stands, and what you should do now.

What the name tells you about scope

Glamsterdam combines two upgrades. Gloas is the consensus layer upgrade, named after a star. Amsterdam is the execution layer upgrade, named after a Devconnect host city (EF).

ePBS needs consensus changes. BALs need execution changes. That’s why this fork touches both layers in a big way.

EIP-7773 tracks the full list of changes. ethereum.org describes the scope as frozen, though it can still change before mainnet while the meta EIP remains in review.

Where the schedule stands

ethereum.org expects mainnet in Q4 2026. The Ethereum Foundation says the mainnet date has not been decided and will be announced in a separate post, after client teams review the Hoodi results.

• Platåberget: a public Glamsterdam testnet that opened in August 2026, with open validator and builder deposits.
• Sepolia: live since October 6, 2026, at 13:53:36 UTC. Its gas limit moved to 200M at the fork (EF).
• Hoodi: scheduled for epoch 132,352 on October 26, 2026, at 17:42:48 UTC. Hoodi’s gas limit rises to 200M at the same epoch (EF).
• Mainnet: to be decided.

Node operators must update both execution and consensus clients before each activation. The EF’s Hoodi announcement lists the client versions that support the fork, and the table is still being filled in. Only run releases whose notes confirm Glamsterdam support.

One lesson from Sepolia: the EF’s Sepolia announcement noted that Prysm 7.2.0 and Teku 26.9.1 defaulted to a 60M gas limit after the fork unless operators set 200M themselves. Prysm shipped 7.2.1 the day before activation to raise its default (CoinDesk). Check your client’s release notes for the gas limit it targets by default.

The EIPs at a glance

Ethereum sorts proposals for each upgrade into three buckets: Scheduled for Inclusion (SFI), Considered for Inclusion (CFI), and Declined for Inclusion (DFI). Glamsterdam has 18 scheduled EIPs, per EIP-7773 and the EF’s Hoodi announcement.

EIP-7773 lists supporting networking and informational EIPs: eth/70 partial block receipt lists (EIP-7975), eth/71 block access list exchange (EIP-8159), eth/72 sparse blobpool (EIP-8070), cell-level deltas for data column broadcast (EIP-8136), snap/2 BAL-based state healing (EIP-8189), compute gas cost analysis (EIP-7904), and the gas limit schedule (EIP-8261).

ePBS: block building moves into the protocol

What it solves

Today, block building sits outside the core protocol. Proposers and builders hand off through trusted relays and sidecar software. Three problems follow.

• A tight hot path. Validators must receive a full block, run consensus and execution checks, and attest inside a window of about 2 seconds (ethereum.org). That limits how much data the network can move as blocks and blob counts grow.
• Relay dependence. Proposers rely on a small set of relays to deliver payloads. A relay outage, a censorship policy, or a bad bid becomes the validator’s operational problem.
• Unenforced payment. The protocol doesn’t guarantee the builder pays the proposer. Edge cases around withheld payloads stay messy.

What changes

EIP-7732 separates the proposer’s job (choosing the consensus block) from the builder’s job (assembling the execution payload).

• Builders become staked participants in the protocol, with their own registry.
• The proposer commits to a builder’s bid inside the beacon block. The builder then reveals the payload.
• The protocol handles payment to the proposer.
• A Payload Timeliness Committee (PTC) of 512 validators (PTC_SIZE in EIP-7732) attests to whether the builder revealed its payload and blob data on time.
• The propagation window grows from about 2 seconds to about 9 seconds, per ethereum.org. The slot stays at 12 seconds.

Relays become optional. Builders and proposers can still use off-protocol software for features the core protocol doesn’t cover.

ethereum.org notes that staking pools need architecture updates so they can monitor builder payments without trusting a third party.

What it means for you

• MEV-Boost style flows don’t vanish on day one. The protocol adds a trustless builder path, and relays become one option among several. Ask your operator which path they’ll use.
• PTC selection is a new duty. Validators picked for the committee sign an extra attestation. Client software handles it, but missed duties can still cost rewards.
• Reward reporting gets more detailed. A slot can now be full, empty (the builder withheld its payload), or skipped. Make sure your reporting separates the three.
• Builder operation is a separate decision. If you run your own infrastructure, decide whether you want any role as an in-protocol builder. That’s a different job from running validators.

We go deeper on what ePBS means for execution rewards in our companion post, ePBS and your MEV rewards.

Block-level access lists: the path to parallel execution

What it solves

Ethereum processes transactions one at a time because nodes don’t know in advance which accounts and storage slots each transaction will touch. Running them in parallel without that map risks conflicting writes.

What changes

EIP-7928 adds a block-level access list to every block. The list records which accounts and storage locations the block touches, plus the values after each transaction. With it, nodes can:

• Read state from disk in parallel
• Validate non-overlapping transactions in parallel
• Update state from the recorded values without replaying every transaction (executionless sync)

eth/71 (EIP-8159) lets nodes share access lists over the peer-to-peer network. snap/2 (EIP-8189) uses them to heal state during sync.

What it means for you

• BALs are a precondition for higher gas limits. Mainnet runs at 60M today (Etherscan). ethereum.org describes 200M as the gas limit floor Glamsterdam enables, with developers testing against a 150M reference. Sepolia and Hoodi move to 200M at their forks, but a testnet setting is not a mainnet setting. The fork doesn’t raise mainnet to 200M by itself.
• Hardware matters more as limits rise. Parallel execution rewards operators with enough CPU, NVMe, and bandwidth. Ask your operator how their hardware compares with client guidance.
• Faster sync helps resilience. Shorter recovery times matter for redundant validator setups.

Gas repricing and state growth

As capacity rises, the cost of creating and reading state needs to track real hardware costs. ethereum.org frames this as the way to raise capacity while keeping home staking hardware workable.

• State creation (EIP-8037): reprices operations that create permanent state, targeting growth of about 120 GiB per year (ethereum.org). A separate state gas reservoir keeps storage accounting apart from execution gas.
• State access (EIP-8038): raises costs for state-reading opcodes that are underpriced for the work they force on nodes, which makes cheap state-read spam harder.
• Calldata and access lists (EIP-7976 and EIP-7981): align these costs with bandwidth and node load as limits rise.
• Simple ETH transfers (EIP-2780): cuts the base cost of a transfer between existing accounts by up to 71%, per ethereum.org. Sending ETH to a new account carries a surcharge.

Contracts that rely on fixed gas stipends, hardcoded gas limits, or assumptions about remaining gas may need changes. The EF’s repricing impact guide covers how to test for this.

Changes that touch validators

• Slashed validators stop proposing (EIP-8045). A slashed validator is no longer picked as a future proposer, which removes guaranteed missed slots after a slashing event.
• Exits and consolidations get more room (EIP-8061). Exits scale with total staked ETH, and consolidations get their own capacity. At current staking levels, ethereum.org estimates about 4x the exit capacity and about 2x the consolidation capacity. The weak subjectivity period drops from about 15.7 days to about 7 days. These figures move with the amount of ETH staked.

If you’re planning exits or validator consolidations around the fork, factor in EIP-8061.

Changes for custodians, exchanges, and developers

• ETH transfers emit a log (EIP-7708). Every non-zero ETH transfer or burn produces a standard log. Custodians, exchanges, and bridges can detect deposits without custom tracing.
• Bigger contracts (EIP-7954). The max contract size rises from 24KiB to 64KiB.
• Same address across chains (EIP-7997). A built-in factory lets apps and smart wallets deploy to the same address on every participating EVM chain.
• Paged receipts (EIP-7975). Large receipt lists can be fetched in chunks, so sync doesn’t fail as blocks grow.
• New developer tools. SLOTNUM (EIP-7843) and SWAPN, DUPN, and EXCHANGE (EIP-8024).

What Glamsterdam does not include

• FOCIL (EIP-7805) is scheduled for the next fork, Hegotá, alongside frame transactions (EIP-8141), a step toward native account abstraction (Forkcast). Hegotá’s timing depends on Glamsterdam.
• Shorter slots are not in this fork. The slot stays at 12 seconds.
• Letting exits use the consolidation queue (EIP-8080) was declined (Forkcast, June 25, 2026). EIP-8061 is the scheduled change for exit and consolidation churn.

You don’t need to do anything with your ETH. There is no token swap or migration. Anyone telling you to “upgrade your ETH” is running a scam.

Wallets, indexers, and gas estimators that hardcode a maximum gas limit can break on a higher-gas network. Ask your vendors whether theirs is hardcoded.

A checklist for institutional stakers

• Track client releases through EF protocol announcements, client GitHub repos, and EthStaker. Clients without Glamsterdam support fall out of consensus at activation.
• Confirm your operator runs Hoodi-ready client versions before October 26, 2026, at 17:42:48 UTC.
• Confirm the gas limit your validators will target after activation. Defaults vary by client.
• Review CPU, NVMe, and bandwidth against a higher gas limit.
• Ask your operator how they’ll source blocks through the ePBS transition, and how reporting will treat empty slots.
• Plan exits and consolidations with EIP-8061 in mind.
• Remember: no ETH migration and no token swap.

The bigger picture

Glamsterdam moves block production into the protocol and prepares Ethereum for parallel execution. Together, ePBS and BALs support higher gas limits, more room for rollup data, and a cleaner handoff between proposers and builders.

The case for institutional Ethereum staking doesn’t change because of one fork. Validator selection still matters. Commission design still matters. Operational discipline still matters. What grows is the technical surface area, and operators who understand the transition are better placed to keep performance steady through it.

stakefish will publish operational guidance for institutional clients ahead of mainnet activation, and we’ll track each milestone in our newsletter.

Stake Ethereum with stakefish

stakefish has run Ethereum validators since the Beacon Chain launched in 2020 (first staked at genesis).

Our public fee structure is simple: 0% on consensus layer rewards and 50% on execution layer rewards, which flow through our MAX MEV smoothing pool. See how our commission works. Institutional pricing is available on request.

• Stake ETH with stakefish
• Talk to us about institutional staking
• Read the Ethereum Enterprise Staking API docs

Sources

Facts checked October 20, 2026.

• Ethereum Foundation: Glamsterdam Hoodi announcement (October 16, 2026)
• Ethereum Foundation: Glamsterdam testnet announcement (September 17, 2026)
• Ethereum Foundation: Platåberget testnet
• Ethereum Foundation: Glamsterdam repricing impact guide
• ethereum.org: Glamsterdam roadmap
• EIP-7773: Glamsterdam meta EIP
• EIP-7732: Enshrined proposer-builder separation
• EIP-7928: Block-level access lists
• Forkcast: Glamsterdam
• Forkcast: Hegotá
• Hoodi testnet repo

Building staking into a platform? The stakefish Multi-Chain Staking API and SDK cover Ethereum, Solana and more. Read the API docs.

Stake now at: stake.fish/stake

About stakefish

Founded in 2018 by Ethereum and Bitcoin veterans, stakefish is the leading validator for Proof of Stake blockchains. With support for 20+ networks, we combine institutional‑grade infrastructure with intuitive dashboards, transparent reporting, and a spotless slashing record so individuals and institutions alike can stake confidently while strengthening decentralized networks.

Visit our website 🐠 | Telegram | X | YouTube | LinkedIn