Just over 100 Ethereum core contributors recently convened above the Arctic Circle in Longyearbyen, Svalbard, for the Soldægn Interop. This intensive, week-long gathering was dedicated to meticulously advancing the Glamsterdam network upgrade, a crucial step in scaling the Ethereum blockchain. The event, held in the unique locale of Svalbard, mirrored previous successful interop sessions like Amphora, Edelweiss, and Nyota, focusing on a single track of focused, multi-client progress toward specific upgrade objectives. The primary aim of Soldægn was to solidify the Glamsterdam network’s readiness, particularly concerning its gas limit and overall efficiency.
The Soldægn Interop followed the successful Berlinterop of the previous year, reinforcing a format that has proven effective in driving collaborative development. This concentrated approach allows developers from various client teams to work in close proximity, fostering rapid problem-solving and alignment on complex technical challenges. The remote and distinctive setting of Longyearbyen, a Norwegian archipelago town, served not only as a backdrop but also as a symbolic choice, aligning with Ethereum’s ethos of resilience and long-term vision.
By the conclusion of the Soldægn Interop on Friday, the assembled core contributors achieved three pivotal goals. Firstly, they established a consensus on a post-Glamsterdam gas limit floor of 200 million gas. This significant increase is a direct outcome of the week’s technical advancements, aimed at enhancing Ethereum’s transaction processing capacity. Secondly, the event saw the deployment and stabilization of external proposer-builder separation (ePBS) implementations, a critical component for improving block production efficiency. Finally, definitive repricing numbers for Ethereum Improvement Proposal (EIP) 8037 were finalized, ensuring that the increased gas limit does not lead to uncontrolled state growth. Beyond these headline achievements, substantial progress was also made on upcoming features for the Hegotæ fork, including the development of FOCIL (Fork Choice Interface Layer) and native account abstraction functionalities, alongside discussions on numerous other technical topics.
The Strategic Significance of Svalbard
The choice of Svalbard as the venue for the Soldægn Interop was deliberate and multifaceted. Svalbard holds a unique position as one of the few locations globally where individuals of any nationality can reside and work without visa requirements, fostering an environment of international collaboration. More profoundly, the archipelago is home to the Global Seed Vault and the Arctic World Archive. These are sophisticated cold-storage facilities, ingeniously tunneled into the permafrost near Longyearbyen. They serve as crucial repositories for humanity’s most valuable data, including backups of vital crops, historical records, cultural artifacts, and critical source code. Notably, a snapshot of Ethereum’s source code is also preserved within the Arctic World Archive, underscoring the network’s commitment to long-term data integrity and preservation.
Furthermore, Svalbard experiences the phenomenon of the midnight sun from late April through August, meaning the sun does not set during this period. This constant daylight, offering 24/7 uptime, provided a fitting metaphor for Ethereum’s own continuous operation and the relentless dedication of its core developers who capitalized on the extended daylight hours to maximize their productive time during the week. This unique environmental factor likely contributed to the intense focus and extended working hours observed throughout the event.
Hardening Glamsterdam and Scaling Ethereum
The overarching objective of the Soldægn Interop was to rigorously harden the Glamsterdam network upgrade and to establish a clear target for its post-upgrade gas limit floor. The challenge of safely increasing the gas limit is a complex, multi-dimensional problem that Glamsterdam is designed to address. Key areas of focus include optimizing how blocks are constructed and proposed, ensuring that client implementations have sufficient headroom under peak load conditions, and managing the scalability of state-creation costs in tandem with increased throughput.
In practical terms, the week’s efforts culminated in a stable, multi-client Glamsterdam development network (devnet) that successfully integrated the latest ePBS implementations, alongside updated block access list specifications and comprehensive benchmarking data. This data is instrumental in anchoring a credible proposal for the gas limit increase. Much of the intensive work involved developers dedicating long hours, often into the early morning, to writing code. These coding sessions were punctuated by breakout discussions aimed at aligning on design decisions and strategizing for longer-term roadmap items.
Three key teams from the Ethereum Foundation (EF) provided essential infrastructure to support the interop week. EthPandaOps deployed ethIQ, a performance monitoring tool, and a Panda Message Communication Protocol (MCP) server to facilitate agentic workflows for the participating teams. The Protocol Support team established soldogn.xyz as the central hub for interop goals, schedules, and documentation, serving as the single source of truth for the event. The EF Digital Studio team meticulously documented the week’s activities, promising the release of the first-ever interop documentary, offering a unique visual record of this significant development milestone.
Advancements in ePBS
The implementation of ePBS represents a significant architectural shift within Ethereum’s consensus layer. Beyond refining the relationship between block proposers and builders, ePBS restructures the slot by introducing explicit deadlines for block construction, payload revelation, and attestation submission. This formalization allocates dedicated time for execution processes, thereby increasing the available headroom for raising the gas limit.
The week commenced with teams aiming to establish a four-execution-layer (EL) to four-consensus-layer (CL) Glamsterdam devnet by Monday evening. The initial attempts revealed numerous issues, necessitating a revised target of Tuesday for a stable 4×3 configuration, which then allowed stress testing to commence. The remainder of the week was dedicated to an ePBS hardening cycle: stress testing, identifying edge cases, implementing fixes, and repeating the process. A breakout session on Tuesday morning significantly simplified the Builder API specification, clarifying validator registration, the bid/header/commitments flow, the trust model for builder payments, and circuit-breaker mechanisms. Mid-week debugging efforts focused on cross-client edge cases, particularly concerning the invalidation of beacon requests triggered by execution layer requests. A newly developed test suite exposed inconsistencies 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, with resolutions achieved through Thursday and into Friday. Two contentious issues remained for the AllCoreDevs (ACD) discussions: 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 clients were successfully running on glamsterdam-devnet-2, with the external builder pipeline tested end-to-end.
Block-Level Access List (BAL) Optimizations
If ePBS represents the consensus layer’s contribution to Glamsterdam’s scaling strategy, the execution layer’s parallel efforts are centered on 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 crucial optimizations such as parallel execution, batched I/O operations, and parallel state-root computation. These advancements are fundamental to determining the maximum block size that clients can comfortably process.
The BAL track at Soldægn operated on separate devnets, distinct from the Glamsterdam ePBS chains, ensuring that optimization benchmarks were not conflated with consensus layer stabilization efforts. Each optimization was implemented behind a feature flag, allowing for isolated comparison of performance in a single bundle. The BAL benchmark dashboard and leaderboard highlighted each client’s worst-case scenarios across the test suite. By focusing on improving the slowest execution paths first, teams were able to elevate the gas limit floor across the board, rather than solely benefiting the most performant implementations.
Gas Repricing Refinements
Glamsterdam incorporates several EL gas repricings designed to align costs more accurately with resource utilization at higher throughput levels. EIP-8037, which proposes an increase in state-creation gas costs, is central to this effort. By raising the price of creating new state, it ensures that a higher gas limit does not result in unbounded state growth.
Prior to Soldægn, the EIP-8037 specification featured dynamic per-state-byte pricing, which was contingent on the block gas limit. This dynamic nature presented significant challenges for testing, requiring a complex fuzz matrix for each gas limit band, and made benchmarking nearly intractable. Early in the week, participants agreed to abandon dynamic pricing in favor of a fixed cost_per_state_byte. Future repricing adjustments will be handled at fork boundaries rather than within a given fork.
The accounting model itself underwent an iterative development process. A breakout session on Monday shifted state-gas accounting from mid-execution to the end of the call frame. 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. A breakout session on Thursday reverted the accounting to the opcode level, recognizing that the core complexity resided within the reservoir model rather than the accounting computation itself. By Friday, the specification had stabilized on bal-devnet-6, with the BAL track delivering the finalized repricing numbers. This entire process exemplifies the critical role of interop weeks in resolving complex specification, implementation, testing, debugging, and design issues within hours rather than weeks, compressing asynchronous progress into concentrated daily advancements.
The convergence of these three critical threads—ePBS, BALs, and gas repricings—culminated in the week’s headline achievement: the establishment of a credible 200 million gas limit floor for the post-Glamsterdam era. This substantial increase is made possible by ePBS, which structures the slot to allocate more time for execution; BAL optimizations, which provide clients with the necessary throughput headroom within that structure; and EIP-8037, which ensures that the elevated gas limit does not lead to runaway state growth.
Other Glamsterdam Development Threads
Beyond the core advancements in ePBS, BALs, and gas repricings, the Soldægn Interop addressed numerous other aspects of the Glamsterdam upgrade through dedicated 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, concerning exits via the consolidation queue, was declined for inclusion in this upgrade. EIP-8045, aimed at removing slashed validator duties, was scoped down to apply only to proposer duties within the look-ahead window. EIP-7688, focused on SSZ stable containers, remains within Glamsterdam’s scope but was held out of glamsterdam-devnet-1 while the team addressed bounded gossip message sizes for attestations under progressive lists.
A synchronization breakout session on Wednesday morning involving both EL and CL teams resulted in the deferral of EIP-8237 from Glamsterdam. This decision preserves optionality for a more extended "top-up sync" architecture in a future fork. In its place, the group agreed to draft an EIP that standardizes the sequencing of forkchoiceUpdated, newPayload, and getPayload calls, defines a handshake for snap-sync initiation, and enhances consistency between the engine API surfaces for valid and invalid states.
Hardening and testing were continuous themes throughout the week. A session on Thursday focused on fork-choice compliance testing frameworks, the Diamond repository, which houses reproducible CL edge-case scenarios, and buildoor, EthPandaOps’s external builder testing tool. Demonstrations of buildoor were met with a stream of attack scenarios suggested by attendees in real-time.
Looking Beyond Glamsterdam: Hegotæ and Future Forks
Several breakout sessions at Soldægn were dedicated to examining progress toward Hegotæ and subsequent forks. A deliberately proposal-agnostic session on native Account Abstraction initiated discussions on the requirements and constraints that any future design must satisfy. Feature set goals included support for alternative signature schemes, aggregation, batching, recovery, gas sponsorship, flexible nonces, and keystore wallets. These were juxtaposed with critical hard constraints such as public mempool compatibility, statelessness, and Layer 2 denial-of-service resistance.
A dedicated FOCIL breakout on Thursday focused on implementation updates. Early prototypes demonstrated functional capabilities, with multi-client interop and a dedicated FOCIL devnet identified as immediate next steps. Two significant design decisions were made: disabling FOCIL during two-epoch non-finality periods, mirroring proposer-boost circuit-breaker behavior, and adopting an index-based bookmark approach for compatibility with frame transactions and EIP-7702.
Further into the future, a long-running ETH P2P track explored the potential for a QUIC-based replacement for libp2p, incorporating privacy-by-default features and slot-aware integration. An erasure-coded broadcast prototype was also presented, simulating approximately six times faster propagation than GossipSub on 2.4 MB payloads. The CL track also surfaced 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 procedure, seen as a cleaner long-term solution for managing validator set state growth.
Refining the AllCoreDevs Process
On Wednesday afternoon, Nixo and Ansgar, the co-leads of the AllCoreDevs (ACD) working group, convened a session to gather input from core contributors regarding the ACD process. This session revisited the "headliner" construct, debated the merits of maintaining a strawmap, and formalized the criteria for EIP selection (EIP SFI). The consensus favored retaining headliners but with a more flexible approach to EIP-versus-theme rigidity, accepting a "theme plus candidate EIP" pattern as a viable option. The per-fork year assignments in the strawmap beyond 2026 were flagged as overly canonicalized and likely to be softened. A new four-point SFI definition was proposed, with the AllCoreDevs Technical Decision-Makers (ACDT) signaling readiness and the AllCoreDevs Execution (ACDE) and AllCoreDevs Coordination (ACDC) retaining the final decision-making authority. A new prioritization-ordering process, to be implemented after CFI decisions and reflected in the meta-EIP, will replace the former role of SFI 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 cover for ACDT. The finalized coordination roles are: Nixo and Ansgar will chair ACDE; Pari will serve as interim ACDC moderator; and Mario, Barnabas, and Danceratopz will rotate ACDT moderation responsibilities.
Comprehensive Progress Across All Fronts
In addition to the major advancements detailed above, participating teams leveraged the in-person collaboration to make significant progress on a wide array of other topics. These included improvements to test harnesses, such as compressing Hive feedback loops from hours to mere minutes, enhancing engine API plumbing with features like gossip deduplication, batched calls, and light-client-driven head discovery, and navigating difficult trade-offs concerning client diversity. The complete list of session notes from the Soldægn Interop is available on soldogn.xyz.
Next Steps and Future Outlook
Following the Soldægn Interop, the teams are now returning to their respective bases to transform the week’s prototypes into production-ready code. The coming weeks will be characterized by intensive efforts to harden client implementations against the newly established specifications, finalize test coverage, and integrate the draft pull requests from Soldægn into the codebase.
As is customary, final decisions on key values, such as the 200 million gas limit target and precise repricing figures, will be made and publicly communicated during AllCoreDevs calls. These decisions are anticipated to be the primary focus of upcoming discussions.
The success of the Soldægn Interop is a testament to the dedication of the over 100 core contributors who traveled to the high Arctic. Special acknowledgment is due to EthPandaOps for their role in organizing and motivating the group daily, and to all who worked tirelessly under the midnight sun to ensure daily goals were met. The inclusion of the Ethrex crew, attending their first interop, was also a significant addition. The week was remarkably productive, and the forthcoming documentary promises a compelling record of this pivotal development milestone.
