Ethereum developers have given native account abstraction a much clearer path toward the Hegotá upgrade, moving EIP-8141, Frames, to Scheduled for Inclusion during All Core Developers Execution Call #244. At the same time, Ethereum's nearer-term Glamsterdam upgrade is entering a very different phase.

The focus is shifting from ordinary devnet stability toward intentionally stressing the network through non-finality, attack scenarios and extremely large validator states.

EIP-8141 Frames Gets Support for SFI in Hegotá

Ethereum developers backed EIP-8141 Frames for SFI in Hegotá, giving the proposal strong support as the upgrade’s native account abstraction path. Frames had previously been advanced as a placeholder because developers broadly agreed that Hegotá should make progress on account abstraction, while the exact mechanism was still being worked out.

Part of the Layer 2 ecosystem has been preparing EIP-8130, while Ethereum L1 developers have been evaluating EIP-8141. Shipping materially different transaction systems across L1 and L2 could create additional work for wallets, SDKs, explorers, paymasters and other infrastructure that would need to understand both formats.

That fragmentation risk is now pushing the two groups closer together. Authors of EIP-8130 and EIP-8141 have started working toward two possible outcomes.

The preferred result is a shared transaction type that retains the flexibility of Frames while allowing more opinionated account systems to be implemented on top of it.

If that cannot be achieved, developers want at minimum to preserve account interoperability. A user should ideally be able to operate the same account at the same address across L1 and L2 networks even if different transaction formats exist underneath.

Vitalik Buterin argued that the proposals should increasingly be viewed as different points within the same design space rather than completely separate competing architectures. Areas where the approaches could move closer include keystore design, authentication logic, transaction structure and whether certain functionality belongs in opcodes, precompiles or contracts.

Execution clients ultimately showed strong support for allowing work on Frames to proceed. Ethrex, Geth, Nethermind and Besu were among the clients that signaled support for moving EIP-8141 to SFI during the call.

The broader direction has been developing for several calls. During ACDE #241, developers had already made clear that native account abstraction remained an important Hegotá priority. ACDE #243 then pushed the debate toward a more explicit choice between competing approaches.

EIP-8141 has received strong developer support for Hegotá, but its Scheduled for Inclusion (SFI) status still needs to be formally ratified through the documented ACD process. Until that happens, it is more accurate to describe the proposal as having consensus toward inclusion rather than being officially SFI.

One small clarification from the process side: I’d suggest waiting for EIP-8141 to be explicitly ratified as SFI (Scheduled for Inclusion) on an ACDT call before describing it as having moved to Scheduled for Hegotá.

The direction and intent may be clear from today's ACD… https://t.co/tK3umk4pyJ pic.twitter.com/x7gHGcC0BJ

— Pooja Ranjan | ranjan.eth (@poojaranjan19) August 27, 2026

Glamsterdam Moves Into Adversarial Testing

The next major coordinated environment, Devnet 9, will serve as a non-finality and adversarial-testing network once clients have merged the necessary fixes into their trunk branches.

Developers reported participation close to 100% while continuously loading the network with roughly ten blobs and around 100–150 transactions per slot. The few missing payloads observed were largely linked to outdated client releases rather than fundamental protocol issues.

That stability gives developers room to become much more aggressive. Devnet 9 is expected to contain roughly three to four million validators, producing a genesis state potentially around 600–700 MB.

Developers also discussed generating around 20,000 to 25,000 builder deposits, including deliberately invalid deposits, to place additional pressure on client implementations. The network may initially operate normally through the fork transition. Researchers would then be allowed to launch attacks intended to cause failures or non-finality before developers deliberately extend the non-finality period and test recovery.

September 28 remains the proposed Glamsterdam activation date for Sepolia, while October 26 has been proposed for Hoodi. If the schedule holds, developers expect to preserve a security-review window followed by preparation time for L2s, DAOs and other ecosystem infrastructure before a possible mainnet fork around the beginning of December.

Follow all Ethereum protocol calls and updates here.

