Ethereum developers have decided that the next Glamsterdam network will launch as a public-facing testnet called Platåberget, but only after the upgrade’s gas-repricing package is considered stable enough to avoid major specification changes. The decision, reached during All Core Developers Execution Call #242, reflects how close Glamsterdam is getting to its final testing stage.

Devnet 7 is operating steadily with full participation, but developers are not ready to expose the wider ecosystem to what may become the final mainnet specification until benchmark results are complete. The call also marked an important step for Ethereum’s following upgrade, Hegotá.

Platåberget Will Launch Only After Repricing Is Finalized

Devnet 8 is intended to become the final major testing environment before Glamsterdam moves toward mainnet. That makes its specification more consequential than earlier internal devnets. Once the network becomes public-facing, client teams want application developers, validators and infrastructure providers to test against a relatively stable version of the upgrade.

Launching before repricing is finalized would create the risk of developers building against rules that later change substantially. Gas repricing is central to Glamsterdam because the upgrade is designed to make Ethereum better prepared for higher throughput and more parallel execution.

Operations that access state, deploy contracts or consume client resources must be priced closely enough to their real computational cost. If an operation is priced too cheaply, attackers may be able to create blocks that are technically valid but unusually expensive for clients to process.

If it is priced too aggressively, ordinary applications may face unnecessary cost increases. Testing on Glamsterdam Devnet 7 is therefore focused not only on whether the network remains online, but also on whether the proposed gas schedule remains safe under demanding workloads.

The latest analysis introduced some uncertainty. A new state-actor testing tool produced results that may be worse than earlier estimates. Developers are now waiting for a broader benchmark suite before deciding whether further optimization or repricing changes are required.

This is why the launch decision was delayed even though Devnet 7 itself is performing well. The network is currently stable with 100% participation, and Teku has been successfully building blocks locally rather than relying on public bids. That is a positive signal compared with the client instability and participation issues experienced during earlier Glamsterdam testing.

EtherWorld previously tracked this progression in Upgrade Watch #3: Glamsterdam Devnet 7 Nears Final Launch and Highlights from All Core Developers Execution Call #241, where the need for another coordinated network before public testing was already becoming clear. However, stability alone is not enough. The next network must represent something close to the version that Ethereum intends to ship.

Platåberget Will Become Glamsterdam’s Public Testing Ground

Developers agreed that Devnet 8 should not remain another largely internal network. It will instead become a named, public-facing testnet called Platåberget, written as plataberget in configurations and URLs.

Previous Glamsterdam devnets primarily helped client teams test interoperability, specification updates and failure conditions. Platåberget is intended to extend that testing to the wider Ethereum ecosystem. EthPandaOps plans to launch the network with approximately 50,000 genesis validators operating across around 50 nodes. The initial setup will cover different execution-layer and consensus-layer client combinations, creating a diverse environment for interoperability testing.

The network will remain fully permissionless. Validators, staking providers, node operators and decentralized application developers will be able to join and test their own infrastructure. EthPandaOps also intends to maintain a relatively small share of the total validator set. This means external validators should receive a meaningful share of block proposals rather than joining a network overwhelmingly controlled by the testnet operator.

Platåberget will begin in a pre-Glamsterdam state and activate the upgrade approximately seven days after genesis. This gives clients and applications the opportunity to experience a real fork transition from a populated chain. That distinction matters. A network that begins with new rules already enabled cannot fully test how clients handle the moment when the protocol changes.

Its configuration will closely resemble Ethereum mainnet, with only necessary differences such as the chain ID, genesis time and fork versions. Developers expect it to remain active at least until Glamsterdam reaches mainnet. If no critical issue is discovered, Platåberget could represent the final specification that ships with the upgrade.

The public testnet will not replace smaller internal networks. Separate experimental devnets will continue in parallel for restarts, unusual configurations and deliberately chaotic testing that would be unsuitable for external users. This two-track structure gives Ethereum developers both a stable public environment and a more flexible internal environment.

The transition toward public testing follows the roadmap discussed in Ethereum Protocol Update: ACDC #183 and the broader Glamsterdam development covered in Ethereum ACD Monitor #1. Before Platåberget can launch, several smaller readiness issues also need to be resolved.

Most execution clients are prepared for discv5-only discovery, but some still need a working option to disable discv4. Clients must also return Ethereum Node Record information through the admin_nodeInfo RPC endpoint instead of exposing only the older enode value.

