This past week, over 100 Ethereum core contributors convened in Longyearbyen, Svalbard, a remote settlement perched above the Arctic Circle, for Soldøgn Interop. This intensive, week-long gathering was dedicated to the critical task of advancing the Glamsterdam network upgrade, with a specific focus on enhancing its stability and scalability. The event marked a return to a focused, single-track format, reminiscent of previous successful interop sessions like Amphora, Edelweiss, and Nyota, allowing for concentrated progress on multi-client development.
The Soldøgn Interop, held in the unique environment of Svalbard, aimed to solidify key aspects of the Glamsterdam upgrade, a pivotal step in Ethereum’s ongoing evolution. By Friday, the collective efforts of the core developers yielded significant achievements, including the establishment of a post-Glamsterdam gas limit floor of 200 million, the successful implementation of stable proposer-builder separation (ePBS) with external builders, and the finalization of repricing numbers for EIP-8037. Beyond these headline objectives, substantial headway was also made on future features such as FOCIL and native account abstraction, alongside discussions on numerous other vital topics shaping Ethereum’s roadmap.
The choice of Svalbard for this critical development sprint was deliberate and symbolic. As one of the few locations globally where individuals can reside and work without visa restrictions, it offers a unique environment for international collaboration. Furthermore, Svalbard is home to the Global Seed Vault and the Arctic World Archive, both vital repositories of humanity’s most precious data, including a snapshot of Ethereum’s source code. This commitment to long-term preservation mirrors Ethereum’s own mission of building a resilient and enduring decentralized network. The perpetual daylight during this period, from late April through August, provided an extended working window, mirroring Ethereum’s own 24/7 uptime, a characteristic core developers sought to imbue into the network’s next iteration.
Harden Glamsterdam, Scale Ethereum
The primary objective of the Soldøgn Interop was to harden Glamsterdam implementations and establish a target for a post-upgrade gas limit floor. The challenge of safely increasing the gas limit is multifaceted, involving intricate considerations of block construction, proposer-builder dynamics, client implementation capacity under load, and the scaling of state-creation costs in tandem with network throughput.
The week’s work culminated in the operation of a stable, multi-client Glamsterdam devnet. This devnet integrated the latest advancements in ePBS, block access list specifications, and comprehensive benchmarking data. This data serves as a crucial foundation for proposing a credible and sustainable gas limit increase. The intensive development process involved significant coding efforts, often extending into the early hours of the morning, interspersed with focused breakout sessions to harmonize design decisions and strategize on long-term roadmap objectives.
Three key Ethereum Foundation (EF) teams provided essential infrastructure and support for the interop. EthPandaOps deployed their ethIQ platform and a panda MCP server to bolster agentic workflows, while the Protocol Support team established soldogn.xyz as the central hub for interop goals, schedules, and meeting notes. The EF Digital Studio team meticulously documented the week’s proceedings, promising a forthcoming documentary capturing the essence of this collaborative endeavor.
ePBS: Enhancing Block Construction and Throughput
The integration of proposer-builder separation (ePBS) represents a significant architectural shift in how Ethereum blocks are constructed and proposed. ePBS introduces explicit deadlines for block construction, payload revelation, and attestation submission. This structured approach allocates dedicated time for execution, thereby increasing the potential headroom for raising the gas limit.
The week commenced with the ambitious goal of establishing a 4 Execution Layer (EL) and 4 Consensus Layer (CL) Glamsterdam devnet by Monday evening. Initial attempts revealed a number of challenges, pushing the target to Tuesday. By Tuesday, a 4×3 configuration was running stably, enabling the commencement of rigorous stress testing.
The remainder of the week was dedicated to a continuous ePBS hardening cycle: stress testing, identifying edge cases, implementing fixes, and repeating the process. A breakout session on Tuesday morning significantly streamlined the Builder API specification, clarifying validator registration, the bid/header/commitments flow, the builder payment trust model, and circuit-breaker mechanisms. Mid-week debugging efforts concentrated on cross-client edge cases, particularly concerning the invalidation of beacon requests by execution layer requests. A newly developed test suite highlighted discrepancies across all client implementations, underscoring the need for this focused effort. 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 contentious issues remained under active discussion within the AllCoreDevs (ACD) working groups: 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. By Friday, nearly all participating clients were synchronized on glamsterdam-devnet-2, with the external builder pipeline tested end-to-end, a testament to the week’s concentrated development.
BAL Optimizations: The Execution Layer’s Scaling Contribution
While ePBS addresses the consensus layer’s role in scaling, the execution layer’s contribution is primarily driven by gas repricings and Block-Level Access Lists (BALs), as outlined in EIP-7928. By providing clients with comprehensive information about a block’s read and write sets upfront, BALs facilitate parallel execution, batched I/O operations, and parallel state-root computation. These optimizations are critical in determining the maximum block size that clients can comfortably handle.
The BAL optimization track at Soldøgn operated on separate devnets, distinct from the Glamsterdam ePBS chains, ensuring that optimization benchmarking was not conflated with consensus layer stabilization efforts. Each optimization was implemented behind its own feature flag, allowing for isolated comparative analysis rather than evaluating them as a monolithic package. The BAL benchmark dashboard and leaderboard highlighted the worst-case scenarios for each client across the test suite. By prioritizing and addressing the slowest execution paths, developers aimed to elevate the gas limit floor uniformly across all implementations, rather than solely benefiting the most performant ones.
Gas Repricings: Calibrating Costs for Higher Throughput
The Glamsterdam upgrade incorporates several execution layer gas repricings, designed to align costs more accurately with resource utilization at higher throughput levels. EIP-8037, which addresses the state-creation gas cost, is central to this effort. This EIP increases the cost of writing new state, thereby preventing an unbounded state growth scenario even with a higher gas limit.
Leading into the Soldøgn interop, the EIP-8037 specification included dynamic per-state-byte pricing that was tied to the block gas limit. This dynamic approach presented significant challenges for testing, creating a combinatorial explosion of test matrices for each gas limit band, and making benchmarking nearly intractable. Early in the week, the participants agreed to transition away from dynamic pricing in favor of a fixed cost_per_state_byte. Future repricing adjustments will be managed at fork boundaries, rather than being dynamically integrated within a single fork.
The accounting model itself underwent a more iterative development 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. Mid-week, discussions surrounding reservoir refund and refill edge cases necessitated a re-evaluation of the accounting model. By Thursday, the accounting model reverted to the opcode level, with the conclusion that the primary complexity resided within the reservoir model itself, rather than the computational aspects of accounting. By Friday, the specification had stabilized on bal-devnet-6, with the BAL track delivering the finalized repricing numbers. This entire process exemplifies the critical role of interop weeks in resolving complex specification, implementation, testing, debugging, and design issues in a compressed timeframe, potentially achieving weeks’ worth of asynchronous progress in mere days.
Ultimately, the convergence of these three development threads—ePBS, BAL optimizations, and gas repricings—led to the headline figure of the week: a credible 200 million post-Glamsterdam gas limit floor. This substantial increase is achievable due to the structural enhancements provided by ePBS, the throughput headroom created by BAL optimizations, and the assurance against runaway state growth offered by EIP-8037.
Other Glamsterdam Threads: Refining the Upgrade
Beyond the core advancements in ePBS, BALs, and gas repricings, the Soldøgn Interop also saw significant progress on other Glamsterdam scope items through dedicated breakout sessions.
Consensus Layer 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. EIP-8080, proposing exits via the consolidation queue, was declined for inclusion in this upgrade. 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, focused on SSZ stable containers, remains within the Glamsterdam scope but was held out of glamsterdam-devnet-1 to allow for continued work on bounded gossip-message sizes for attestations under progressive lists.
A crucial EL/CL sync architecture breakout session on Wednesday morning led to the decision to defer EIP-8237 out of Glamsterdam. This decision preserves optionality for a more comprehensive "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 strengthens consistency between the engine API surfaces for valid and invalid block states.
Hardening and testing remained a constant theme throughout the week. A dedicated session on Thursday explored fork-choice compliance testing frameworks. The Diamond repository, a collection of reproducible CL edge-case scenarios, and buildoor, PandaOps’s external builder testing tool, were demonstrated. During the buildoor demo, attendees actively suggested attack scenarios on the spot, showcasing the collaborative and adaptive nature of the development process.
Beyond Glamsterdam: Laying the Groundwork for Future Forks
Several breakout sessions at Soldøgn were forward-looking, examining features planned for future forks, including Hegotá. A deliberately proposal-agnostic session on native Account Abstraction initiated discussions around the core requirements and constraints that any future design must address. Key feature goals such as alternative signature schemes, aggregation, batching, recovery, gas sponsorship, flexible nonces, and keystore wallets were considered alongside critical constraints like public mempool compatibility, statelessness, and Layer 2 Denial-of-Service (DoS) resistance.
A breakout session dedicated to FOCIL on Thursday focused on implementation updates. Early prototypes have already demonstrated functionality, with multi-client interop and a dedicated FOCIL devnet identified as immediate next steps. Two significant 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 for compatibility with frame transactions and EIP-7702.
Further out on the roadmap, a long-running Ethereum Peer-to-Peer (ETH P2P) track explored the potential for a QUIC-based replacement for libp2p, emphasizing privacy-by-default features and slot-aware integration. An erasure-coded broadcast prototype was also presented, simulating approximately six times faster propagation than GossipSub for 2.4 MB payloads. The CL track also indicated a strong consensus toward eventually deprecating consolidations entirely. The proposed approach involves declaring a final fork that supports them, followed by a mandatory exit-and-redeposit mechanism, seen as a cleaner long-term solution for managing validator set state growth.
Refining the AllCoreDevs (ACD) Process
On Wednesday afternoon, Nixo and Ansgar, the co-leads of the AllCoreDevs Events (ACDE) working group, convened a session to gather input from core contributors regarding the ACD process. The discussion revisited the "headliner" construct, debated the merits of maintaining a strawmap, and formalized the criteria for EIP Selection Framework Initiative (SFI). The consensus leaned towards retaining headliners but reducing the rigidity between EIP-specific proposals and broader thematic objectives, 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 ACD Technical (ACDT) signaling readiness and ACDE/ACDC retaining final decision-making authority. A revised prioritization and ordering process, to be established after CFI decisions and reflected in the meta-EIP, will supersede SFI’s previous 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 interim moderation duties for ACDE Coordination (ACDC), while Barnabas will step in for ACDT. The current leadership structure includes Nixo and Ansgar chairing ACDE, Pari as interim ACDC moderator, and Mario, Barnabas, and Danceratopz rotating ACDT moderation responsibilities.
Progress Across the Board
Beyond the major development threads, the in-person gathering at Soldøgn facilitated progress on a wide array of topics. Teams worked on enhancing test harnesses, significantly reducing Hive feedback loops from hours to minutes. Improvements were also made to engine API plumbing, including gossip deduplication, batched calls, and light-client-driven head discovery. The interop also served as a forum for addressing difficult tradeoffs concerning client diversity and numerous other critical issues. Comprehensive notes from all sessions are publicly available on soldogn.xyz.
Next Steps: Towards 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 see a concentrated effort on hardening client implementations against the newly defined specifications, finalizing test coverage, and merging the draft Pull Requests initiated during the interop.
As is customary, final decisions on key values, such as the 200 million gas limit target and definitive repricing numbers, will be formally announced and communicated 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 Arctic Circle. Special acknowledgment is due to EthPandaOps for their instrumental role in organizing and motivating the group daily. The commitment of all participants, working under the midnight sun to achieve daily goals, including the Ethrex crew joining their first interop, was remarkable. The week proved to be exceptionally productive, and the anticipated short film will serve as a valuable record of this significant milestone in Ethereum’s development.
