This past week, over 100 Ethereum core contributors convened in the remote and breathtaking landscape of Longyearbyen, Svalbard, located just over 78 degrees north of the Arctic Circle. This gathering, dubbed Soldægn Interop, was a week of intensive, collaborative work focused on advancing the critical Glamsterdam network upgrade. The event marks a significant milestone in Ethereum’s ongoing journey toward enhanced scalability and robustness, with tangible outcomes that promise to reshape the network’s future.
Soldægn Interop built upon the precedent set by last year’s Berlinterop, returning to a concentrated, single-track format reminiscent of earlier successful interop events such as Amphora, Edelweiss, and Nyota. This focused approach allows developers to dedicate their collective expertise to a specific, high-priority upgrade. In this instance, the primary objective was the comprehensive hardening of the Glamsterdam network upgrade, a pivotal step in increasing Ethereum’s transaction throughput and overall efficiency.
By the culmination of the week on Friday, the core contributors had achieved three pivotal goals: establishing consensus on a post-Glamsterdam gas limit floor of 200 million, ensuring stable implementations of proposer-builder separation (ePBS) operating with external builders, and finalizing the repricing numbers for EIP-8037. Beyond these headline achievements, substantial progress was also made on forward-looking features such as FOCIL and native account abstraction, alongside a broad spectrum of other critical development threads.
Why Svalbard? A Unique Setting for Critical Development
The choice of Longyearbyen, Svalbard, as the venue for Soldægn Interop was deliberate and imbued with symbolic significance. Svalbard holds the unique distinction of being one of the few locations globally where individuals of any nationality can reside and work without requiring a visa. More profoundly, it is home to two vital long-term data repositories: the Global Seed Vault and the Arctic World Archive. These facilities, tunneled deep into the permafrost, serve as digital and physical backups of humanity’s most precious cultural and biological heritage, including a snapshot of Ethereum’s source code. This commitment to long-term preservation mirrors Ethereum’s own mission to build a resilient and enduring decentralized network.
Furthermore, Svalbard experiences the phenomenon of the midnight sun from late April through August, meaning the sun never sets. This continuous daylight, mirroring Ethereum’s own 24/7 operational uptime, provided a fitting and inspiring backdrop for the core developers who worked tirelessly throughout the week to ensure the network’s perpetual availability and enhanced performance.
Harden Glamsterdam, Scale Ethereum: The Core Mission
The central mandate of the Soldægn Interop was to solidify the technical underpinnings of the Glamsterdam upgrade and, critically, to define a sustainable target for the network’s gas limit in the post-upgrade era. Raising the gas limit is a complex, multi-faceted challenge. Glamsterdam addresses several key aspects of this challenge, including the intricate processes of block construction and proposal, the operational headroom available to client implementations under heavy load, and the scaling dynamics of state creation costs in conjunction with increased throughput.
The practical outcome of this intensive week was the establishment of a stable, multi-client Glamsterdam development network. This network was equipped to run the latest ePBS implementations, incorporate finalized block access list (BAL) specifications, and provide robust benchmarking data. This data serves as the bedrock for proposing a credible and achievable gas limit increase, a crucial step for enhancing Ethereum’s scalability.
The majority of the participants’ time was dedicated to hands-on coding and intricate problem-solving, often extending into the early hours of the morning. These deep work sessions were strategically interspersed with focused breakout discussions to foster alignment on design decisions and to deliberate on the long-term roadmap for the Ethereum protocol.
Three dedicated teams from the Ethereum Foundation (EF) provided essential infrastructure and support throughout the week. EthPandaOps was instrumental in deploying ethIQ, a performance monitoring tool, and a panda MCP server designed to streamline agentic workflows for the development teams. The Protocol Support team established soldogn.xyz as the authoritative source for interop goals, the event schedule, and comprehensive meeting notes. Additionally, the EF Digital Studio team meticulously documented the entire week, promising the release of what is anticipated to be the inaugural documentary on Ethereum’s interop process.
ePBS: Revolutionizing Block Construction and Proposer-Builder Dynamics
A significant portion of the Soldægn Interop was dedicated to the evolution of proposer-builder separation (ePBS). Beyond refining the existing proposer-builder relationship, ePBS fundamentally restructures Ethereum slots by introducing explicit deadlines for block construction, payload verification, and attestation submission. This structured approach provides greater clarity on the time allocated for execution, thereby creating additional headroom for a potential increase in the gas limit.
The week commenced with an ambitious target: a stable 4 execution layer (EL) and 4 consensus layer (CL) Glamsterdam development network by Monday evening. Initial attempts to meet this goal revealed several critical issues, necessitating a revised target of Tuesday for a stable 4×3 configuration, which then allowed for the commencement of stress testing.
The remainder of the week was consumed by a rigorous ePBS hardening cycle: intensive stress testing, identification of edge cases, implementation of fixes, and repetition. A breakout session on Tuesday morning significantly streamlined the Builder API specification, clarifying validator registration, the bid/header/commitments flow, the trust model for builder payments, and circuit-breaker functionalities. 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 operation, while EL-side bid pathways were still undergoing debugging, with resolutions achieved by Thursday and Friday. Two contentious questions remain under active discussion within the AllCoreDevs (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 Peer-to-Peer Sybil-based liveness attacks.
By the close of the week, nearly all participating clients were operating in unison on glamsterdam-devnet-2, with the external builder pipeline successfully tested end-to-end, marking a major stride towards a more robust and scalable Ethereum.
BAL Optimizations and Gas Repricings: Enhancing Execution Layer Efficiency
While ePBS represents the consensus layer’s contribution to Glamsterdam’s scaling strategy, the execution layer’s counterpart comprises two primary components: gas repricings and Block-Level Access Lists (BALs). By providing clients with detailed upfront information about a block’s read and write sets, BALs unlock the potential for parallel execution, batched I/O operations, and parallel state-root computations. These optimizations are fundamental to determining the maximum block size that clients can comfortably process.
The BAL track at Soldægn operated on separate development networks, distinct from the Glamsterdam ePBS chains, to prevent entanglement of optimization benchmarks with the stabilization of consensus layer work. Each optimization was implemented behind its own feature flag, allowing for isolated comparison of their performance during the week’s measurement activities. The BAL benchmark dashboard and leaderboard were crucial in identifying each client’s worst-case scenarios across the test suite. By prioritizing and improving the slowest execution paths, developers aimed to elevate the gas limit floor across the entire network, rather than benefiting only the fastest implementations.
Central to the gas repricing effort is EIP-8037, which addresses the state-creation gas cost. This EIP significantly increases the cost of writing new state, ensuring that a higher gas limit does not lead to unbounded state growth on the network.
Leading into Soldægn, the EIP-8037 specification featured dynamic per-state-byte pricing that was intrinsically linked to the block gas limit. This approach presented significant challenges for testing, requiring a separate fuzz matrix for each gas limit band, and made benchmarking nearly intractable. 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 fork boundaries rather than within a fork.
The accounting model itself underwent a more iterative development process. An initial breakout session on Monday shifted state-gas accounting from mid-execution to the end of call frames. A subsequent session on Tuesday addressed account creation costs, code deposit costs, and CREATE transaction reverts. On Wednesday, edge cases related to reservoir refunding and refilling necessitated a re-evaluation of the model. By Thursday, the accounting structure reverted to the opcode level, with the realization that the primary complexity resided within the reservoir model, not the computational aspects of accounting. By Friday, the specification had stabilized on bal-devnet-6, and the BAL track delivered the final repricing numbers.
This entire development arc underscores a crucial aspect of interop events: the capacity to resolve complex specification, implementation, testing, debugging, and design issues within hours rather than weeks. At their most effective, interop weeks can compress months of asynchronous progress into daily achievements.
Ultimately, the convergence of these three critical threads—ePBS, BAL optimizations, and gas repricings—culminated in the week’s most significant outcome: a credible target for a 200 million gas limit floor post-Glamsterdam. This substantial increase in capacity is made possible by the structural improvements introduced by ePBS, which allocates more time for execution within each slot. BAL optimizations equip clients with the necessary throughput headroom within this new structure, and EIP-8037 ensures that the increased gas limit does not lead to uncontrolled state expansion.
Other Glamsterdam Threads: Refining the Upgrade
Beyond the core components of ePBS, BALs, and repricings, the remaining scope of the Glamsterdam upgrade was meticulously addressed across numerous breakout sessions. Consensus layer (CL) teams finalized decisions on several smaller Glamsterdam EIPs. EIP-8061, which proposes an increase in exit and consolidation churn, was successfully integrated into glamsterdam-devnet-1. EIP-8080, enabling exits via the consolidation queue, was ultimately 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 held out of glamsterdam-devnet-1 to allow for the resolution of issues related to bounded gossip message sizes for attestations under progressive lists.
A significant architectural breakout session on Wednesday morning, involving both EL and CL teams, resulted in the deferral of EIP-8237 from the Glamsterdam upgrade. This decision 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 the consistency of valid/invalid status between the engine API surfaces.
Hardening and ensuring network resilience were constant themes throughout the week. A dedicated session on Thursday explored frameworks for fork-choice compliance testing. The diamond repository, a collection of reproducible CL edge-case scenarios, was highlighted as a key resource. Furthermore, buildoor, PandaOps’s tool for external builder testing, was demonstrated mid-session, with attendees actively suggesting attack scenarios in real-time, showcasing the collaborative and iterative nature of the development process.
Looking Beyond Glamsterdam: The Road Ahead
Several breakout sessions at Soldægn were dedicated to peering further into the future, focusing on the Hegotæ hegotæ
