Ethereum core developers, numbering just over 100, recently gathered in the remote and striking locale of Longyearbyen, Svalbard, situated above the Arctic Circle, for the Soldægn Interop event. This intensive week-long summit was dedicated to advancing the crucial "Glamsterdam" network upgrade, a pivotal step in Ethereum’s ongoing evolution toward enhanced scalability and efficiency. The Soldægn Interop followed the precedent set by last year’s Berlinterop and returned to the highly effective, single-track format previously employed during the Amphora, Edelweiss, and Nyota interop events. This concentrated approach prioritizes multi-client collaboration and focused development toward specific upgrade objectives, with this iteration centering on the critical task of hardening the Glamsterdam network.
The strategic decision to host this pivotal gathering in Svalbard, a location known for its unique geopolitical status as one of the few places globally where individuals can reside and work irrespective of nationality without visa requirements, underscores a deliberate choice for an environment conducive to deep, uninterrupted work. Svalbard’s remoteness minimizes external distractions, allowing the brightest minds in Ethereum development to immerse themselves fully in the complex technical challenges at hand. Furthermore, the region’s association with long-term data preservation, housing the Global Seed Vault and the Arctic World Archive, subtly resonates with Ethereum’s mission to build a decentralized and resilient digital future. The extended daylight hours during the Arctic summer, with the sun not setting from late April through August, provided a symbolic and practical backdrop, mirroring the 24/7 uptime characteristic of the Ethereum network itself – a constant availability that core developers worked tirelessly to maintain and improve.
By the conclusion of the Soldægn Interop on Friday, the assembled group had achieved significant milestones, successfully meeting three primary objectives. Firstly, there was robust alignment on a post-Glamsterdam gas limit floor set at a substantial 200 million gas. This figure represents a considerable increase over current limits and is a direct outcome of the week’s collaborative efforts to safely and effectively scale Ethereum’s transaction throughput. Secondly, stable implementations of Proposer-Builder Separation (PBS), specifically the execution layer PBS (ePBS) variant, were demonstrated running in conjunction with external builders. This advancement is crucial for optimizing block production and incentivizing efficient block construction. Lastly, the final repricing numbers for Ethereum Improvement Proposal (EIP) 8037, which addresses state creation costs, were locked in. Beyond these core deliverables, substantial progress was also reported on future-facing features, including elements of the Hegotä fork such as Forward Compression Layer (FOCIL) and native account abstraction, alongside a broad spectrum of other critical development topics.
Hardening Glamsterdam for Enhanced Scalability
The overarching goal of the Soldægn Interop was to solidify the technical foundations of the Glamsterdam upgrade and to establish a well-defined target for the network’s gas limit post-implementation. Safely increasing Ethereum’s gas limit is a multifaceted challenge, and the Glamsterdam upgrade directly addresses several key aspects. These include refining the mechanisms by which blocks are constructed and proposed, enhancing the headroom available to client implementations under varying network loads, and ensuring that the cost of state creation scales appropriately with increased transaction throughput.
In practical terms, the week’s intense coding and collaborative sessions culminated in a stable multi-client Glamsterdam development network (devnet). This devnet was configured to run the latest ePBS integrations, incorporate finalized specifications for repricing and block access lists, and generate crucial benchmarking data. This data serves as the bedrock for proposing a credible and sustainable gas limit increase. The development process itself was characterized by deep, focused work, often extending into the early morning hours. These periods of intense coding were interspersed with targeted breakout sessions, crucial for achieving consensus on design decisions and for mapping out longer-term roadmap initiatives.
The Ethereum Foundation (EF) played a crucial supporting role in facilitating the interop week. Three distinct EF teams provided essential infrastructure and services. EthPandaOps deployed their ethIQ performance monitoring tool and a dedicated panda Meta-Control Plane (MCP) server, significantly aiding teams in managing their agentic workflows and analyzing performance data. The Protocol Support team established soldogn.xyz as the central repository for all interop goals, schedules, and meeting notes, ensuring a single source of truth for participants. Finally, the EF Digital Studio team documented the entire week through video, promising the release of the very first interop documentary, offering a unique behind-the-scenes look at this critical development process.
ePBS: Revolutionizing Block Production
The ePBS initiative represents a fundamental restructuring of how Ethereum slots are managed, introducing explicit deadlines for block construction, payload reveal, and attestation finalization. This structured approach provides greater certainty regarding the time allocated for execution, thereby expanding the potential headroom for increasing the gas limit.
The week commenced with an ambitious target: achieving a stable 4 execution layer (EL) and 4 consensus layer (CL) Glamsterdam devnet by Monday evening. Initial attempts, however, revealed a number of challenges, necessitating a revised target of 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 test, identify edge cases, implement fixes, and repeat. A significant breakthrough occurred during a Tuesday-morning breakout session focused on the Builder API, which led to a substantial simplification of the specifications governing 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 identified 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. These issues were largely resolved by Thursday and Friday. Two technically contentious points for All-Core-Developers (ACD) discussions remained: 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 Friday, nearly all participating clients were successfully running on glamsterdam-devnet-2, with the external builder pipeline tested end-to-end, marking a significant achievement for the ePBS component of the upgrade.
BAL Optimizations: Enhancing Execution Layer Efficiency
Complementing ePBS on the consensus layer, the execution layer’s scaling strategy for Glamsterdam hinges on two primary advancements: gas repricings and Block-Level Access Lists (BALs), as outlined in EIP-7928. By providing clients with upfront information about a block’s read and write sets, BALs enable critical optimizations such as parallel execution, batched input/output operations, and parallel state-root computation. These enhancements directly contribute to a client’s capacity to comfortably handle larger blocks.
The BAL track at Soldægn operated on separate devnets, distinct from the Glamsterdam ePBS chains, ensuring that optimization benchmarks were not influenced by the complexities of consensus layer stabilization. Each optimization was implemented behind a feature flag, allowing for isolated comparative analysis rather than being bundled. The dedicated BAL benchmark dashboard and leaderboard effectively highlighted each client’s worst-case performance scenarios across the test suite. By prioritizing the improvement of the slowest execution paths, developers aimed to elevate the gas limit floor uniformly across all implementations, rather than solely benefiting the most optimized clients.
Gas Repricings: Calibrating Costs for Higher Throughput
Glamsterdam incorporates several crucial gas repricings designed to better align transaction costs with resource utilization at higher throughput levels. At the heart of this effort is EIP-8037, which significantly increases the gas cost associated with writing new state. This measure is critical to prevent a higher gas limit from leading to unbounded state growth on the network.
Prior to Soldægn, the EIP-8037 specification featured dynamic per-state-byte pricing that was directly tied to the block gas limit. This dynamic approach presented considerable challenges for testing, requiring extensive fuzz matrices for different gas limit bands and making benchmarking nearly intractable. Early in the week, participants agreed to transition away from dynamic pricing in favor of a fixed cost_per_state_byte. Future repricing adjustments will be managed at fork boundaries, rather than dynamically within a fork.
The accounting model itself underwent a more iterative development process. An initial breakout session on Monday shifted state-gas accounting from the mid-execution phase to the end of the call frame. A subsequent session on Tuesday addressed account creation costs, code deposit costs, and the handling of CREATE transaction reverts. By Wednesday, edge cases related to reservoir refund and refill mechanisms necessitated a re-evaluation of the entire model. A breakout session on Thursday reverted the accounting approach to the opcode level, recognizing that the true complexity resided within the reservoir model rather than the accounting computation itself. By Friday, the specification had stabilized on bal-devnet-6, and the BAL track successfully delivered the final repricing numbers.
This intensive, iterative process exemplifies the power of interop events. The ability to resolve complex specification, implementation, testing, debugging, and design issues in a matter of hours, rather than weeks, significantly accelerates development velocity. At their most effective, interop weeks can compress a month’s worth of asynchronous progress into each day.
The convergence of these three critical development threads—ePBS, BAL optimizations, and gas repricings—culminated in the week’s headline achievement: a credible target of a 200 million gas limit floor for the post-Glamsterdam era. This substantial increase is attainable due to the synergistic effects of ePBS, which structurally allocates more time for execution; BAL optimizations, which provide clients with the necessary throughput headroom within that structure; and EIP-8037, which ensures that the higher gas limit does not lead to uncontrolled state expansion.
Other Glamsterdam Development Threads
Beyond the primary focus on ePBS, BALs, and gas repricings, the remaining scope of the Glamsterdam upgrade was addressed across numerous breakout sessions. Consensus layer teams finalized decisions on several smaller Glamsterdam EIPs. EIP-8061, which aims to increase exit and consolidation churn, was integrated into glamsterdam-devnet-1. However, EIP-8080, concerning exits via the consolidation queue, was declined for inclusion in this upgrade. EIP-8045, which proposes the removal of slashed validator duties, was scoped down to only apply to proposer duties within the look-ahead window. EIP-7688, introducing SSZ stable containers, remains within the Glamsterdam scope but was held out of glamsterdam-devnet-1 while the team addressed the complexities of bounded gossip message sizes for attestations under progressive lists.
A critical EL/CL synchronization architecture breakout session on Wednesday morning resulted in the decision to defer EIP-8237 out of the Glamsterdam upgrade. This deferral 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, define a handshake protocol for snap-sync initiation, and improve consistency between the engine API surfaces for valid and invalid states.
Hardening and testing remained a pervasive theme throughout the week. A dedicated session on Thursday explored frameworks for fork-choice compliance testing. The Diamond repository, which houses reproducible CL edge-case scenarios, and buildoor, PandaOps’s external builder testing tool, were showcased. During the buildoor demonstration, attendees actively suggested attack scenarios in real-time, providing valuable feedback for further development and robustness testing.
Looking Ahead: Hegotä and Future Forks
Several breakout sessions at Soldægn turned their attention to Hegotä and subsequent forks, outlining the future trajectory of Ethereum’s development. A deliberately proposal-agnostic session on native Account Abstraction initiated discussions on the essential requirements and constraints that any future design must satisfy. This included desired feature sets such as alternative signature schemes, aggregation and batching capabilities, recovery mechanisms, gas sponsorship, flexible nonces, and keystore wallets. These were balanced against critical hard constraints, including public mempool compatibility, statelessness, and Layer 2 Denial-of-Service (DoS) resistance.
A dedicated FOCIL breakout session on Thursday focused on implementation updates. Early prototypes for FOCIL were already functional, with multi-client interop and the establishment of a dedicated FOCIL devnet identified as the immediate next steps. Two significant design decisions were also reached: FOCIL will be disabled during periods of two-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.
Looking further ahead, a long-running ETH P2P track explored the potential for a QUIC-based replacement for libp2p. This envisioned protocol would feature privacy-by-default settings and slot-aware integration. Additionally, a prototype for erasure-coded broadcast demonstrated a simulated propagation speed approximately six times faster than GossipSub on 2.4 MB payloads. The CL track also revealed a strong sentiment toward the eventual deprecation of consolidations entirely. The proposed approach involves declaring a final fork that supports them, followed by a mandatory exit-and-redeposit mechanism, which is seen as a cleaner long-term solution for managing validator set state growth.
Refining the All-Core-Devs Process
On Wednesday afternoon, the two ACDE co-leads, Nixo and Ansgar, facilitated a session to gather input from core contributors regarding the All-Core-Devs (ACD) process. This discussion revisited the "headliner" construct, debated the merits of maintaining a strawmap, and formalized the criteria for EIP Special Fork Inclusion (SFI). The consensus leaned towards retaining headliners but with greater flexibility regarding the rigidity of EIP-versus-theme alignment, accepting a "theme plus candidate EIP" model as a viable approach. The per-fork year assignments on the strawmap beyond 2026 were identified as potentially over-canonicalized and likely to be softened. A new four-point SFI definition was proposed, with the All-Core-Devs Technical (ACDT) signaling readiness and the All-Core-Devs Execution (ACDE) and All-Core-Devs Consensus (ACDC) retaining final decision-making authority. A new prioritization and ordering process, to be determined after CFI decisions and reflected in a meta-EIP, will supersede SFI’s previous role in driving devnet inclusion, commencing with the Hegotä fork.
In terms of call coordination, Alex Stokes announced a three-month sabbatical commencing the following week. Pari will assume ACDC moderation duties during this interim period, and Barnabas will step in for ACDT. The current leadership structure involves Nixo and Ansgar chairing ACDE, Pari acting as interim ACDC moderator, and Mario, Barnabas, and Danceratopz rotating ACDT moderation responsibilities.
Progress Across the Board
In addition to the major advancements discussed, teams utilized the in-person gathering to make progress on a wide array of other critical areas. This included developing improved test harnesses, significantly compressing Hive feedback loops from hours to mere minutes. Enhancements to engine API plumbing were also pursued, encompassing gossip deduplication, batched calls, and light-client-driven head discovery. Furthermore, challenging tradeoffs concerning client diversity were addressed, alongside numerous other topics. A comprehensive list of session notes is publicly available on soldogn.xyz.
Next Steps: From Interop to Implementation
Following the Soldægn Interop, development teams will now transition from prototyping to production-readiness. The coming weeks will see intensive efforts focused on hardening client implementations against the newly established specifications, finalizing test coverage, and integrating the draft Pull Requests from Soldægn into the main codebase.
As is customary, final decisions regarding key values, such as the 200 million gas limit target and precise repricing figures, will be publicly communicated and debated during AllCoreDevs calls. These critical decisions are expected to be the primary focus of upcoming discussions.
The success of the Soldægn Interop is a testament to the dedication and collaborative spirit of the Ethereum core development community. The commitment of over 100 contributors who traveled to the extreme northern latitude of 78°N was instrumental in achieving the week’s ambitious goals. Special acknowledgment is due to EthPandaOps for their daily efforts in guiding and supporting the group, and to all those who worked diligently under the perpetual daylight of the Arctic summer to meet daily objectives. The participation of the Ethrex crew, marking their first interop event, was also a welcome addition. The week was exceptionally productive, and the anticipation for the forthcoming short film documenting the event promises a valuable record of this critical phase in Ethereum’s development.
