In a testament to their dedication to the continuous evolution of the Ethereum network, over one hundred core contributors converged in Longyearbyen, Svalbard, for the Soldægn Interop. This intensive week-long gathering, held just above the Arctic Circle, was laser-focused on advancing the network’s capabilities, particularly in preparation for the upcoming "Glamsterdam" network upgrade. The event built upon the success of previous interop initiatives like Berlinterop, Amphora, Edelweiss, and Nyota, reinforcing a collaborative, single-track approach to achieving critical developmental milestones.
The primary objective of Soldægn was to "harden Glamsterdam," a crucial phase aimed at enhancing the network’s scalability and efficiency. By Friday, the core developers had successfully met their three main goals: establishing a firm 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, significant headway was also made on features slated for the subsequent "Hegotæ" upgrade, including advancements in Fully Optimistic Cross-chain Interoperability Layer (FOCIL) and native account abstraction, alongside a broad spectrum of other technical discussions.
The Strategic Choice of Svalbard
The selection of Longyearbyen, Svalbard, as the venue for this pivotal event was far from arbitrary. This remote Norwegian archipelago holds a unique global significance, offering a neutral ground where individuals from any nation can reside and work without visa requirements, fostering an environment of open collaboration. Furthermore, Svalbard is home to the Svalbard Global Seed Vault and the Arctic World Archive. These remarkable cold-storage facilities, tunneled deep into the permafrost, serve as humanity’s safeguard for vital data, preserving backups of agricultural biodiversity, cultural heritage, and even critical software source code for millennia. Notably, a snapshot of Ethereum’s own source code resides within the Arctic World Archive, symbolizing the network’s commitment to long-term preservation and innovation.
The geographical location also provided an unusual, yet fitting, operational advantage. From late April through August, Svalbard experiences the phenomenon of the midnight sun, meaning daylight persists for 24 hours a day. This perpetual uptime mirrored the always-on nature of the Ethereum network itself, a parallel that the core developers embraced, maximizing their productive hours under the continuous Arctic light.
Hardening Glamsterdam: The Path to Scalability
The overarching goal of the Soldægn Interop was to solidify the Glamsterdam network upgrade and define a clear target for its post-implementation gas limit. Raising the gas limit, a key metric for transaction throughput, is a complex, multi-faceted challenge. Glamsterdam addresses several critical aspects of this challenge: it redefines how blocks are constructed and proposed, enhances the headroom available to client implementations under peak load, and meticulously manages how state creation costs scale in tandem with increased throughput.
In practical terms, the week’s intensive work culminated in a stable, multi-client Glamsterdam development network (devnet). This devnet was configured to run the latest iterations of ePBS, along with specifications for repricing and block access lists. Crucially, it generated comprehensive benchmarking data, providing a solid foundation for proposing a credible and sustainable gas limit increase.
The majority of developer time was dedicated to hands-on coding, often extending late into the night. These intense coding sessions were interspersed with focused breakout groups designed to achieve consensus on critical design decisions and to deliberate on the longer-term roadmap for Ethereum’s evolution.
Supporting the developers throughout the week were three dedicated teams from the Ethereum Foundation (EF). EthPandaOps provided essential infrastructure, including the ethIQ performance monitoring tool and a specialized "panda" Message Coordination Protocol (MCP) server to facilitate agentic workflows. The Protocol Support team established soldogn.xyz as the central repository for interop goals, schedules, and detailed notes, ensuring seamless information flow. The EF Digital Studio team meticulously documented the entire event, with a full-length documentary anticipated to capture the spirit and achievements of the Soldægn Interop.
Enhancing Throughput with ePBS (Proposer-Builder Separation)
ePBS represents a significant architectural shift on the consensus layer, designed to optimize block construction and introduce crucial deadlines for various stages of block processing. These deadlines, for block construction, payload reveal, and attestation, explicitly allocate dedicated time for the execution layer, thereby creating more headroom to safely increase the gas limit.
The week commenced with an ambitious target: a stable 4 Execution Layer (EL) and 4 Consensus Layer (CL) Glamsterdam devnet by Monday evening. Initial challenges encountered during this phase necessitated a slight adjustment, pushing the stable configuration to a 4×3 setup by Tuesday, which then allowed for the commencement of rigorous stress testing.
The subsequent days were dedicated to an iterative ePBS hardening cycle: stress testing, identifying and exposing edge cases, implementing fixes, and repeating the process. A significant breakthrough occurred during a Tuesday morning breakout session focused on the Builder API. This session led to a substantial simplification of the specification, particularly concerning validator registration, the bid/header/commitments flow, the trust model for builder payments, and the behavior of circuit breakers. By mid-week, debugging efforts zeroed in on cross-client edge cases, most notably addressing issues related to the invalidation of beacon requests by execution-layer requests. A new test suite developed during this period effectively revealed gaps in every client implementation. By Thursday morning, CL teams reported stable ePBS operations, while EL-side bid pathways were still undergoing debugging, with resolutions achieved by Friday. Two contentious questions remained for the All-Core-Devs (ACD) process: whether a request signature should unequivocally commit to the receiving builder, and how to maintain the resilience of a 1 ETH-staked-builder design against peer-to-peer Sybil-based liveness attacks. By the end of the week, nearly all clients were successfully running in tandem on glamsterdam-devnet-2, with the external builder pipeline having undergone end-to-end testing.
Optimizing Block-Level Access Lists (BALs)
Complementing the consensus-layer advancements of ePBS, the execution layer’s contribution to Glamsterdam’s scaling strategy centers on two primary components: gas repricings and Block-Level Access Lists (BALs), as defined in EIP-7928. By providing clients with detailed information about a block’s read and write sets in advance, BALs enable parallel execution, batched I/O operations, and parallel computation of state roots. These optimizations 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 the stabilization efforts of the consensus layer. Each optimization was implemented behind a feature flag, allowing for isolated comparative measurement rather than being bundled. The BAL benchmark dashboard and leaderboard effectively highlighted each client’s worst-case performance scenarios across the test suite. By prioritizing the enhancement of the slowest execution paths, the developers aimed to elevate the gas limit floor across all implementations, not just those that were already the fastest.
Gas Repricings: Calibrating Costs for Higher Throughput
Glamsterdam incorporates a series of execution-layer gas repricings, meticulously calibrating costs to better align with resource utilization at higher transaction volumes. EIP-8037, which significantly increases the gas cost for state creation, is central to this effort. By raising the price associated with writing new state, the protocol ensures that a higher gas limit does not lead to unbounded state growth, a critical factor in maintaining network health and predictability.
Leading into the Soldægn Interop, the EIP-8037 specification featured dynamic per-state-byte pricing that was directly tied to the block gas limit. This approach presented significant testing challenges, requiring a combinatorial matrix of fuzzing scenarios for each gas limit band, and made benchmarking an almost intractable 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 fork boundaries, rather than being dynamically adjusted within a single fork.
The accounting model itself evolved through an iterative process. A breakout session on Monday shifted state-gas accounting from mid-execution to the end of the call frame. A subsequent follow-up on Tuesday addressed account creation costs, code deposit costs, and CREATE transaction reverts. On Wednesday, edge cases related to reservoir refunds and refills necessitated a fundamental reevaluation. By Thursday, the accounting model reverted to the opcode level, with the realization that the primary 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 final repricing numbers.
This entire development arc underscores a crucial aspect of interop events: the ability to resolve complex specification, implementation, testing, debugging, and design issues within hours rather than weeks. At their most effective, interop weeks can compress weeks of asynchronous progress into a single day of focused, collaborative effort.
The convergence of these three threads – ePBS, BAL optimizations, and gas repricings – led to the week’s most significant outcome: a credible target for a 200 million gas limit floor post-Glamsterdam. This substantial increase is achievable due to the synergistic effects of ePBS structuring the slot to afford the execution layer more time, BAL optimizations providing clients with the necessary throughput headroom within that structure, and EIP-8037 ensuring that the increased gas limit does not result in uncontrolled state expansion.
Exploring Other Glamsterdam Threads
Beyond the core advancements in ePBS, BALs, and repricings, a significant portion of the remaining Glamsterdam scope was addressed through various breakout sessions.
On the consensus layer (CL) front, 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 ultimately declined for inclusion in this upgrade. EIP-8045, related to 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 the Glamsterdam scope but was held out of glamsterdam-devnet-1 while teams work through the challenges of bounded gossip message sizes for attestations under progressive lists.
A breakout session on Wednesday morning dedicated to EL/CL sync architecture resulted in the deferral of EIP-8237 out of Glamsterdam. This decision was made to preserve optionality for a more extensive "top-up sync" architecture in a future fork. In its place, the participants agreed to draft an EIP that standardizes the sequencing of forkchoiceUpdated, newPayload, and getPayload calls, specifies an initiation handshake for snap-sync, and tightens the consistency of valid and invalid states between the engine API surfaces.
Hardening and testing were persistent themes throughout the week. A Thursday session covered fork-choice compliance testing frameworks, the diamond repository which houses reproducible CL edge-case scenarios, and buildoor, PandaOps’s external builder testing tool. During a mid-session demonstration of buildoor, attendees spontaneously suggested a continuous stream of attack scenarios, which were promptly incorporated into the testing protocols.
Looking Beyond Glamsterdam: Hegotæ and Future Forks
Several breakouts shifted focus to the subsequent "Hegotæ" upgrade and the forks that will follow.
A deliberately proposal-agnostic session on native Account Abstraction initiated discussions by working through the fundamental requirements and constraints that any future design must satisfy. The session identified key feature-set goals, including alternative signature schemes, aggregation, batching, recovery mechanisms, gas sponsorship, flexible nonces, and keystore wallets. These were weighed against critical hard constraints such as public mempool compatibility, statelessness, and Layer 2 Denial-of-Service (DoS) resistance.
A dedicated FOCIL breakout on Thursday concentrated on implementation updates. Early prototypes for FOCIL were already functional, with multi-client interop and a dedicated FOCIL devnet identified as the immediate next steps. Two notable design decisions were also finalized: FOCIL will be disabled during two-epoch non-finality periods, 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 the existing libp2p implementation. This proposed system would feature privacy-by-default functionalities and slot-aware integration. Additionally, an erasure-coded broadcast prototype was presented, simulating approximately six times faster propagation compared to GossipSub on 2.4 MB payloads. The CL track also indicated 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-then-redeposit process, which is viewed as the cleaner long-term solution for managing validator-set state growth.
Refining the All-Core-Devs (ACD) Process
On Wednesday afternoon, Nixo and Ansgar, the two co-leads of the ACD process, facilitated a session to gather input from core contributors regarding its operational framework. The session revisited the "headliner" construct, debated the merits of maintaining a "strawmap" (a community-driven roadmap visualization), and formalized the criteria for EIP Special Fork Inclusion (SFI). The consensus generally favored retaining headliners but advocated for a more flexible approach to EIP versus theme rigidity, accepting a "theme plus candidate EIP" pattern as a viable option. The strawmap’s per-fork year assignments beyond 2026 were flagged as overly canonicalized and likely to be softened. A new four-point SFI definition was proposed, with the All-Core-Devs Technical (ACDT) group signaling readiness and the All-Core-Devs Execution (ACDE) and All-Core-Devs Consensus (ACDC) groups retaining the final decision-making authority. A new prioritization and ordering process, to be determined after CFI decisions and reflected in a meta-EIP, will replace SFI’s former role in driving devnet inclusion, beginning with the Hegotæ upgrade.
In terms of call coordination, Alex Stokes announced a three-month sabbatical commencing the following week. Pari will assume interim ACDC moderation responsibilities during this period, and Barnabas will fill in for ACDT. The current ACD leadership structure is as follows: Nixo and Ansgar chair ACDE, Pari serves as interim ACDC moderator, and Mario, Barnabas, and Danceratopz rotate ACDT moderation duties.
Progress on All Other Fronts
Beyond the major technical advancements, the in-person format of the Soldægn Interop allowed teams to make significant progress on a wide array of other critical areas. This included the development of improved test harnesses, dramatically compressing Hive feedback loops from hours to mere minutes. Significant progress was also made on engine API plumbing improvements, encompassing gossip deduplication, batched calls, and light-client-driven head discovery. The event also facilitated crucial discussions around hard trade-offs concerning client diversity and numerous other specialized topics. A comprehensive record of all session notes is publicly available at soldogn.xyz.
Charting the Course Forward: Next Steps
Following the productive Soldægn Interop, teams are returning to their respective workstreams with the immediate objective of transforming the prototypes developed during the week into production-ready code. The coming weeks will see a concentrated effort on hardening client implementations against the new specifications, finalizing test coverage, and merging the draft pull requests generated at Soldægn into the codebase.
As is customary, the final decisions regarding key values, such as the 200 million gas limit target and the precise repricing numbers, will be formally announced and publicly shared during AllCoreDevs calls. These decisions are anticipated to be the central focus of upcoming discussions.
The success of the Soldægn Interop was a collective achievement, made possible by the dedication of all participants who traveled to the remote 78°N latitude. Special commendation is due to EthPandaOps for their daily efforts in galvanizing the group and to everyone who worked tirelessly under the midnight sun to meet daily objectives. The inclusion of the Ethrex crew, marking their first interop experience, was also a significant contribution. The week was exceptionally productive, and the forthcoming short film will serve as a valuable memento of this crucial milestone in Ethereum’s ongoing development.
