Ethereum Glamsterdam Timeline: H1 2026 Target Moves to Q4

Fusaka Shipped First, Then Glamsterdam's Target Moved

Pectra launched on May 7, 2025 with account abstraction (EIP-7702) and doubled blob throughput. The next fork after Pectra was not Glamsterdam, it was Fusaka: Fusaka activated on Ethereum mainnet on December 3, 2025 at epoch 411392, headlined by PeerDAS (EIP-7594), which lets validators sample blob data instead of downloading it in full (Ethereum Foundation announcement).

The Ethereum Glamsterdam upgrade was originally scoped for H1 2026. The Ethereum Foundation's own February 2026 protocol-priorities post still described it as "targeted for the first half of 2026" (blog.ethereum.org). That target did not hold. The current ethereum.org roadmap page for Glamsterdam now states the upgrade is "planned for Q4 2026," and as late as the August 13, 2026 All Core Devs Execution call, developers were still discussing devnet-8 (codename Platåberget) and finalizing gas repricing numbers (ethereum/pm issue #2178). A hard fork that was supposed to be live by mid-2026 had not even locked its parameters by mid-August.

Glamsterdam: Parallel Execution and Enshrined PBS

The Ethereum Glamsterdam upgrade tackles Ethereum's sequential-execution bottleneck with two headline changes.

Block-Level Access Lists (EIP-7928)

EIP-7928 adds a block_access_list_hash field to block headers, a hash of every account and storage slot touched during block execution, including unchanged accounts. This lets clients read state, execute transactions, and reconstruct state roots in parallel instead of one instruction at a time, and it is a prerequisite for stateless verification of blocks (EIP-7928 text). EIP-7928 is currently in Review status on the EIPs site, meaning the specification is stable enough for client teams to implement but not yet finalized.

Enshrined Proposer-Builder Separation (EIP-7732)

Today Ethereum relies on external relays like MEV-Boost to separate block proposing from block building. EIP-7732 moves that separation into the protocol: proposers publish a signed bid from an in-protocol builder registry (builders stake a minimum of 1 ETH and are subject to slashing), and execution-payload validation is deferred to the next slot instead of blocking the current one. A 512-validator Payload Timeliness Committee attests that the payload was revealed on time, without re-executing it (EIP-7732 text). Like EIP-7928, it is in Review status, not yet Final.

Both EIPs are tracked under the Glamsterdam meta-EIP, EIP-7773, which lists 22 EIPs scheduled for inclusion (covering gas repricing, opcode changes, and networking updates) and 39 EIPs that were formally proposed and declined. EIP-7773 itself is still in Draft status; it states plainly that activation details for Sepolia, Holesky, and mainnet "remain to be determined."

The Gas Limit Question Is Still Open

