Platåberget did not have a clean first fork. That is the most useful thing that happened to Ethereum protocol development this week.

When Gloas activated on August 20, the public testnet lost finality and recovered only shortly before the day’s core-developer call. The network had been loaded with roughly 16,000 queued builder deposits. Lighthouse, Prysm, and Teku each hit a different problem while processing them at the fork boundary; Lodestar and Nimbus reported no transition problem.

Nothing in that result says Glamsterdam is ready. It says the test finally reached conditions that private, short-lived devnets had not reproduced well enough.

A public test found client assumptions

Platåberget was designed to remain available for a few months, giving validators, application teams, and infrastructure operators a stable place to break post-Glamsterdam Ethereum before Sepolia and Hoodi. Its validator set is publicly joinable, so builder deposits arrive through something closer to a real operating environment instead of a neatly staged internal run.

The fork exposed several assumptions at once. Lighthouse had merged a cache optimization only hours before activation, which meant earlier deposits were not in that cache. Prysm had removed its builder-deposit cache while evaluating whether it was still needed. Teku’s retry behavior turned a slow first-block transition into a much longer recovery. Lodestar, by contrast, had reduced its own transition processing from about 20 seconds to roughly half a second.

These are implementation failures, not evidence that ePBS itself failed. But they point to the same operational lesson: mainnet deposits may sit in the queue for weeks, and a client cannot assume that a warm in-memory cache will still exist at the fork boundary. A public network made that assumption visible before a long-lived testnet had to absorb it.

Application developers have a different test to run. Glamsterdam changes both the block-production pipeline and gas accounting. The Ethereum Foundation’s launch note warns that wallets, indexers, and gas estimators with a hardcoded maximum gas limit will break, and that a transfer to a previously nonexistent account is no longer guaranteed to fit the familiar 21,000-gas shortcut. Platåberget is therefore not only a client-team network; it is the first practical compatibility target for downstream tooling.

The next dates remain proposals

Core developers discussed September 28 for Sepolia and October 26 for Hoodi, but left both dates unconfirmed. Lido, SSV, and others asked for more stable testing time first. The current proposal also puts Sepolia ahead of Hoodi so application developers encounter the gas changes earlier.

Before either date is locked, client teams want another network that is built to misbehave. A roughly 1,000-node non-finality devnet is targeted for the week after next, once the relevant client changes have reached trunk or unstable branches. Because that network is expensive, the current plan gives it only about one to one-and-a-half days before the fork. A smaller finalizing network may run alongside it for teams that need a calm integration target.

That separation is sensible. The pathological network can stress recovery and repeat the mass-deposit test; the public network can remain usable for wallets, staking systems, and application infrastructure. One environment does not need to serve both jobs badly.

Glamsterdam got slightly smaller

The week also produced a clear scope decision. Core developers formally removed EIP-7610, which would add a runtime check to prevent contract creation over an account with non-empty storage. The corresponding change to the Glamsterdam meta EIP was merged on August 20, and EIP-7773 now lists EIP-7610 as declined.

The replacement path is narrower. EIP-8253 proposes a one-time nonce change for the 28 affected mainnet accounts, avoiding a new storage check on every future contract creation. It is a Draft and was only proposed for Hegotá this week; that is the start of consideration, not a promise of inclusion.

This is the quieter half of protocol work. Public testing finds the assumptions that need code changes. Scope review removes code that no longer earns its permanent cost.

Hegotá begins to choose

Hegotá is now moving from collecting candidates to comparing them. Client teams were asked to publish an initial S/A/B/D ranking by mid-September, explain the reasoning behind their tiers, and work toward a rough upgrade scope before Devcon. The call also announced an intention to decline proposals with no active champion.

Those rankings are signals, not votes. “Proposed for Inclusion” is likewise a queue for discussion, not an inclusion decision. The useful information will be where several client teams independently see the same implementation risk or the same protocol value.

For next week, the most important evidence will not be another list of candidates. It will be whether the Platåberget fixes land cleanly, whether the non-finality network launches on the intended branches, and whether application teams report concrete breakage from the new gas rules.

Sources and further reading