Just over 100 Ethereum core contributors recently convened in the remote settlement of Longyearbyen, Svalbard, situated above the Arctic Circle, for the Soldøgn Interop. This intensive week-long gathering was dedicated to the critical task of refining the Glamsterdam network upgrade, a pivotal step in enhancing Ethereum’s scalability and efficiency. The Soldøgn Interop followed the successful Berlinterop held the previous year, but importantly, it reverted to a proven format that has yielded significant progress in past initiatives like Amphora, Edelweiss, and Nyota. This single-track, highly focused approach allows for concentrated multi-client development, a crucial element when aiming to achieve specific, complex upgrades such as the hardening of the Glamsterdam network.
By the conclusion of the week on Friday, the assembled developers had achieved three primary objectives: securing consensus on a post-Glamsterdam gas limit floor of 200 million, establishing stable implementations of Proposer-Builder Separation (ePBS) capable of operating with external builders, and finalizing the repricing numbers for EIP-8037. Beyond these core goals, substantial advancements were also made on forward-looking features like FOCIL and native account abstraction, alongside discussions and progress on a multitude of other technical subjects vital to Ethereum’s ongoing evolution.
The Strategic Choice of Svalbard: A Remote Hub for Innovation
The selection of Svalbard as the venue for the Soldøgn Interop was a deliberate and symbolic choice. This remote archipelago is one of the few locations globally where individuals of any nationality can reside and work without the need for visas, fostering an environment of open international collaboration. Furthermore, Svalbard is home to unique institutions that resonate with the long-term vision of blockchain technology: the Global Seed Vault and the Arctic World Archive. These facilities, meticulously carved into the permafrost, serve as cold-storage repositories for humanity’s most vital data, including agricultural genetic diversity, cultural artifacts, and crucially, digital archives of critical technologies like Ethereum’s source code. The intention is to preserve this knowledge for a thousand years, mirroring the enduring ambition of decentralized systems.
Adding to the unique atmosphere, from late April through August, Svalbard experiences the phenomenon of the midnight sun, where daylight persists for 24 hours a day. This continuous uptime served as a fitting metaphor for Ethereum’s own commitment to constant availability, a characteristic the core developers embraced by maximizing their productive hours throughout the week.
Hardening Glamsterdam for Enhanced Scalability
The central aim of the Soldøgn Interop was to solidify the implementation of Glamsterdam and establish a clear target for the gas limit that will be in effect after its deployment. The challenge of safely increasing Ethereum’s gas limit is a multifaceted one, touching upon how blocks are constructed, how proposers present them, the operational headroom available to client implementations under heavy load, and the economics of state creation as transaction throughput rises.
In practical terms, the week’s work culminated in a stable multi-client Glamsterdam development network (devnet). This devnet was configured to run the latest versions of ePBS, incorporate updated specifications for transaction repricing and block access lists (BALs), and generate crucial benchmarking data. This data serves as the bedrock for proposing a credible and robust increase to the gas limit. The developers dedicated the majority of their time to intensive coding sessions, often extending into the early morning hours. These were interspersed with focused breakout sessions designed to achieve consensus on design decisions and to deliberate on the long-term roadmap for Ethereum’s development.
The operational backbone for this intensive collaboration was provided by three Ethereum Foundation (EF) teams. EthPandaOps was instrumental in deploying ethIQ, a performance monitoring tool, and a panda MCP server to facilitate agentic workflows for the participating teams. The Protocol Support team established soldogn.xyz as the definitive single source of truth for interop goals, schedules, and detailed meeting notes. The EF Digital Studio team was also present, diligently documenting the entire week through film, promising the release of the first-ever interop documentary, offering a unique behind-the-scenes look at this critical phase of Ethereum’s development.
The Mechanics of Proposer-Builder Separation (ePBS)
The ePBS initiative represents a significant architectural shift on the consensus layer, aiming to decouple the responsibilities of block proposers from block builders. This restructuring introduces explicit deadlines for various stages of block construction, including block building, payload revelation, and attestation submission. By defining these time allocations, ePBS significantly increases the available time for the execution layer to process transactions, thereby creating more headroom for a higher gas limit.
The week commenced with an ambitious target: a functional 4 Execution Layer (EL) and 4 Consensus Layer (CL) Glamsterdam devnet by Monday evening. The initial attempts to achieve this revealed several critical issues, necessitating a revised target of Tuesday. By Tuesday, a 4×3 configuration was running stably enough to initiate stress testing. The remainder of the week was dedicated to a rigorous ePBS hardening cycle: subjecting the system to stress tests, identifying edge cases, implementing fixes, and repeating the process. A breakout session on Tuesday morning substantially 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 exposed 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, with resolutions achieved through Thursday and into Friday. Two persistent and contentious questions for the All-Core-Devs (ACD) process remained: whether a request signature should explicitly 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. Despite these ongoing discussions, by Friday, nearly all participating clients were operating in unison on glamsterdam-devnet-2, with the external builder pipeline tested end-to-end.
Optimizing Block Access Lists (BALs) for Throughput
If ePBS represents the consensus layer’s contribution to Glamsterdam’s scaling strategy, the execution layer’s parallel efforts involve gas repricing and the implementation of Block-Level Access Lists (BALs), as outlined in EIP-7928. BALs provide clients with upfront information about a block’s read and write sets, which is crucial for enabling parallel execution, batched input/output operations, and parallel state-root computation. These optimizations are fundamental to determining the maximum block size that clients can comfortably handle.
The BAL track at Soldøgn operated on separate devnets, distinct from the Glamsterdam ePBS chains. This segregation ensured that optimization benchmarks were not conflated with the stabilization efforts of the consensus layer. Each optimization was implemented behind its own feature flag, allowing the week’s measurement work to compare their performance in isolation rather than as a monolithic bundle. The dedicated BAL benchmark dashboard and leaderboard highlighted the worst-case scenarios for each client across the entire test suite. By prioritizing the enhancement of the slowest execution paths, the development teams aimed to collectively raise the gas limit floor across all implementations, rather than merely optimizing for the fastest ones.
Fine-Tuning Gas Repricings for Sustainable Growth
Glamsterdam incorporates several crucial gas repricing adjustments on the execution layer. These adjustments are designed to align transaction costs more accurately with the actual resource consumption at higher throughput levels. EIP-8037, which mandates an increase in the gas cost for state creation, is central to this effort. By raising the cost of writing new state, this EIP ensures that a higher gas limit does not inadvertently lead to uncontrolled state growth, a potential long-term sustainability issue for the network.
Leading into the Soldøgn Interop, the EIP-8037 specification featured dynamic per-state-byte pricing that was intricately linked to the block gas limit. This dynamic approach presented significant testing challenges, requiring extensive fuzz matrices for each gas limit band and rendering performance benchmarking nearly intractable. Early in the week, the development teams reached a consensus to move away from dynamic pricing in favor of a fixed cost_per_state_byte. This simplification allows for future repricing adjustments to be handled at fork boundaries, rather than dynamically within a single fork.
The accounting model itself underwent an iterative refinement process. A breakout session on Monday shifted state-gas accounting from the mid-execution phase to the end of each call frame. A subsequent follow-up session on Tuesday addressed account creation costs, code deposit costs, and the handling of CREATE transaction reverts. Mid-week, edge cases related to the reservoir refund and refill mechanisms necessitated a fundamental reevaluation of the model. By Thursday, the accounting model had reverted to the opcode level, with the realization that the primary complexity resided within the reservoir model itself, rather than the computation of the accounting. By Friday, the specification had stabilized on bal-devnet-6, and the BAL track had successfully delivered the final repricing numbers.
This entire iterative process underscores a critical advantage of interop events: the ability to resolve complex issues spanning specification, implementation, testing, debugging, and design in a matter of hours, a feat that would typically take weeks in an asynchronous, remote setting. At their most effective, these interop weeks can compress months of development progress into each day.
By Friday, these three distinct development threads—ePBS, BALs, and gas repricings—converged on a pivotal outcome: the establishment of a credible 200 million gas limit floor for the post-Glamsterdam era. This substantial increase is achievable due to the synergistic improvements brought about by ePBS, which restructures the block 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 unmanageable state growth.
Addressing Other Glamsterdam Development Threads
Beyond the primary focuses of ePBS, BALs, and gas repricings, a significant portion of the remaining Glamsterdam scope was addressed through various breakout sessions. On the consensus layer front, teams finalized decisions on several smaller Glamsterdam EIPs. EIP-8061, which aims to increase exit and consolidation churn, was successfully integrated into glamsterdam-devnet-1. However, 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, focused on SSZ stable containers, remains within the Glamsterdam scope but was held out of glamsterdam-devnet-1 while the team addressed the challenge 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 Glamsterdam. This move was made to preserve flexibility for a longer-term "top-up sync" architecture in a future fork. In its place, the participants agreed to draft a new EIP that would standardize the sequencing of forkchoiceUpdated, newPayload, and getPayload messages. This new EIP will also define a handshake protocol for snap-sync initiation and tighten consistency requirements between the various engine API surfaces.
Hardening and ensuring the robustness of the network was 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, was a key focus. Additionally, buildoor, PandaOps’s external builder testing tool, was demonstrated mid-session, with attendees actively suggesting and simulating various attack scenarios in real-time.
Charting the Course Beyond Glamsterdam: Hegotá and Future Forks
Several breakout sessions were dedicated to looking ahead, specifically at the scope of Hegotá and subsequent forks. A deliberately proposal-agnostic session on native Account Abstraction initiated discussions by thoroughly examining the requirements and constraints that any future design must satisfy. The identified feature-set goals encompass a wide range of capabilities, including alternative signature schemes, aggregation, batching, recovery mechanisms, gas sponsorship, flexible nonces, and the implementation of keystore wallets. These are balanced against critical hard constraints such as public mempool compatibility, statelessness, and resistance to denial-of-service attacks on Layer 2 solutions.
A dedicated FOCIL breakout session on Thursday focused on implementation updates. Early prototypes for FOCIL were already functional, with multi-client interoperability and the establishment of a dedicated FOCIL devnet identified as immediate next steps. Two significant design decisions were also solidified: 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 into the future, a long-running ETH P2P track explored the potential for a QUIC-based replacement for libp2p. This proposed system would feature privacy-by-default settings and slot-aware integration. Additionally, a prototype for an erasure-coded broadcast mechanism was developed, which simulated approximately six times faster propagation compared to GossipSub when handling 2.4 MB payloads. The CL track also revealed a strong sentiment toward eventually deprecating consolidations entirely. The proposed approach involves declaring a final fork that supports them, followed by a mandatory exit and redeposit process, which is seen as the cleanest long-term solution for managing validator-set state growth.
Refining the All-Core-Devs (ACD) Process
On Wednesday afternoon, Nixo and Ansgar, the co-leads of the All-Core-Devs Execution (ACDE) working group, facilitated a session to gather input from core contributors regarding the ACD process itself. The discussion revisited the "headliner" construct, a mechanism for identifying key themes for hard forks. The pros and cons of maintaining a "strawmap," a living document outlining proposed fork contents, were debated. Furthermore, the criteria for EIP Special Fork Inclusion (SFI) were formalized. The consensus of the participants was to retain the headliner concept but to loosen the strict rigidity between individual EIPs and broader themes. This approach allows for a more flexible "theme plus candidate EIP" pattern to be considered. The per-fork year assignments in the strawmap beyond 2026 were flagged as overly canonicalized and likely to be softened in future iterations. A new four-point definition for SFI was proposed, with ACD Technical (ACDT) signaling readiness and ACDE/ACDC retaining the final decision-making authority. A new prioritization and ordering process, to be implemented after Consensus Fork Improvement (CFI) decisions and reflected in a meta-EIP, will replace the old role of SFI in driving devnet inclusion, beginning with the Hegotá fork.
In terms of call coordination, Alex Stokes announced his upcoming three-month sabbatical, commencing the following week. During his absence, Pari (Parithosh Jayanthi) will assume moderation duties for the All-Core-Devs Coordination (ACDC) calls, while Barnabas (Barnabas Busa) will step in for ACDT moderation. The current leadership structure is: Nixo and Ansgar chair ACDE, Pari serves as interim ACDC moderator, and Mario (Mario Evelyn), Barnabas, and Danceratopz (Danceratopz) will rotate ACDT moderation responsibilities.
Progress on Numerous Fronts and Future Outlook
In addition to the major advancements discussed above, the in-person gathering facilitated progress on a wide array of other critical areas. Development teams utilized the focused environment to improve test harnesses, significantly compressing Hive feedback loops from hours to mere minutes. Enhancements were also made to engine API plumbing, including improvements to gossip deduplication, the implementation of batched calls, and the development of light-client-driven head discovery. Furthermore, difficult trade-offs concerning client diversity were addressed, alongside numerous other technical discussions. A comprehensive list of session notes is publicly available on soldogn.xyz.
The immediate next steps for the core development teams involve returning home to translate the prototypes developed during the Soldøgn Interop into production-ready code. The coming weeks are expected to be characterized by intensive efforts to harden client implementations against the new specifications, finalize test coverage, and integrate the draft Pull Requests from Soldøgn into the main codebase.
As is customary, the final decisions regarding key values, such as the 200 million gas limit target and the definitive repricing numbers, will be formally announced and publicly shared during the AllCoreDevs calls. These critical decisions are anticipated to be the primary focus of discussions in the immediate weeks ahead.
The success of the Soldøgn Interop was a testament to the dedication and collaborative spirit of the over 100 core contributors who traveled to the remote 78° North latitude. Special recognition is due to EthPandaOps for their daily efforts in organizing and motivating the group, and to all participants who worked diligently under the continuous daylight to ensure daily goals were met. This included the Ethrex crew, who participated in their first interop event. The week proved to be exceptionally productive, and the upcoming release of a short film documenting the event promises to provide a lasting record of this significant milestone in Ethereum’s ongoing development journey.