Another blocker involves EIP-7928 and Block-Level Access Lists. Clients currently disagree on the expected BAL contents at a specific block in a Hive chain test, preventing full RPC compatibility testing.

Block Access Lists are expected to support faster execution, parallel processing and more efficient state handling. Their importance has been discussed in EtherWorld’s coverage of ACDE Call #219 and EIP-8268 Explained: Benefits, Risks and Ethereum Impact.

Follow all Ethereum protocol calls and updates here.

Eight Execution-Layer EIPs Will Enter Hegotá Evaluation

The second major decision from the call was to move eight execution-layer proposals into the “Proposed for Hegotá” stage. This does not mean the EIPs are confirmed for inclusion. It means they have formally entered the upgrade-selection process and will now receive deeper technical review.

Together, the proposals suggest that Hegotá could focus heavily on making Ethereum easier to execute in parallel, safer for wallets and simpler for client developers.

1. EIP-8115 proposes batching priority-fee payments at the end of a block. Today, fee transfers can create dependencies between transactions. Moving this processing to the end could make parallel execution easier, although the recipient would only be able to spend the priority fee in the following block.
2. EIP-8116 would replace cumulative gas usage in transaction receipts with a direct per-transaction value. The change could make gas proofs easier because users would no longer need an adjacent receipt to calculate how much gas a transaction consumed.
3. EIP-7807 entered Hegotá consideration with a reduced scope. The proposal would focus on introducing an SSZ execution block hash rather than converting transactions and receipts at the same time. This could allow the consensus layer to calculate the execution block hash locally and support future header simplification.
4. EIP-7819, also called SETDELEGATE, would allow a factory opcode to create EIP-7702-style delegation pointers onchain. Supporters argue that it could make smart-account deployment considerably cheaper than creating traditional proxy contracts.
5. EIP-7906 would expose transaction state changes through new opcodes, allowing wallets and smart contracts to verify whether a transaction produced the expected result.
6. EIP-7668 proposes removing logs bloom filters, which developers say have become saturated and provide limited practical value. Removing them could reduce unnecessary computation and simplify the block header.
7. EIP-8200, known as EVMification, would replace selected underused precompiles with equivalent EVM bytecode. This could reduce specialized client logic and make parts of Ethereum easier to maintain.
8. EIP-7666, which replaces the IDENTITY precompile with EVM code, was also moved forward as a companion proposal.

These changes complement Hegotá’s broader focus on censorship resistance, validator efficiency and transaction inclusion. EtherWorld has examined those priorities in Hegotá Should Complete the Holy Trinity of Censorship Resistance and Ethereum Encrypted Mempool: Progress, Challenges and the Road to Hegota.

Glamsterdam Must Stabilize Before Hegotá Can Take Shape

The final implication from ACDE #242 is that Ethereum is now developing two upgrades at the same time, but they are not independent. Glamsterdam’s final design will influence the assumptions behind Hegotá.

EIP-7819 is one clear example. Its expected account-deployment savings are partly calculated against the gas-pricing changes planned for Glamsterdam. Similarly, proposals for priority-fee batching and state-diff access build on the expectation that Ethereum will increasingly support parallel execution.

Client teams must finalize repricing benchmarks, resolve the EIP-7928 compatibility issue, complete discv5 readiness and prepare Platåberget for public launch. For Hegotá, proposal authors must formally submit their candidates before the upcoming ACDC deadline.

The eight EIPs discussed during ACDE #242 will then need to pass implementation reviews, security analysis and cross-client evaluation before any inclusion decision is made. Glamsterdam’s own documentation also remains in progress. Several EIPs still require author or editor approval before moving to Review, and the EIP-7773 meta EIP cannot advance until every proposal listed within it reaches the required stage.

The call therefore did not produce a final Glamsterdam launch date or a final Hegotá scope. Platåberget will launch when developers believe the Glamsterdam specification is stable enough for the wider ecosystem to test. Hegotá proposals will advance only after they demonstrate that they can build safely on that foundation.

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. Highlights from the All Core Developers Consensus (ACDC) Call #179
2. Highlights from the All Core Developers Consensus (ACDC) Call #178
3. Highlights from the All Core Developers Consensus (ACDC) Call #177
4. Highlights from the All Core Developers Consensus (ACDC) Call #176
5. Highlights from the All Core Developers Consensus (ACDC) Call #175

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.