This past week, over one hundred of Ethereum’s most dedicated core contributors gathered in the remote and striking locale of Longyearbyen, Svalbard, nestled just above the Arctic Circle. The event, dubbed "Soldægn Interop," marked a week of intensive, collaborative work focused on the critical "Glamsterdam" network upgrade. This gathering built upon the momentum of previous interop events, echoing the focused, single-track format employed in successful prior sessions like Berlinterop, Amphora, Edelweiss, and Nyota. The primary objective: to solidify and advance the Glamsterdam upgrade, paving the way for a more scalable and robust Ethereum.
The convergence of these key developers in such an extreme environment underscores the unique nature of the Ethereum community’s commitment to progress. By Friday, the Soldægn Interop had achieved significant milestones, most notably aligning on a post-Glamsterdam gas limit floor of 200 million. This crucial decision, representing a substantial increase from current levels, is a testament to the progress made in enhancing the network’s capacity. Furthermore, the event saw the successful implementation of stable proposer-builder separation (ePBS) with external builders, a fundamental shift in how blocks are constructed and proposed. The final repricing numbers for EIP-8037, a key component for managing state growth, were also locked in, providing much-needed clarity for future development. Beyond these headline achievements, substantial headway was also made on future-facing features such as FOCIL (Feature-Oriented Cryptographic Identity Layer) and native account abstraction, alongside a broad spectrum of other technical discussions.
Why Svalbard? A Unique Setting for Critical Development
The choice of Svalbard, and specifically Longyearbyen, for such a pivotal event was far from arbitrary. This remote Norwegian archipelago offers a unique proposition: it is one of the few places globally where individuals can live and work visa-free, irrespective of their nationality. This inclusive policy fosters an environment conducive to collaboration among a globally distributed team. Beyond its accessibility for residents, Svalbard is home to the Svalbard Global Seed Vault and the Arctic World Archive. These remarkable subterranean facilities, tunneled into the permafrost, serve as long-term cold storage for humanity’s most precious data. They safeguard backups of vital crop diversity, cultural artifacts like books and films, and even the source code of critical technologies, including Ethereum’s. The inclusion of Ethereum’s source code in the Arctic World Archive is a symbolic nod to the network’s enduring importance and its creators’ commitment to its future.
Adding to the unusual allure of the location, Svalbard experiences the phenomenon of the midnight sun from late April through August, meaning the sun never sets. This provides 24/7 daylight, a fitting parallel to Ethereum’s own "always-on" ethos. The core developers, it seems, embraced this perpetual uptime, dedicating their days and nights to the demanding work at hand, mirroring the network they are striving to improve.
Harden Glamsterdam, Scale Ethereum: The Core Mission
The central ambition of the Soldægn Interop was to "harden Glamsterdam implementations" and establish a concrete target for a post-upgrade gas limit floor. The challenge of safely increasing Ethereum’s gas limit is a multifaceted one, intricately tied to how blocks are constructed, how efficiently client implementations handle load, and how the cost of state creation scales with increased throughput. Glamsterdam is designed to address these very issues.
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 versions of ePBS, along with the refined block access list specifications. Crucially, it generated the necessary benchmarking data to support a credible proposal for a significantly higher gas limit. The majority of the week was dedicated to intense coding sessions, often extending into the early hours of the morning. These periods of deep work were interspersed with focused breakout sessions designed to align on critical design decisions and to deliberate on the long-term roadmap for Ethereum’s development.
Supporting this ambitious endeavor were three Ethereum Foundation (EF) teams. EthPandaOps provided essential infrastructure, including ethIQ for performance analysis and a "panda" MCP server to facilitate agentic workflows. The Protocol Support team established soldogn.xyz as the central hub for interop goals, schedules, and all documentation, serving as the single source of truth. Finally, the EF Digital Studio team documented the entire week, promising a forthcoming documentary that will offer a behind-the-scenes look at this critical development period.
ePBS: Restructuring for Scalability
At the heart of the Glamsterdam upgrade’s scaling strategy lies proposer-builder separation (ePBS). This mechanism goes beyond simply refining the relationship between block proposers and builders; it fundamentally restructures the timing within each block slot. By introducing explicit deadlines for block construction, payload revelation, and attestations, ePBS clarifies the time allocated for execution. This increased headroom is vital for safely raising the gas limit.
The week began with an ambitious target: a four-execution-layer (EL) and four-consensus-layer (CL) Glamsterdam devnet operational by Monday evening. Initial attempts, as is often the case in complex development cycles, revealed numerous issues, pushing the target to Tuesday. By then, a 4×3 configuration was running stably enough to commence rigorous stress testing.
The subsequent days were dedicated to a continuous ePBS hardening cycle: stress testing, identifying edge cases, fixing bugs, and repeating the process. A significant breakout session on Tuesday morning substantially simplified the Builder API specification. This included refinements to validator registration, the bid/header/commitments flow, 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 effectively highlighted gaps in every client implementation. By Thursday morning, CL teams reported stable ePBS operation, while EL-side bid pathways were still undergoing debugging, with resolutions emerging through Thursday and into Friday. Two contentious questions remained for the All-Core-Devs (ACD) process: whether a request signature should explicitly commit to the receiving builder, and how to ensure a 1 ETH-staked-builder design remains resilient against peer-to-peer Sybil-based liveness attacks. By the end of the week, nearly all participating clients were running together on the glamsterdam-devnet-2 network, with the external builder pipeline tested end-to-end.
BAL Optimizations: Enhancing Execution Layer Efficiency
If ePBS represents the consensus layer’s contribution to Glamsterdam’s scaling ambitions, the execution layer’s efforts are dominated by two key areas: gas repricings and Block-Level Access Lists (BALs). BALs provide clients with detailed upfront information about a block’s read and write sets. This enables critical performance enhancements such as parallel execution, batched I/O operations, and parallel state-root computation, all of which directly influence the maximum block size 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 intertwined with the complexities of consensus layer stabilization. Each optimization was implemented behind its own feature flag, allowing for isolated comparison of performance gains rather than a single, bundled improvement. The BAL benchmark dashboard and leaderboard, accessible at nerolation.github.io/bal-dashboard/, highlighted client-specific worst-case scenarios across the test suite. By focusing on improving the slowest execution paths first, the development teams 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 execution layer gas repricings, designed to better align transaction costs with resource utilization in a higher-throughput environment. Central to this effort is EIP-8037, which increases the gas cost for creating new state. This repricing is crucial: it ensures that a higher gas limit does not lead to unchecked state growth, a potential long-term scalability bottleneck.
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, while theoretically robust, created significant testing complexities, 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 dynamically within a fork.
The accounting model itself underwent a more iterative refinement process. An initial 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. Wednesday’s discussions surfaced edge cases related to reservoir refunds and refills, necessitating a reevaluation of the accounting model. By Thursday, the team reverted the accounting to the opcode level, concluding that the core complexity resided within the reservoir model rather than the computational aspects of accounting. By Friday, the specification had stabilized on bal-devnet-6, with the BAL track delivering the final repricing numbers. This iterative process exemplifies the power of interop events, where complex specification, implementation, testing, debugging, and design challenges can be resolved in hours rather than weeks, compressing a month’s worth of asynchronous progress into each day.
The culmination of these parallel efforts – the structural improvements from ePBS, the throughput headroom provided by BAL optimizations, and the state growth controls from EIP-8037 – has resulted in a credible proposal for a 200 million post-Glamsterdam gas limit floor. This significant increase is a direct outcome of the collaborative and intensive work undertaken during the Soldægn Interop.
Other Glamsterdam Threads: Refining the Upgrade
Beyond the core ePBS, BAL, and repricing initiatives, the Soldægn Interop addressed numerous other aspects of the Glamsterdam upgrade. Consensus layer teams finalized decisions on several smaller Glamsterdam EIPs. EIP-8061, which increases exit and consolidation churn, was successfully integrated into glamsterdam-devnet-1. EIP-8080, proposing exits via the consolidation queue, was declined for inclusion in this upgrade cycle. 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 the Glamsterdam scope but was held out of glamsterdam-devnet-1 as the team worked through the complexities of bounded gossip message sizes for attestations under progressive lists.
A significant breakout session on Wednesday morning involving both execution and consensus layer teams addressed sync architecture. EIP-8237 was deferred from Glamsterdam to preserve optionality for a more advanced "top-up sync" architecture in a future fork. In its place, the teams agreed to draft an EIP that standardizes the sequencing of forkchoiceUpdated, newPayload, and getPayload calls, defines a snap-sync initiation handshake, and tightens 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 fork-choice compliance testing frameworks. The eth-clients/diamond repository, which hosts reproducible CL edge-case scenarios, was utilized, and EthPandaOps’s external builder testing tool, buildoor, was demonstrated. Attendees actively suggested attack scenarios on the spot, further enhancing the robustness of testing methodologies.
Beyond Glamsterdam: Architecting Future Ethereum
The Soldægn Interop also served as a crucial platform for discussions regarding future upgrades, particularly "Hegotæ" and subsequent forks. A proposal-agnostic session on native Account Abstraction initiated these forward-looking discussions. Participants meticulously worked through the essential requirements and constraints that any future design must satisfy. The feature-set goals were ambitious, encompassing alternative signature schemes, aggregation, batching, recovery mechanisms, gas sponsorship, flexible nonces, and keystore wallets. These were balanced against critical hard constraints such as public mempool compatibility, statelessness, and L2 DoS resistance.
A breakout session on Thursday specifically addressed FOCIL, focusing on implementation updates. Early prototypes were already functional, with multi-client interop and a dedicated FOCIL devnet identified as immediate next steps. Two notable design decisions were made: 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 libp2p. This envisioned protocol would feature privacy-by-default settings and slot-aware integration. Additionally, an erasure-coded broadcast prototype demonstrated significantly faster propagation speeds, simulating approximately six times the efficiency of GossipSub on 2.4 MB payloads. The CL track also revealed a strong sentiment towards the eventual deprecation of consolidations entirely. The proposal suggests designating a final fork that supports them, followed by a mandatory exit and redeposit process, as the cleanest long-term solution to validator-set state growth.
ACD Process: Refining Governance and Coordination
Mid-week, the All-Core-Devs (ACD) co-leads, Nixo and Ansgar, facilitated a session to gather input from core contributors regarding the ACD process itself. The discussion revisited the "headliner" construct, a mechanism for selecting major features for hard forks, and debated the merits of maintaining a "strawmap," a flexible roadmap document. The criteria for EIP-SFI (Signaling for Inclusion) were also formalized. 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. The straw map’s per-fork year assignments beyond 2026 were flagged as potentially over-canonicalized and likely to be softened. A new four-point SFI definition was proposed, with ACDT (All-Core-Devs Technical) signaling readiness and ACDE (All-Core-Devs Execution) and ACDC (All-Core-Devs Consensus) retaining the final decision-making authority. A new prioritization and ordering process, to be implemented after CFI (Core Feature Integration) decisions and reflected in a meta-EIP, will replace SFI’s historical role in driving devnet inclusion, commencing with the Hegotæ upgrade.
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 ongoing leadership structure sees Nixo and Ansgar chairing ACDE, Pari as interim ACDC moderator, and Mario, Barnabas, and Danceratopz rotating ACDT moderation responsibilities.
Everything Else: Broadening Progress
Beyond the major initiatives, the in-person nature of the Soldægn Interop facilitated progress on a wide array of other critical areas. Teams worked on improving test harnesses, significantly compressing Hive feedback loops from hours to mere minutes. Enhancements to engine API plumbing, including gossip deduplication, batched calls, and light-client-driven head discovery, were also pursued. The week provided a forum for addressing difficult trade-offs related to client diversity and numerous other technical topics. Comprehensive notes from all sessions are publicly available at soldogn.xyz.
Next Steps: From Arctic Workshop to Production Readiness
Following the productive Soldægn Interop, development teams are returning to their respective bases to transition the week’s prototypes into production-ready implementations. 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 generated at 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 discussions are expected to dominate the agenda in the immediate future.
The success of the Soldægn Interop is a testament to the dedication of over one hundred core contributors who traveled to the 78th parallel North. Special commendation goes to EthPandaOps for their daily efforts in organizing and driving the group forward, and to everyone who worked tirelessly under the perpetual daylight to achieve daily goals, including the Ethrex crew, participating in their first interop. The week was remarkably productive, and the anticipation of a full short film documenting the event promises a valuable record of this significant milestone in Ethereum’s evolution.