History Expiry Becomes a Glamsterdam Readiness Requirement

Execution clients are moving toward aligning around a common historical-data retention window based on the Consensus Layer block-retention period. Developers noted that some Ethereum nodes using 2 TB drives are already consuming approximately 1.5 to 1.8 TB.

Allowing historical data to continue accumulating without a more consistent expiry strategy could leave some operators with insufficient capacity after Glamsterdam. The preferred direction is to document the common retention approach through EIP-4444-related work instead of introducing another standalone Glamsterdam proposal.

Nimbus has already implemented the relevant behavior, while other execution clients are working toward compatible approaches. Ethereum has been gradually moving in this direction for some time.

Major clients have already introduced forms of Partial History Expiry, allowing operators to remove historical block data that is unnecessary for validating the current chain. EtherWorld has also published a practical guide on Partial History Expiry across Geth, Besu and Nethermind.

The ACDE #244 discussion shows why that work matters more as Ethereum raises throughput. Increasing the gas limit without controlling the long-term storage burden would gradually make full nodes harder to operate.

Glamsterdam's scalability work therefore increasingly depends on complementary changes that prevent hardware requirements from growing unchecked. The call also surfaced a related state-cost issue around EIP-8037.

Developers considered whether an account created and destroyed within the same transaction should receive its state-gas charge back because it leaves no persistent state behind. Without that adjustment, temporary or ephemeral-contract patterns could become relatively expensive despite not adding lasting state.

However, developers concluded that changing EIP-8037 this late in Glamsterdam would mean specification changes, client changes and another round of testing. Rather than risk delaying the fork, the underlying problem is expected to be addressed more deliberately through Hegotá.

The growing number of open PRs in the EIP repository is becoming a coordination concern, with around 500 currently pending. Many of these still need attention from authors, editors or ACD participants, which can slow down status updates and leave upgrade documentation behind actual decisions.

Today on ACD, I shared a <5 min update on Glamsterdam & Hegotá open PRs requiring attention, highlighting blockers and where author/ACD attention is needed.https://t.co/bU33Y8uDEi

The goal here is to keep the "Meta EIP the canonical, up-to-date source of upgrade information."… pic.twitter.com/DTdPfpZ1AL

— Pooja Ranjan | ranjan.eth (@poojaranjan19) August 27, 2026

A short 2–5 minute EIP update slot during ACD calls could help flag blockers and pending changes earlier.This would also help keep the Meta EIP aligned with the latest upgrade decisions.

Hegotá Enters Its Final Scope-Narrowing Phase

With Frames now SFI, attention is turning toward which other proposals can realistically fit inside Hegotá. The upgrade has accumulated a substantial number of candidate EIPs, but developers are now moving from proposal collection toward elimination and prioritization.

Execution-client teams have been asked to submit their preferred non-headliner proposals ahead of the next ACDE. Client preferences are expected by September 9, one day before the September 10 call.

EIP champions will then need to participate actively through the upcoming scoping calls. Developers made clear that proposals without somebody prepared to defend their inclusion can be removed from consideration.

This reinforces the stricter governance process introduced during ACDE #243, where developers emphasized that Hegotá cannot become an unlimited collection of desirable improvements. The Hegotá upgrade already has a broad direction.

FOCIL remains its Consensus Layer headliner, keeping censorship resistance and stronger transaction-inclusion guarantees at the center of the fork. EtherWorld has previously examined how FOCIL fits into Ethereum's censorship-resistance roadmap and tracked its progress through earlier All Core Developers discussions.

One proposal seeking stronger client support is EIP-8304, Trustless Log and Transaction Index. Its objective is to make historical Ethereum queries verifiable instead of requiring users to blindly trust external indexers.

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. All You Need to Know About Ethereum Glamsterdam Upgrade
2. All You Need to Know About Ethereum Hegotá Upgrade
3. Ethereum Protocol Update: ACDE #243
4. Highlights From the All Core Developers Execution Call #241
5. Ethereum Clients Roll Out Partial History Expiry

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.