Just over one hundred core contributors to the Ethereum network recently gathered in Longyearbyen, Svalbard, nestled above the Arctic Circle, for an intensive week of collaborative development known as Soldægn Interop. The primary objective of this gathering was to advance the critical "Glamsterdam" network upgrade, a pivotal step in enhancing Ethereum’s scalability and efficiency. This event follows in the tradition of previous interop sessions, including Berlinterop, Amphora, Edelweiss, and Nyota, each focused on specific network enhancements. The Soldægn Interop, however, returned to a single-track format, emphasizing deep, multi-client collaboration toward a singular, ambitious goal: hardening the Glamsterdam upgrade.
The intense week of development, held under the perpetual daylight of the Arctic summer, culminated in the achievement of three principal objectives by Friday. These included establishing alignment on a post-Glamsterdam gas limit floor of 200 million, ensuring the stability of execution-payloads-by-builders (ePBS) implementations operating with external builders, and finalizing the repricing numbers for EIP-8037. Significant headway was also made on future features, such as those planned for the Hegedas upgrade, including FOCIL (Formal Consensus Layer) and native account abstraction, alongside progress on numerous other technical fronts.
The Strategic Choice of Svalbard: A Nexus of Innovation and Preservation
The selection of Longyearbyen, Svalbard, as the venue for Soldægn Interop was deliberate and multifaceted. Beyond its unique geographical location, Svalbard offers an environment where individuals from any nation can live and work without visa restrictions, fostering an inclusive atmosphere for global collaboration. More profoundly, the archipelago is home to the Svalbard Global Seed Vault and the Arctic World Archive. These remarkable facilities, carved into the permafrost, serve as repositories for humanity’s most vital data and genetic heritage, safeguarding everything from crop diversity to cultural artifacts and source code for future generations. Notably, Ethereum’s own source code is part of this digital ark, symbolizing the project’s commitment to long-term data preservation.
Furthermore, the extended daylight hours in Svalbard from late April through August provided a unique operational advantage. This period of 24/7 sunlight mirrored the continuous uptime characteristic of the Ethereum network itself, allowing core developers to maximize their working hours and foster an environment of constant progress, much like the network they are dedicated to building. This unique setting, combined with the shared objective of advancing Ethereum’s scalability, created an unparalleled atmosphere for focused development.
Hardening Glamsterdam: Paving the Way for Enhanced Scalability
The central mission of the Soldægn Interop was to solidify the technical foundations for the Glamsterdam upgrade, with a particular focus on establishing a robust and sustainable gas limit. Safely increasing Ethereum’s gas limit is a complex, multi-dimensional challenge that Glamsterdam is designed to address. The upgrade tackles several key areas: optimizing how blocks are constructed and proposed, ensuring that client implementations have sufficient operational headroom under increased load, and refining how state-creation costs scale in tandem with transaction throughput.
The practical outcome of the week’s efforts was the establishment of a stable, multi-client Glamsterdam development network. This network was configured to run the latest ePBS implementations, alongside finalized specifications for gas repricing and block access lists. Crucially, the week generated extensive benchmarking data, which now serves as a solid empirical basis for proposing a credible increase to the gas limit. The majority of the developers’ time was spent in deep coding sessions, often extending into the early hours of the morning. These periods of intense individual work were interspersed with focused breakout sessions dedicated to aligning on critical design decisions and discussing the long-term roadmap for Ethereum’s evolution.
The logistical and technical support for the event was provided by three dedicated teams from the Ethereum Foundation. EthPandaOps delivered their advanced tool, ethIQ, and a panda MCP server to facilitate agentic workflows, enhancing the development process. The Protocol Support team established soldogn.xyz as the centralized repository for interop goals, schedules, and meeting notes, ensuring clear communication and documentation. Additionally, the EF Digital Studio team meticulously documented the entire week, promising a forthcoming documentary that will capture the essence of this significant collaborative effort.
ePBS: Reimagining Block Construction for Increased Throughput
Execution-payloads-by-builders (ePBS) represents a fundamental shift in how Ethereum blocks are constructed. This system restructures block production by introducing specific deadlines for block construction, payload revelation, and attestation finalization. By explicitly allocating time for execution within the block production cycle, ePBS significantly increases the available headroom for raising the network’s gas limit.
The week began with an ambitious goal: a fully functional 4-Execution Layer (EL) by 4-Consensus Layer (CL) Glamsterdam development network by Monday evening. The initial attempts revealed a number of critical issues, necessitating a revised target for Tuesday. By Tuesday, a 4×3 configuration was running stably enough to commence rigorous stress testing. The remainder of the week was dedicated to an intensive ePBS hardening cycle: stress testing, identifying edge cases, implementing fixes, and repeating the process.
A significant development occurred on Tuesday morning with a breakout session focused on the Builder API. This session substantially simplified the specification concerning validator registration, the flow of bids, headers, and commitments, the trust model for builder payments, and the implementation of circuit-breaker mechanisms. Mid-week debugging efforts zeroed in on cross-client edge cases, particularly concerning the invalidation of beacon requests by execution-layer requests. A newly developed test suite highlighted a critical gap across all client implementations in this area. By Thursday morning, CL teams reported stable ePBS operations, while EL-side bid pathways were still undergoing debugging. These were resolved through Thursday and into Friday. Two contentious issues remain under active discussion within the All-Core Developers (ACD) community: whether a request signature should explicitly commit to the receiving builder, and how to ensure the resilience of a 1 ETH-staked-builder design against Sybil-based liveness attacks on the peer-to-peer network. By Friday, nearly all participating clients were operating in concert on the glamsterdam-devnet-2 network, with the external builder pipeline successfully tested end-to-end.
BAL Optimizations and Gas Repricings: The Execution Layer’s Scaling Strategy
While ePBS addresses the consensus layer’s role in scaling, the execution layer’s contribution is driven by two primary components: gas repricings and Block-Level Access Lists (BALs). BALs provide clients with advance information about a block’s read and write sets, enabling critical optimizations such as parallel execution, batched I/O operations, and parallel state-root computation. These advancements directly influence the maximum block size that clients can comfortably process.
The BAL optimization track at Soldægn Interop operated on separate development networks, distinct from the Glamsterdam ePBS chains. This separation ensured that optimization benchmarks were not conflated with the complexities of stabilizing consensus-layer components. Each optimization was implemented behind a feature flag, allowing for isolated performance comparisons rather than evaluating them as a monolithic bundle. The BAL benchmark dashboard and leaderboard were instrumental in identifying the worst-case scenarios for each client across the test suite. By prioritizing and addressing the slowest execution paths, developers aimed to elevate the gas limit floor across the entire network, rather than solely benefiting the most optimized implementations.
EIP-8037, a key element of the gas repricing strategy, focuses on increasing the gas cost associated with creating new state. This adjustment is crucial to prevent an unbounded increase in state growth, even with a higher gas limit. The initial specification for EIP-8037, as it stood before Soldægn, featured dynamic per-state-byte pricing that was directly tied to the block gas limit. This dynamic approach presented significant challenges for testing, creating a combinatorial explosion of fuzz matrices for each gas limit band, and making benchmarking an arduous task. Early in the week, the development teams reached a consensus to abandon dynamic pricing in favor of a fixed cost_per_state_byte. Future repricing adjustments will be managed at future fork boundaries, rather than being dynamically determined within a single fork.
The accounting model itself underwent a more iterative refinement process. A breakout session on Monday shifted state-gas accounting from the mid-execution phase to the end of the call frame. A follow-up session on Tuesday addressed account creation costs, code deposit costs, and CREATE-transaction reverts. By Wednesday, edge cases related to reservoir refunds and refills necessitated a re-evaluation of the model. A breakout session on Thursday reverted the accounting back to the opcode level, recognizing that the primary complexity lay within the reservoir model itself, rather than the computational aspects of accounting. By Friday, the specification had stabilized on the bal-devnet-6 network, and the BAL track successfully delivered the final repricing numbers. This iterative process underscores the power of interop events, where complex specification, implementation, testing, and debugging challenges can be resolved in hours rather than weeks, compressing asynchronous progress into days.
The convergence of these three critical threads—ePBS, BAL optimizations, and gas repricings—culminated in the week’s headline achievement: the establishment of a credible target for a 200 million gas limit floor post-Glamsterdam. This substantial increase is made possible by the synergistic effect of ePBS structuring the slot to allocate more time for execution, BAL optimizations providing clients with the necessary throughput headroom within that structure, and EIP-8037 ensuring that the higher gas limit does not lead to unsustainable state growth.
Other Glamsterdam Initiatives and Future Outlook
Beyond the core components of ePBS, BALs, and gas repricings, the Soldægn Interop also addressed numerous other aspects of the Glamsterdam upgrade. Consensus Layer (CL) teams finalized decisions on several smaller EIPs slated for Glamsterdam. EIP-8061, which aims to increase exit and consolidation churn, was successfully integrated into glamsterdam-devnet-1. Conversely, EIP-8080, proposing exits via the consolidation queue, was declined for inclusion in this upgrade. EIP-8045, concerning the removal of slashed validator duties, was scoped down to apply only to proposer duties within the look-ahead window. EIP-7688, focusing on SSZ stable containers, remains within Glamsterdam’s scope but was intentionally held out of glamsterdam-devnet-1 to allow for further work on bounded gossip-message sizes for attestations under progressive lists.
A significant architectural breakout session on Wednesday morning, involving both EL and CL teams, led to the decision to defer EIP-8237 from Glamsterdam. This move preserves optionality for a more comprehensive "top-up sync" architecture in a future fork. In its place, the participants agreed to draft a new EIP that will standardize the sequencing of forkchoiceUpdated, newPayload, and getPayload calls, specify an initiation handshake for snap sync, and enhance consistency between the engine API surfaces for valid and invalid states.
Hardening and testing were pervasive themes throughout the week. A dedicated session on Thursday focused on the development of fork-choice compliance testing frameworks. The Diamond repository, a collection of reproducible CL edge-case scenarios, and buildoor, PandaOps’s external builder testing tool, were showcased. Attendees actively suggested attack scenarios in real-time, demonstrating the collaborative and responsive nature of the interop process.
Looking beyond Glamsterdam, several breakout sessions were dedicated to the Hegedas upgrade and subsequent forks. A proposal-agnostic session on native Account Abstraction explored the fundamental requirements and constraints for any future design. Key feature goals such as alternative signature schemes, aggregation, batching, recovery, gas sponsorship, flexible nonces, and keystore wallets were discussed alongside critical hard constraints like public mempool compatibility, statelessness, and L2 Denial-of-Service (DoS) resistance.
A FOCIL breakout on Thursday focused on implementation updates, with early prototypes already demonstrating functionality. The immediate next steps involve multi-client interoperation and the establishment of a dedicated FOCIL development network. Two significant design decisions were made: FOCIL will be disabled during periods of 2-epoch non-finality, mirroring the behavior of the proposer-boost circuit breaker, and an index-based bookmark approach will be adopted to ensure compatibility with frame transactions and EIP-7702.
Further into the future, an extended ETH P2P track explored the potential for a QUIC-based replacement for libp2p, emphasizing privacy-by-default and slot-aware integration. A prototype for erasure-coded broadcast demonstrated a simulated propagation speed approximately six times faster than GossipSub for 2.4 MB payloads. The CL track also indicated a strong sentiment towards eventually deprecating consolidations entirely. The proposed approach involves declaring a final fork that supports consolidations, followed by a mandatory exit-and-redeposit mechanism, presenting a cleaner long-term solution for managing validator set state growth.
Refining the All-Core-Developers Process
A pivotal session on Wednesday afternoon, led by ACDE co-leads Nixo and Ansgar, gathered input from core contributors regarding the All-Core-Developers (ACD) process. This session revisited the "headliner" construct, a mechanism for selecting major upgrade themes. The pros and cons of maintaining a "strawmap," a flexible, community-driven roadmap, were debated, and criteria for EIP Selection Framework Initiative (SFI) were formalized. The consensus favored retaining headliners but with increased flexibility regarding the rigidity of EIP-versus-theme alignment, accepting a "theme plus candidate EIP" approach as a viable pattern. The strawmap’s per-fork year assignments beyond 2026 were identified as potentially over-canonicalized and likely to be softened. A new four-point SFI definition was proposed, with ACDT (All-Core-Developers-Technical) signaling readiness and ACDE (All-Core-Developers-Execution) and ACDC (All-Core-Developers-Consensus) retaining final decision-making authority. A new prioritization and ordering process, to be determined after CFI (Core Feature Inclusion) decisions and reflected in a meta-EIP, will supersede SFI’s previous role in driving devnet inclusion, commencing with the Hegedas upgrade.
On the call coordination front, Alex Stokes announced a three-month sabbatical commencing the following week. Pari will assume ACDC moderation duties in the interim, and Barnabas will fill the role for ACDT. The current leadership structure for core developer coordination is as follows: Nixo and Ansgar chair ACDE, Pari serves as interim ACDC moderator, and Mario, Barnabas, and Danceratopz rotate ACDT moderation responsibilities.
Broader Progress and Future Endeavors
In addition to the major initiatives, the in-person gathering facilitated progress on a wide array of other crucial areas. Teams worked on enhancing test harnesses, significantly compressing Hive feedback loops from hours to minutes. Improvements were made to engine API plumbing, including gossip deduplication, batched calls, and light-client-driven head discovery. Difficult trade-offs regarding client diversity were addressed, alongside numerous other technical topics. A comprehensive list of session notes is publicly available at soldogn.xyz.
Next Steps for Ethereum Development
Following the productive Soldægn Interop, development teams will now focus on transforming the week’s prototypes into production-ready code. The coming weeks will be characterized by intensive efforts to harden client implementations against the new specifications, finalize test coverage, and integrate the draft Pull Requests from Soldægn into the main codebase.
As is customary, final decisions on key values, such as the 200 million gas limit target and specific repricing numbers, will be formally announced and shared publicly during All-Core-Developers calls. These discussions are expected to be the central focus of upcoming developer meetings.
The success of Soldægn Interop is a testament to the dedication and collaborative spirit of the Ethereum core development community. The contributions made under the Arctic sun have significantly advanced the network’s scalability roadmap, ensuring a more robust and efficient future for the Ethereum ecosystem. The forthcoming documentary promises to offer a compelling visual narrative of this critical phase in Ethereum’s ongoing evolution.