The original plan floated a jump from roughly 60 million gas to 100-200 million. That number is not settled. At the August 13 ACDE call, developers reviewed a separate proposal, PFI EIP-8261, warning specifically that setting the 200M gas limit in client software before the fork activates "risks premature increase" (ethereum/pm #2178). The ethereum.org roadmap page confirms client teams are currently testing against a 150 million reference block as an interim step to derive accurate state-access pricing, not the full 200 million target (ethereum.org/roadmap/glamsterdam). In plain terms: the gas limit increase is real, but the final number is not locked, and shipping it too early was flagged as a protocol risk by the developers building it.

There is a second open question specific to this fork: whether clients are ready for history expiry, the plan to stop full nodes from storing Ethereum's entire historical chain data forever. It was still an open agenda item, not a settled decision, at the same August call.

Hegota: Verkle Trees, FOCIL, and a Timeline That Has Not Been Set

Hegota follows Glamsterdam. Two features anchor it.

Verkle Trees and Stateless Clients

Ethereum currently stores state in Merkle Patricia Tries, which require large proofs, several kilobytes, to verify a single piece of data. Verkle Trees replace that structure with one that produces proofs of roughly 150 bytes. Smaller proofs are what make stateless clients possible: a node can verify a block using only the header and the accompanying Verkle proofs, without holding the full multi-hundred-gigabyte state itself. That is the change BALs (above) are laying groundwork for on the execution side.

FOCIL: Censorship Resistance at the Protocol Level

The original version of this article treated Hegota as a single-feature (Verkle Trees) fork. It is not. Fork-Choice Enforced Inclusion Lists, EIP-7805, randomly select a committee of participants per slot who can force specific pending transactions into the next block, closing the gap where a block builder could otherwise quietly exclude valid transactions. Native account abstraction is also on the table for Hegota: EIP-7701 and EIP-8141 ("Frame Transactions") were both referenced in the Ethereum Foundation's 2026 protocol-priorities post as candidates for the fork (blog.ethereum.org), and as of the August 13 call, Frames had been Considered-For-Inclusion and Nethermind had shipped client support, with a breakout meeting series restarting to resolve an open EVM-compatibility objection (ethereum/pm #2178).

Hegota has no locked mainnet date. The Ethereum Foundation's own process post from December 2025 lays out only the proposal and selection schedule, headliner proposals through early February 2026, headliner finalization by late February, a further 30-day window for smaller EIPs, and explicitly does not name an activation date, pointing readers to Forkcast for the live schedule instead (blog.ethereum.org/2025/12/22/hegota-timeline). As of the August 13, 2026 ACDE call, Hegota's Priority-For-Inclusion list was still being finalized, with a two-week deadline for outstanding proposals and a September 10, 2026 deadline for client teams to submit preference rankings. Anything without a Priority-For-Inclusion sponsor by then is automatically declined. Given that Glamsterdam itself is not expected before Q4 2026, a Hegota mainnet date inside 2026 is not realistic; the Foundation has published no target date, so any 2027 framing is inference from the schedule, not an announced plan.

How the Ethereum Glamsterdam Upgrade and Hegota Fit Together

Glamsterdam increases how many transactions Ethereum can process per block. Hegota is meant to keep running a node affordable once that throughput lands, by cutting what a node has to store. Shipping more throughput without the state-management half would accelerate the state-bloat problem Verkle Trees exists to fix. That is this article's reading of the sequencing; the Foundation has not published a stated rationale for running the two forks separately rather than bundling them.

What This Means for Layer 2 Rollups

Ethereum's Layer 2 ecosystem, where much of the user-facing transaction activity now happens, stands to benefit from Glamsterdam, though through a different channel than the one that already cut rollup costs. Glamsterdam's higher execution gas ceiling raises how many transactions L1 itself can process; the capacity rollups actually post their data into is the blob space that PeerDAS (Fusaka) expanded in December 2025, a separate parameter that Glamsterdam does not itself increase. Whether a bigger execution gas limit translates into lower rollup fees depends on L1 demand for that added block space at the time; it is not a fixed cost reduction.

For rollup operators like Arbitrum, Optimism, and Base, the mechanism to watch is blob-space capacity and demand for it, not the execution gas ceiling; PeerDAS's added capacity can reduce blob-fee pressure when demand does not absorb it, a condition that does not depend on Glamsterdam shipping; the size of any end-user effect still varies by each rollup's own architecture and demand. For the broader ecosystem, see our analysis of Layer 2 consolidation trends.

Competitive Context: How Ethereum Compares

Ethereum is not upgrading in a vacuum. Solana's Alpenglow protocol targets 100-150ms block finality. Avalanche, Sui, and Aptos all advertise sub-second finality in their own documentation, and they are shipping while Ethereum is still finalizing gas repricing numbers for a fork whose target moved from a first-half window to a fourth-quarter one.

Ethereum's approach differs on what it optimizes for:

1. Decentralization - ePBS and stateless clients are both framed in their proposals as lowering the burden of running a validator or a full node, not as maximizing raw throughput
2. Security - ZK-proof validation work continues in parallel, though the 2026 target share of validators running it has not been reconfirmed since the Glamsterdam slip
3. Composability - Eligible L2 rollups settle on the same shared security layer and build on the blob-space capacity Fusaka's PeerDAS already expanded in December 2025, with the Ethereum Glamsterdam upgrade adding L1 execution headroom on top; the practical fee and capacity effects still vary by each rollup's own architecture and demand; how that compares with single-chain competitors is a comparison this article does not make.

For a detailed comparison of how L1 blockchains stack up, see our Layer 1 Wars 2026 analysis. For Ethereum's institutional positioning, read our Year of Ethereum 2026 deep dive.

Ethereum Glamsterdam Upgrade Risks and Open Questions

What the record actually shows, as of August 2026:

• The H1 2026 target already missed. Glamsterdam was described as an H1 2026 fork as recently as February 2026 and is now officially Q4 2026. With both EIP-7732 and EIP-7928 still in Review rather than Final status, a further slip is a material risk worth tracking, not something this article has the fork-delay history to rate as likely or unlikely.
• The gas limit is not decided. Developers are explicitly testing against a 150M reference block, not the 200M headline figure, and a live proposal (EIP-8261) argues against setting 200M in client code before the fork activates.
• History expiry readiness is unresolved. Whether client teams can support it in time for Glamsterdam was still an open question at the August 13 call, not a settled feature.
• Hegota has no date. The process for selecting Hegota's features is still running; the Priority-For-Inclusion list only becomes final in the second half of August 2026, with client preference rankings due September 10, 2026.
• Adoption lag persists regardless of ship date. Even once stateless clients are available, existing node operators upgrading their infrastructure takes time that does not show up in a protocol timeline.

The Bottom Line

The Ethereum Glamsterdam upgrade is real, but it is running behind its own original schedule. Fusaka shipped on its revised December 2025 date. Glamsterdam has not: its headline EIPs are still in Review, its gas limit is still being tested at an interim figure, and its own roadmap page has moved the target from H1 to Q4 2026. Hegota, which brings Verkle Trees and FOCIL, follows Glamsterdam and does not yet have a mainnet date at all.

For investors, the signal worth tracking is not the roadmap copy, it is whether devnet-8 clears its remaining open items (gas repricing, history expiry readiness) without another slip. With a STRICT score of 88 and $41.24 billion in TVL (DefiLlama, Chains API), Ethereum enters this upgrade cycle with the deepest DeFi capital concentration of any chain tracked here, even as its execution timeline has stretched. Watch the ethereum/pm All Core Devs Execution call notes directly for the next Glamsterdam devnet update rather than a fixed calendar date, since the calendar date has already moved once.

Disclaimer: The content above is for informational purposes only and does not constitute financial advice. Cryptocurrency investments carry significant risk. Always conduct your own research and consult with a qualified financial advisor before making investment decisions.