The most consequential Glamsterdam decision was to schedule signaling toward a 200 million gas limit alongside the October 6 Sepolia fork. Developers chose the more demanding test environment despite concerns raised by adversarial Devnet 8 workloads, arguing that Sepolia should expose problems before similar conditions reach mainnet.

Hegotá, meanwhile, saw another major round of proposal filtering. Several EIPs advanced to Considered for Inclusion, EIP-8304 was rejected for this fork, and other proposals were deliberately left unresolved until developers have more data or client feedback.

Sepolia Will Target a 200M Gas Limit With Glamsterdam

Developers agreed to schedule signaling toward a 200 million gas limit at the Glamsterdam Sepolia fork on October 6.

Glamsterdam’s October 6 activation date had already been confirmed during ACDC #187, with client releases expected before the fork. ACDE #246 added an important parameter to that test: validators will be able to begin moving Sepolia toward a 200M gas limit once Glamsterdam activates.

Recent adversarial testing on Glamsterdam Devnet 8 produced valid workloads that took unusually long to execute. Developers discussed blocks that could require eight seconds or more under certain attack patterns, with some client observations reaching even higher execution times.

This creates a serious concern under Ethereum’s 12-second slot structure. If a payload is delivered several seconds into a slot and then requires many additional seconds to execute, the work can extend into the following slot and increase the risk of reorganization or degraded network performance.

The issue is particularly important because, as developers emphasized, Glamsterdam is fundamentally a scaling-focused upgrade. Raising throughput without proving that execution clients can handle worst-case workloads would undermine the purpose of the upgrade.

Instead of choosing a conservative testnet configuration, developers argued that Ethereum should reproduce conditions closer to what it ultimately expects from mainnet. If 200M reveals a bottleneck, discovering it on Sepolia is preferable to discovering it after production deployment.

EIP-8037, previously discussed during ACDE #244, changes the relationship between gas limits and state creation costs. Developers warned that remaining too far below roughly 150M gas after the repricing could make some transactions disproportionately large relative to available block capacity and increase base-fee volatility.

Retention Window Changes Will Not Block Glamsterdam

Developers did not finalize new CL and EL retention windows and agreed that the issue is not a blocker for Glamsterdam testnet deployment.

EIP-8061 alters a Consensus Layer parameter connected to validator exits and consolidations. Ethereum’s current block-retention window was originally tied to the older value, creating an opportunity to shorten how long historical data must be retained.

During ACDE #246, developers described a Devnet 8 case where a Geth node had been offline for roughly two weeks. When it restarted, the node had recent Block Access Lists available but lacked the data corresponding to the point from which it actually needed to resume synchronization.

According to the discussion, sequential execution can be substantially slower than parallel execution. As Ethereum raises throughput, that becomes increasingly relevant: if sequentially processing a block eventually takes longer than Ethereum’s 12-second slot time, a node attempting a full sync could struggle to catch up with the chain.

Developers therefore discussed whether the Execution Layer’s Block Access List retention period should match the Consensus Layer block-retention window. One option would keep a much longer window around 33,000 epochs. Another could reduce the requirement substantially based on the new parameters introduced by EIP-8061.

Instead, developers agreed to continue the discussion asynchronously. Because changing these windows does not require immediate resolution for the October 6 Sepolia fork, Glamsterdam can proceed while clients separately determine the safest long-term retention policy.

Follow all Ethereum protocol calls and updates here.

Hegotá Advances a Major Batch of Execution EIPs

Developers moved a large group of Hegotá execution proposals to CFI, including EIP-7979, EIP-8163 and several of the highest-rated client proposals.

The most notable change involved EIP-7979, which introduces structured call and return operations for the EVM. The proposal had remained uncertain after ACDE #245, when developers began separating strong candidates from EIPs likely to be rejected.

Prototype work across Solidity, Vyper and execution clients helped address concerns about implementation complexity. Supporters also argued that introducing more explicit static control flow could improve compilation, validation and zero-knowledge proving over time.

With client opposition weakening, EIP-7979 moved to CFI. EIP-8163 also advanced. Rather than introducing immediate EVM functionality, the proposal reserves an opcode for extensions used by alternative EVM environments.

Supporters pointed to demand from ecosystems including Monad and Arbitrum Nitro, while execution clients noted that the reservation itself imposes minimal implementation burden. That was enough to move EIP-8163 to CFI as well.

Developers then advanced several highly rated proposals with comparatively little disagreement. EIP-7906 moved forward after receiving support from hardware and offline signing use cases.

EIP-8250 and EIP-8272 also advanced as part of the broader Frame Transactions architecture. Their inclusion reinforces Hegotá’s Account Abstraction direction after Frame Transactions emerged as its execution-layer headliner.

Other proposals moved forward as well:

• EIP-7668, removing bloom filters
• EIP-8253, addressing zero-nonce storage accounts
• EIP-3298, removing storage-clear refunds and the refund cap
• EIP-8131, introducing a unified transaction-content floor

Hegotá’s Remaining Scope Will Be Decided Over the Next Two Calls

Developers left several proposals unresolved and plan to use the next two ACDE calls to settle roughly ten remaining execution-layer candidates.

EIP-8304, the Trustless Log Index proposal, was moved to DFI for Hegotá after client teams maintained their previous assessments. Its champion indicated that work on the project would continue despite exclusion from this fork.

EIP-8360, which proposes the TCREATE opcode for transaction-scoped contracts, received a different outcome. Developers agreed not to reject it yet.

Supporters argued that Glamsterdam’s state-pricing changes make existing ephemeral-contract patterns using SELFDESTRUCT significantly more expensive. TCREATE could provide a protocol-native replacement for use cases including temporary payment addresses, cross-chain intents and disposable accounts.

But several developers argued that its treatment should be considered alongside the broader future of SELFDESTRUCT. EIP-8368 and EIP-8372 were also left unresolved, but for a different reason.

Developers believe the choice between them depends on real mainnet data after Glamsterdam activates. Instead of prematurely selecting one, both proposals will remain PFI until that information becomes available.

The upgrade already has major architectural anchors. Frame Transactions define much of the execution-layer Account Abstraction direction, while FOCIL continues to shape the censorship-resistance side of the roadmap, explored further in EtherWorld’s Hegotá censorship-resistance analysis.

Developers now need to decide which supporting EVM, gas-accounting, transaction-format and protocol-cleanup changes deserve to ship alongside those headliners. With only two ACDE calls planned for evaluating the remaining execution proposals, Hegotá is approaching the point where PFI must increasingly become either CFI or DFI.

ACDE #246 therefore marked a clear transition for both upgrades. For Glamsterdam, the question is moving from what should ship to whether the selected design survives aggressive testing. Ethereum’s next two upgrades are now progressing through very different stages, but both are moving closer to a fixed protocol scope.

If you find any issues in this blog or notice any missing information, please feel free to reach out at yash@etherworld.co for clarifications or updates.

To promote your Web3 articles, events, and projects, you may reach out anytime via EtherWorld PR for submissions and collaboration.

Related Articles

1. Platåberget Testnet Brings Glamsterdam Closer to Mainnet
2. Ethereum Protocol Update: ACDC #184
3. Ethereum Protocol Update: ACDC #183
4. Tracking the Glamsterdam Upgrade on EIPsInsight
5. All You Need to Know About Ethereum Hegotá Upgrade

To follow blockchain news, track Ethereum protocol progress, and read our latest stories, subscribe to our weekly today.

Join the EtherWorld & Avarch Internship Program and build your career in blockchain, content, social media, video, podcast editing, or operations. Send your resume and brief introduction to contact@etherworld.co.