This past week, over 100 Ethereum core contributors converged in the remote and starkly beautiful landscape of Longyearbyen, Svalbard, just over 450 miles north of the Arctic Circle, for the Soldøgn Interop. This intensive week-long event was dedicated to the critical task of hardening the network’s upcoming "Glamsterdam" upgrade, a pivotal step in Ethereum’s ongoing evolution towards greater scalability and efficiency. The gathering followed last year’s Berlinterop and returned to the highly effective single-track format pioneered by Amphora, Edelweiss, and Nyota, emphasizing focused, multi-client collaboration on specific upgrade objectives.
The strategic choice of Svalbard, a unique territory where visa requirements are minimal, provided an ideal environment for concentrated work. Beyond its logistical advantages, Svalbard’s commitment to long-term preservation, embodied by the Global Seed Vault and the Arctic World Archive, resonated with the developers’ mission to build a robust and enduring decentralized future for Ethereum. The persistent daylight of the Arctic summer, offering 24/7 illumination, mirrored the Ethereum network’s own commitment to continuous operation, a fitting backdrop for a week where developers worked around the clock to advance the protocol.
By the close of the Soldøgn Interop on Friday, the core contributors achieved significant milestones, delivering on three primary objectives. A consensus was reached on a post-Glamsterdam gas limit floor of 200 million, a substantial increase aimed at enhancing transaction throughput. Stable implementations of Proposer-Builder Separation (ePBS) were successfully demonstrated with external builders, paving the way for a more decentralized and efficient block-building process. Furthermore, the final repricing numbers for EIP-8037, a crucial component for managing state growth, were locked in. Beyond these headline achievements, substantial progress was also made on features slated for the subsequent "Hegotá" fork, including advancements in FOCIL (Fee-market Oblivious Consensus-Layer Incentives) and native account abstraction, alongside a broad spectrum of other technical discussions and problem-solving initiatives.
Harden Glamsterdam: Scaling Ethereum’s Capacity
The overarching goal of the Soldøgn Interop was to solidify the Glamsterdam upgrade and establish a concrete target for the network’s gas limit following its implementation. Safely increasing the gas limit, a metric that dictates the maximum computational effort a block can consume, is a complex, multi-faceted challenge. The Glamsterdam upgrade addresses several key areas: optimizing how blocks are constructed and proposed, ensuring client implementations possess sufficient headroom under heavy load, and refining the cost-scaling mechanisms for state creation as throughput increases.
In practical terms, the week culminated in a stable multi-client Glamsterdam development network (devnet). This devnet incorporated the latest ePBS configurations, updated specifications for repricing and block access lists, and provided essential benchmarking data. This empirical evidence formed the bedrock for proposing a credible and safe increase to the gas limit. The majority of the participants’ time was dedicated to intensive coding sessions, often extending into the early morning hours. These deep-dive coding sprints were strategically interspersed with breakout sessions designed to foster alignment on design decisions and to collaboratively map out longer-term development roadmaps.
Supporting this intense week of development were three dedicated teams from the Ethereum Foundation (EF). EthPandaOps provided crucial infrastructure, launching ethIQ for performance analysis and deploying a Panda MCP server to facilitate agentic workflows. The Protocol Support team established soldogn.xyz as the central repository for interop goals, schedules, and detailed notes, serving as the single source of truth for all participants. The EF Digital Studio team meticulously documented the week’s activities, promising the release of the first-ever interop documentary, offering a behind-the-scenes look at the collaborative spirit and technical rigor of the event.
The Mechanics of Scalability: ePBS and BAL Optimizations
The Glamsterdam upgrade is poised to significantly enhance Ethereum’s scalability through several key innovations. At the forefront is the evolution of Proposer-Builder Separation (ePBS), which goes beyond simply refining the relationship between block proposers and builders. ePBS restructures the block production process by introducing explicit deadlines for block construction, payload unveiling, and attestation submission. This structured approach allocates dedicated time for execution, thereby creating greater headroom for increasing the gas limit.
The initial stages of the week saw teams striving to establish a stable four-Execution Layer (EL) to four-Consensus Layer (CL) Glamsterdam devnet by Monday evening. The early challenges encountered highlighted the complexity of the task, pushing the target to Tuesday. By Tuesday, a 4×3 configuration was running stably, enabling the commencement of stress testing. The subsequent days were dedicated to an intensive ePBS hardening cycle: rigorous stress testing, identification of edge cases, implementation of fixes, and repetition of the process.
A significant breakout session on Tuesday morning dramatically 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 zeroed in on cross-client edge cases, particularly concerning the invalidation of beacon requests by execution layer requests. A newly developed test suite revealed a critical gap across all client implementations, which was subsequently addressed. By Thursday morning, CL teams reported stable ePBS functionality, while EL-side bid pathways continued to undergo debugging, with resolutions achieved by Friday. Two lingering contentious issues for the All-Core Developers (ACD) include whether a request signature should be tied to the receiving builder and how to ensure the resilience of a 1 ETH-staked-builder design against Sybil-based liveness attacks in peer-to-peer networks. By Friday, nearly all participating clients were operating in unison on glamsterdam-devnet-2, with the external builder pipeline tested end-to-end.
Complementing ePBS on the execution layer are Block-Level Access Lists (BALs) and gas repricings, which collectively form the other pillar of Glamsterdam’s scaling strategy. BALs, as defined by EIP-7928, provide clients with advance knowledge of a block’s read and write sets. This foresight enables critical optimizations such as parallel execution, batched I/O operations, and parallel state-root computations, all of which directly influence the maximum block size clients can efficiently handle.
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 its own feature flag, allowing for isolated comparative analysis rather than assessing them as a bundled update. The BAL benchmark dashboard and leaderboard provided real-time insights into each client’s worst-case performance across the test suite. By prioritizing the improvement of the slowest execution paths, the developers aimed to elevate the gas limit floor across the entire network, rather than solely benefiting the most optimized implementations.
Gas Repricings: Calibrating Costs for Higher Throughput
A significant component of the Glamsterdam upgrade involves a series of execution-layer gas repricings. These adjustments are designed to more accurately align computational costs with resource utilization at higher transaction volumes. Central to this effort is EIP-8037, which introduces an increase in the gas cost associated with creating new state. This measure is critical to prevent an unbounded expansion of state size as the gas limit rises.
Prior to Soldøgn, the EIP-8037 specification featured dynamic per-state-byte pricing that was intrinsically linked to the block gas limit. This dynamic pricing model presented significant challenges for testing, leading to a combinatorially complex fuzz matrix for each gas limit band, and rendering benchmarking nearly intractable. Early in the week, the development teams reached a consensus to transition away from dynamic pricing in favor of a fixed cost_per_state_byte. Future repricing adjustments will be handled at fork boundaries, rather than dynamically within a single fork, simplifying the development and testing process.
The accounting model itself underwent an iterative refinement process. An initial breakout session on Monday shifted state-gas accounting from mid-execution to the end of call frames. A follow-up session on Tuesday addressed account creation costs, code deposit costs, and CREATE-transaction reverts. By Wednesday, challenges related to reservoir refund and refill edge cases necessitated a re-evaluation of the model. A breakout session on Thursday reverted the accounting back to the opcode level, recognizing 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, and the BAL track successfully delivered the final repricing numbers for the upgrade. This entire process underscores the immense value of interop events, where complex specification, implementation, testing, debugging, and design challenges can be resolved within hours rather than weeks, compressing asynchronous progress into tangible daily advancements.
The convergence of these three critical development threads – ePBS, BAL optimizations, 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 in capacity is a direct result of the synergistic advancements: ePBS restructures the block slot to allocate more time for execution, BAL optimizations provide clients with the necessary throughput headroom within this new structure, and EIP-8037 ensures that the elevated gas limit does not lead to unmanageable state growth.
Exploring Other Glamsterdam Threads and Future Horizons
Beyond the core pillars of ePBS, BALs, and gas repricings, the Soldøgn Interop saw significant progress on a variety of other Glamsterdam-related initiatives 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, aiming to facilitate exits via the consolidation queue, was ultimately declined for inclusion in this upgrade. EIP-8045, focused on the removal of slashed validator duties, was scoped down to apply only to proposer duties within the look-ahead window. EIP-7688, concerning SSZ stable containers, remains within the Glamsterdam scope but has been held out of glamsterdam-devnet-1 as the team addresses the complexities of bounded gossip message sizes for attestations under progressive lists.
A sync architecture breakout session between the EL and CL teams on Wednesday morning resulted in the decision to defer EIP-8237 out of the Glamsterdam upgrade. This strategic move preserves optionality for a more comprehensive "top-up sync" architecture in a future fork. In its place, the teams agreed to draft a new EIP that standardizes the sequencing of forkchoiceUpdated, newPayload, and getPayload calls, specifies an initiation handshake for snap-sync, and enhances consistency between the engine API surfaces for valid and invalid states.
Hardening and testing remained a constant theme throughout the week. A dedicated session on Thursday explored frameworks for fork-choice compliance testing, showcased the Diamond repository of reproducible CL edge-case scenarios, and featured a demonstration of buildoor, PandaOps’s external builder testing tool. Attendees actively suggested attack scenarios in real-time, highlighting the collaborative and responsive nature of the interop process.
Looking beyond Glamsterdam, several breakout sessions focused on the subsequent "Hegotá" fork and future network advancements. A deliberately proposal-agnostic session on native Account Abstraction kicked off discussions, meticulously working through the fundamental requirements and constraints that any future design must satisfy. Feature-set goals, such as alternative signature schemes, aggregation, batching, recovery, gas sponsorship, flexible nonces, and keystore wallets, were considered alongside critical hard constraints like public mempool compatibility, statelessness, and Layer 2 Denial-of-Service (DoS) resistance.
A FOCIL breakout on Thursday centered on implementation updates, with early prototypes already demonstrating functional capabilities. The immediate next steps involve multi-client interop and the establishment of a dedicated FOCIL devnet. Two significant design decisions were made: 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.
Further into the future, a long-running ETH P2P track sketched out plans for a QUIC-based replacement for libp2p, emphasizing privacy-by-default features and slot-aware integration. A prototype for erasure-coded broadcast demonstrated a simulated propagation speed approximately six times faster than GossipSub for 2.4 MB payloads. The CL track also revealed a strong sentiment towards eventually deprecating consolidations entirely. This would involve declaring a final fork that supports them, followed by a mandatory exit-and-redeposit process, presenting a cleaner long-term solution to validator-set state growth.
Refining the All-Core-Devs Process
On Wednesday afternoon, the two All-Core-Devs Engine (ACDE) co-leads, Nixo and Ansgar, convened a session to gather input from core contributors regarding the All-Core-Devs (ACD) process. The discussion revisited the "headliner" construct for selecting major protocol upgrades, debated the merits of maintaining a "strawmap" of proposed upgrades, and formalized the criteria for EIP Special Fork Inclusion (SFI). The consensus leaned towards retaining headliners but with greater flexibility in the rigidity between EIPs and thematic goals, accepting a "theme plus candidate EIP" model as a viable approach. 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 ACD Technical (ACDT) signaling readiness and ACDE/ACDC retaining final decision-making authority. A new prioritization and ordering process, to be implemented after Consensus-fork-internal (CFI) decisions and reflected in the meta-EIP, will replace SFI’s former 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 interim moderation responsibilities for ACD Coordination (ACDC), while Barnabas will fill the role for ACDT. The current leadership structure for ACD calls involves Nixo and Ansgar chairing ACDE, Pari acting as interim for ACDC, and Mario, Barnabas, and Danceratopz rotating moderation duties for ACDT.
Broader Implications and Next Steps
Beyond the major technical advancements, teams utilized the in-person gathering to make progress on a wide array of other critical areas. These included enhancements to test harnesses, significantly compressing Hive feedback loops from hours to minutes; improvements to engine API plumbing, such as gossip deduplication, batched calls, and light-client-driven head discovery; and addressing difficult trade-offs concerning client diversity. The full list of session notes, detailing these diverse discussions, is publicly available at soldogn.xyz.
Following the Soldøgn Interop, the immediate next steps involve each team taking the prototypes developed during the week and preparing them for production readiness. The coming weeks will be characterized by intensive efforts to harden client implementations against the new specifications, finalize test coverage, and translate the draft Pull Requests (PRs) from Soldøgn into merged code.
As is customary, final decisions on key parameters, such as the 200 million gas limit target and the precise repricing numbers, will be formally announced and shared publicly 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 contributors who traveled to the remote Arctic outpost. Special recognition is due to EthPandaOps for their daily organizational efforts and to all who worked tirelessly under the midnight sun to achieve daily objectives. The participation of the Ethrex crew, marking their first interop, was also a welcome addition. The week was remarkably productive, and the anticipation for the upcoming documentary promises a lasting record of this significant collaborative achievement. The gathered data and implemented solutions from Soldøgn lay a robust foundation for Ethereum’s continued scaling and decentralization, signaling a promising trajectory for the network’s future.
