Reporting window: 2026-08-24 20:17:36 WITA through 2026-08-31 20:20:18 WITA (Asia/Makassar).

Hegotá now has a commitment to ship native account abstraction, but not yet a commitment to ship today’s Frame Transaction unchanged. AllCoreDevs Execution moved EIP-8141, Frame Transaction, to Scheduled for Inclusion on August 27, giving the upgrade its second scheduled feature after FOCIL. The same decision preserved room for major redesign, including a different EIP number, while the Frame and Account Configuration teams try to converge. That combination is the week’s central development: client teams have committed to the outcome soon enough to organize implementation, but kept the mechanism open while the most consequential design questions are still live.

The commitment is stronger than the current document

The canonical Hegotá meta EIP now lists Frame Transaction under Scheduled for Inclusion, rather than Proposed or Considered. The current Frame Transaction draft decomposes validation, fee approval, and user operations into contract-call frames, allowing accounts to define authentication and gas payment without relying on the existing ECDSA-bound transaction model.

The decision did not settle that exact shape. Derek Chiang reported that the Frame and EIP-8130, Account Abstraction by Account Configuration, teams had timeboxed convergence work to two to four weeks. Their preferred result is a shared transaction type; the fallback is separate transaction types that let the same account work at the same address across L1 and L2. Vitalik Buterin recommended scheduling Frames while continuing the redesign, and Ethrex, Nethermind, and Besu supported the move; Erigon had not formed a position. Core developers also accepted the caveat that Scheduled for Inclusion must not become an argument against radical specification changes.

That caveat makes the next signal unusually clear. Weekly account-abstraction breakouts must show whether the two proposals can share transaction semantics, and the separate frames-devnet-0 track must turn the document into multi-client behavior. Until then, the governance decision is real, but the present opcode, precompile, and envelope choices remain provisional.

History expiry returns as client work

EIP-4444, Bound Historical Data in Execution Clients, moved from Stagnant back to Draft and replaced its old one-year horizon with 33,024 epochs, matching the consensus layer’s block-retention window. The revised specification says execution clients should stop serving older headers, bodies, and receipts over devp2p and may prune them locally; it also makes checkpoint sync, rather than genesis sync over the p2p network, the assumed bootstrap path. The rationale ties the common window to consensus clients that depend on their paired execution client for payload history.

This was more than an editorial revival. On ACDE #244, Nimbus and Nethermind reported implementations, Reth targeted its next release, Ethrex reported a pull request under test, Erigon agreed to investigate, and Geth had agreed with the direction but supplied no implementation update. The call treated history expiry as storage work that should not trail Glamsterdam, while the EIP still flags out-of-band history availability and centralization as unresolved risks. The watch item is therefore Geth’s implementation and a coordinated rollout plan, not the Draft label by itself.

FOCIL’s tests found specification bugs

FOCIL gained a more useful form of implementation evidence than another prose revision. A merged change on the execution-specs feature branch updated fixtures to the latest Engine API and generated inclusion-list variants from existing tests. Those tests found three specification bugs: wrong-chain transactions were treated as includable, malformed RLP could throw inside the validator, and type-3 transactions were excluded by default. This is not a merge to the repository’s main branch or proof of client interoperability, but it converts previously implicit edge cases into conformance tests.

At the cutoff, the first dedicated EIP-7805, Fork-choice enforced Inclusion Lists, devnet still had an August 31 launch target, not a verified launch result. Its published plan calls for end-to-end committee and proposer behavior, timing-boundary tests, FOCIL–ePBS interaction, and a censoring proposer or builder. It also identifies an open Beacon API pull request as the main validator-client/beacon-node coordination risk and says purpose-built censorship-test tooling is not yet available. The next meaningful evidence is a multi-client network that crosses those interfaces, not the calendar target.

Glamsterdam’s document matures before its dates do

The Glamsterdam meta EIP moved from Draft to Review on August 27. The merged edit also removed its long Declined for Inclusion list so the meta document could satisfy status rules; the resulting Review document contains the scheduled upgrade scope but still has blank activation rows. This is a proposal-process maturity signal, not a declaration that the fork is release-ready.

ACDE #244 reported the current public devnet as stable and outlined a short-lived non-finality successor with attack testing, roughly three to four million validators, and 20,000 to 25,000 builder deposits. September 28 for Sepolia and October 26 for Hoodi remained proposals to be confirmed on the next consensus call. The distinction matters: the scope document is in review, while the stress test and activation decisions are still ahead.

Outside the core fork path, one standards deadline is worth noting. ERC-7945, Confidential Transactions Supported Token, entered Last Call with a September 8 deadline after its transfer functions were changed to rely on reversion rather than boolean success returns. That is a review clock for an application interface, not evidence of deployment or ecosystem adoption.

Sources and further reading