This past week, over 100 Ethereum core contributors convened in the remote Arctic settlement of Longyearbyen, Svalbard, for the Soldøgn Interop. This intensive, week-long gathering focused on the critical "Glamsterdam" network upgrade, a pivotal step in Ethereum’s ongoing evolution toward enhanced scalability and robustness. The event, mirroring successful past interop sessions like Amphora, Edelweiss, and Nyota, adopted a focused, single-track format to drive multi-client progress on specific development goals.
The Soldøgn Interop, following last year’s Berlinterop, aimed to solidify key aspects of the Glamsterdam upgrade. By the culmination of the week, significant milestones were achieved, including the alignment on a post-Glamsterdam gas limit floor of 200 million, the establishment of stable proposer-builder separation (ePBS) implementations interacting with external builders, and the finalization of EIP-8037 repricing numbers. Furthermore, substantial headway was made on future features such as FOCIL and native account abstraction, alongside discussions on a multitude of other crucial development threads.
The Strategic Choice of Svalbard
The selection of Longyearbyen, Svalbard, as the venue for this critical technical summit was deliberate and symbolic. Svalbard offers a unique environment where individuals from any nation can reside and work without visa requirements, fostering a truly international collaboration. More profoundly, the region is home to the Global Seed Vault and the Arctic World Archive, facilities dedicated to long-term preservation of humanity’s most vital data, including a snapshot of Ethereum’s source code. This commitment to enduring legacy resonates with Ethereum’s own mission of building a decentralized and resilient future. The perpetual daylight of the Arctic summer, from late April through August, also provided a fitting backdrop, symbolizing the 24/7 uptime and continuous operation that the Ethereum network strives to achieve, a metaphor that core developers embraced by working tirelessly throughout the week.
Hardening Glamsterdam: The Scalability Imperative
The primary objective of the Soldøgn Interop was to harden the Glamsterdam upgrade and establish a clear target for a post-upgrade gas limit floor. Safely increasing the gas limit, a key metric for transaction throughput, is a complex, multi-faceted challenge. Glamsterdam directly addresses several critical components of this challenge: it refines the processes by which blocks are constructed and proposed, enhances the headroom available to client implementations under heavy load, and optimizes how state-creation costs scale in proportion to increased throughput.
In practical terms, the week’s work resulted in a stable, multi-client Glamsterdam development network (devnet) running the latest ePBS, incorporating updated block access list specifications, and generating crucial benchmarking data. This data forms the foundation for a credible proposal to raise the gas limit significantly. The intensive schedule saw developers deeply immersed in coding, often extending into the early hours of the morning. These coding sprints were interspersed with focused breakout sessions to align on design decisions and deliberate on the long-term roadmap for the Ethereum protocol.
Supporting the intense development efforts, three Ethereum Foundation (EF) teams provided essential infrastructure. EthPandaOps deployed ethIQ and a Panda MCP server to facilitate agentic workflows, while the Protocol Support team established soldogn.xyz as the central repository for interop goals, schedules, and meeting notes. The EF Digital Studio team documented the entire week, promising a forthcoming documentary that will offer an inside look at this crucial period of development.
The Technical Pillars of Glamsterdam: ePBS and BAL Optimizations
The Glamsterdam upgrade rests on two fundamental technological advancements: enhanced Proposer-Builder Separation (ePBS) and Block-Level Access List (BAL) optimizations.
ePBS: Restructuring Block Production
ePBS fundamentally reshapes the relationship between block proposers and builders. By introducing explicit deadlines for block construction, payload revelation, and attestations, ePBS allocates dedicated time for execution, thereby creating more headroom for raising the gas limit. The week’s work began with an ambitious target: a four-execution-layer (EL) by four-consensus-layer (CL) Glamsterdam devnet by Monday evening. Initial challenges encountered during this phase led to a revised target of Tuesday for a stable 4×3 configuration, allowing stress testing to commence.
The remainder of the week was dedicated to an ePBS hardening cycle: rigorous stress testing, identification of edge cases, implementation of fixes, and repetition. A significant development occurred mid-week with a Builder API breakout session that substantially streamlined the specification for validator registration, the bid/header/commitment flow, the trust model for builder payments, and circuit-breaker mechanisms. Debugging efforts then zeroed in on cross-client edge cases, particularly concerning the invalidation of beacon requests by execution requests. A newly developed test suite highlighted discrepancies across all client implementations, underscoring the importance of this intensive interop. 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 points remained for the All-Core-Devs (ACD) process: 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. Ultimately, by Friday, nearly all participating clients were operating seamlessly on glamsterdam-devnet-2, with the external builder pipeline tested end-to-end.
BAL Optimizations: Enhancing Execution Layer Throughput
Complementing ePBS on the consensus layer, the execution layer’s scaling capabilities are bolstered by gas repricings and Block-Level Access Lists (BALs). BALs provide clients with upfront information regarding a block’s read and write sets. This foresight enables critical optimizations such as parallel execution, batched I/O operations, and parallel state-root computation, 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 benchmarking was not entangled with consensus-layer stabilization efforts. Each optimization was implemented behind a feature flag, allowing for isolated comparison. The BAL benchmark dashboard and leaderboard highlighted client-specific worst-case scenarios across the test suite. By prioritizing and improving the slowest execution paths, developers aimed to raise the gas limit floor uniformly across all implementations, rather than benefiting only the fastest ones.
Gas Repricings: Managing State Growth
A crucial element of Glamsterdam’s scaling strategy involves recalibrating gas costs to better align with resource utilization at higher throughput levels. At the forefront of this effort is EIP-8037, which increases the gas cost for creating new state. This measure is designed to prevent an unbounded expansion of network state, even with a higher gas limit.
Initially, the EIP-8037 specification featured dynamic per-state-byte pricing tied to the block gas limit, creating significant complexity for testing and benchmarking. A key decision made early in the Soldøgn week was to abandon dynamic pricing in favor of a fixed cost_per_state_byte. Future repricing adjustments will be managed at fork boundaries, rather than within a single fork.
The accounting model itself underwent an iterative refinement process. Initial efforts shifted state-gas accounting from mid-execution to the end of call frames. Subsequent discussions addressed account creation costs, code deposit costs, and the handling of CREATE transaction reverts. Mid-week, complexities in the reservoir refund and refill mechanisms necessitated a re-evaluation. By Thursday, the focus shifted back to the opcode level, recognizing that the core challenges lay 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 agile approach to resolving complex specification, implementation, testing, and debugging issues in a compressed timeframe is a hallmark of successful interop events, effectively compressing weeks of asynchronous progress into days.
The culmination of these efforts at Soldøgn was the establishment of a credible 200 million gas limit floor for post-Glamsterdam. This substantial increase is made possible by the synergistic advancements: ePBS structures the block production process to allocate more time for execution, BAL optimizations provide clients with the necessary throughput headroom within that structure, and EIP-8037 ensures that the increased gas limit does not lead to uncontrolled state growth.
Beyond the Core: Other Glamsterdam Threads and Future Visions
Beyond the central ePBS, BAL, and gas repricing initiatives, the Soldøgn Interop also addressed a range of other critical "Glamsterdam threads." Consensus-layer (CL) teams finalized decisions on several smaller Glamsterdam EIPs. EIP-8061, which aims to increase exit and consolidation churn, was integrated into glamsterdam-devnet-1. EIP-8080, proposing exits via the consolidation queue, was ultimately declined for inclusion in this upgrade. EIP-8045, concerning slashed-validator duty removal, was scoped down to affect only proposer duties within a look-ahead window. EIP-7688, focusing on SSZ stable containers, remains within the Glamsterdam scope but was held out of glamsterdam-devnet-1 to allow for further work on bounded gossip-message sizes for attestations under progressive lists.
An execution-layer (EL) and CL synchronization architecture breakout session on Wednesday morning decided to defer EIP-8237 out of Glamsterdam. This decision preserves optionality for a more expansive "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 snap-sync initiation handshake, and enhances consistency between the engine API surfaces for valid and invalid states.
Hardening and testing remained a pervasive theme throughout the week. A dedicated session on Thursday explored fork-choice compliance testing frameworks, the Diamond repository of reproducible CL edge-case scenarios, and buildoor, PandaOps’s external builder testing tool. buildoor was demonstrated with a series of attack scenarios suggested by attendees in real-time, highlighting its utility in stress-testing the network.
Charting the Future: Hegotá and Beyond
Several breakout sessions at Soldøgn cast their gaze toward "Hegotá" and subsequent forks. A deliberately proposal-agnostic session on native account abstraction explored the fundamental requirements and constraints that any future design must satisfy. Key feature-set goals included support for alternative signature schemes, aggregation, batching, recovery, gas sponsorship, flexible nonces, and keystore wallets. These were balanced against critical hard constraints such as public-mempool compatibility, statelessness, and Layer 2 denial-of-service (DoS) resistance.
A breakout session focused on FOCIL (Forward-Compatible Interface Layer) implementation updates showcased functional early prototypes. The immediate next steps for FOCIL development include 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 for compatibility with frame transactions and EIP-7702.
Further into the future, a long-running Ethereum peer-to-peer (P2P) track explored the potential for a QUIC-based replacement for libp2p. This envisioned system would incorporate privacy-by-default features and slot-aware integration. Additionally, a prototype for erasure-coded broadcast demonstrated approximately six times faster propagation than GossipSub for 2.4 MB payloads. The CL track also revealed a strong consensus 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 mechanism, which is seen as a cleaner long-term solution for managing validator-set state growth.
Refining the Development Process: ACD and Coordination
A significant session on Wednesday afternoon focused on the All-Core-Devs (ACD) process itself. Co-leads Nixo and Ansgar gathered input from core contributors to refine the ACD framework. Discussions revisited the "headliner" construct for selecting major protocol upgrades, debated the merits of a "strawmap" for outlining fork roadmaps, and formalized EIP Signaling Framework (SFI) criteria. The general sentiment favored retaining headliners while allowing for more flexibility in the relationship between individual EIPs and overarching themes, accepting "theme plus candidate EIP" as a viable development pattern. The strawmap’s per-fork year assignments beyond 2026 were identified 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 final decision-making authority. A new prioritization and ordering process, to be determined after CFI (Core Functionality Integration) decisions and reflected in a meta-EIP, will replace SFI’s previous 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 ACDC moderation duties, and Barnabas will fill in for ACDT. The updated coordination structure sees Nixo and Ansgar chairing ACDE, Pari as interim ACDC moderator, and Mario, Barnabas, and Danceratopz rotating ACDT moderation responsibilities.
Broadening Progress and Next Steps
Beyond the major technical threads, developers utilized the in-person gathering to advance numerous other initiatives. These included improvements to test harnesses, compressing Hive feedback loops from hours to minutes, enhancing engine-API plumbing with features like gossip deduplication and batched calls, and exploring light-client-driven head discovery. Significant discussions also addressed hard tradeoffs regarding client diversity and various other critical topics. Comprehensive notes from all sessions are publicly available at soldogn.xyz.
The immediate next steps following the Soldøgn Interop involve teams returning to their respective development environments to transition prototypes from the week into production-ready code. The coming weeks will be dedicated to hardening client implementations against the new specifications, finalizing test coverage, and merging the drafted pull requests into the main 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 crucial discussions are anticipated to be central topics in the upcoming weeks.
The success of the Soldøgn Interop is a testament to the dedication and collaborative spirit of the over 100 core contributors who traveled to the Arctic. Special acknowledgment is due to EthPandaOps for their daily organizational efforts and to all those who worked under the midnight sun to achieve daily objectives, including the Ethrex crew, who participated in their first interop. The week proved exceptionally productive, and the forthcoming short film promises to capture the essence of this pivotal moment in Ethereum’s development.
