LONGYEARBYEN, SVALBARD – In a remote corner of the world, above the Arctic Circle, just over 100 of Ethereum’s most dedicated core contributors convened last week for the "Soldøgn Interop." Hosted in the unique setting of Longyearbyen, Svalbard, this intensive week of collaboration was dedicated to hardening the upcoming "Glamsterdam" network upgrade, a pivotal step in Ethereum’s ongoing journey towards greater scalability and efficiency. The gathering concluded with significant milestones achieved, setting a clear path for the network’s evolution.
The Soldøgn Interop successfully delivered on its three primary objectives: establishing a post-Glamsterdam gas limit floor of 200 million, achieving stable ePBS (extended Proposer-Builder Separation) implementations with external builders, and locking in the final repricing numbers for EIP-8037. Beyond these immediate goals, substantial progress was also made on features slated for future upgrades, such as "Hegotà," including FOCIL (Forward-Compatible Index Lists) and native account abstraction.
Why Svalbard? A Symbolic Nexus for Global Collaboration
The choice of Svalbard as the host location for such a critical interop was far from arbitrary, carrying profound symbolic weight that resonates with Ethereum’s decentralized ethos. This Norwegian archipelago is one of the few places on Earth where individuals of any nationality can live and work without a visa, embodying a spirit of open, global collaboration essential to a public blockchain.
Moreover, Longyearbyen is home to the Global Seed Vault and the Arctic World Archive, two iconic cold-storage facilities burrowed deep into the permafrost. These archives serve as humanity’s digital and biological safekeepers, preserving everything from vital crop seeds to historical manuscripts and foundational source code – including a snapshot of Ethereum’s own code – against future global disruptions. This commitment to long-term preservation and resilience mirrors Ethereum’s own ambition to build a permanent, censorship-resistant global computing platform.
Adding to its unique appeal, from late April through August, Svalbard experiences the "midnight sun," where the sun never dips below the horizon. This phenomenon of 24/7 daylight served as a powerful metaphor for Ethereum’s continuous, uninterrupted uptime, inspiring the core developers to maximize their intense work schedule throughout the week. The relentless daylight underscored the continuous, global nature of their collaborative efforts.
A Legacy of Interoperability: Charting Ethereum’s Future
The Soldøgn Interop builds upon a tradition of focused, multi-client gatherings that have become instrumental in Ethereum’s development roadmap. Following last year’s "Berlinterop," Soldøgn returned to the highly effective format pioneered by earlier events like "Amphora," "Edelweiss," and "Nyota." This single-track, week-long approach allows for deep, concentrated progress on specific network upgrades, fostering an environment where diverse client teams can align, test, and debug in real-time. For Soldøgn, the singular focus was the "hardening" of the Glamsterdam upgrade, ensuring its robustness and readiness for deployment.
Glamsterdam’s Core Pillars: Scaling Ethereum’s Throughput
The overarching objective of the week was to refine Glamsterdam implementations and establish a credible target for a significantly increased post-upgrade gas limit. Raising Ethereum’s gas limit safely is a complex, multi-faceted challenge, and Glamsterdam addresses several critical dimensions: optimizing how blocks are built and proposed, enhancing the headroom available to client implementations under heavy load, and managing the scaling of state-creation costs in tandem with increased transaction throughput.
Practically, this meant concluding the week with a stable, multi-client Glamsterdam development network (devnet) running the latest specifications for ePBS, repricing mechanisms, and block access lists. Crucially, this setup also enabled the collection of robust benchmarking data, providing the foundational evidence needed to propose a substantial and safe increase to the network’s gas limit.
Much of the week was characterized by heads-down coding, often extending into the early hours, interspersed with frequent breakout sessions to align on design decisions and discuss longer-term roadmap items. The collaborative intensity was supported by dedicated infrastructure teams: EthPandaOps provided advanced monitoring tools like ethIQ and a panda MCP server for agentic workflows; Protocol Support maintained soldogn.xyz as the central hub for goals, schedules, and notes; and the EF Digital Studio team meticulously documented the week, promising the very first interop documentary.
Enhanced Proposer-Builder Separation (ePBS)
ePBS represents a fundamental restructuring of Ethereum’s block production process. By cleanly separating the roles of block proposer and block builder, ePBS aims to reduce centralization risks inherent in MEV (Maximal Extractable Value) and improve overall network efficiency. It redefines slot structure by introducing explicit deadlines for block construction, payload revelation, and attestations. This restructuring allocates more predictable time for execution, directly increasing the "headroom" available for a higher gas limit.
The ePBS track began with an ambitious goal: a 4 Execution Layer (EL) x 4 Consensus Layer (CL) Glamsterdam devnet by Monday evening. Initial attempts revealed several issues, pushing the stable target to Tuesday, where a 4×3 configuration achieved sufficient stability for stress testing. The remainder of the week became an intense ePBS hardening cycle: continuous stress testing, identification of edge cases, iterative fixes, and repetition.
A crucial Tuesday morning breakout on the Builder API significantly simplified specifications around validator registration, the bid/header/commitments flow, the trust model for builder payments, and circuit-breaker behavior. Mid-week debugging efforts pinpointed cross-client edge cases, particularly regarding execution-request invalidation of beacon requests, which a new test suite exposed as a universal gap across all client implementations. By Thursday, CL teams reported stable ePBS, with EL-side bid pathways being resolved into Friday. Two key questions remain contentious for AllCoreDevs (ACD): whether a request signature should commit to the receiving builder, and how to maintain resilience for a 1 ETH-staked-builder design against P2P Sybil-based liveness attacks.
By Friday, nearly all clients were successfully running together on glamsterdam-devnet-2, with the external builders pipeline tested end-to-end – a major triumph for the week.
Optimizing Block Execution with Block-Level Access Lists (BALs)
While ePBS addresses the consensus layer’s role in scaling Glamsterdam, the execution layer counterpart focuses on two dominant pieces: gas repricings and Block-Level Access Lists (BALs), as defined in EIP-7928. BALs aim to provide clients with crucial information upfront about a block’s read/write set. This foreknowledge is a game-changer, enabling parallel execution of transactions, optimized batched I/O operations, and parallel computation of the state root. All these optimizations directly influence how large a block clients can efficiently process.
The Soldøgn BAL track operated on its own dedicated devnets, separate from the Glamsterdam ePBS chains. This isolation allowed for optimization benchmarks to be conducted without entanglement from consensus-layer stabilization work. Each optimization was implemented behind its own feature flag, enabling isolated comparison and measurement. The BAL benchmark dashboard and leaderboard proved invaluable, highlighting each client’s worst-case scenarios across the test suite. By focusing on improving the slowest paths first, teams could raise the overall gas limit floor, rather than just optimizing for the fastest implementations.
Calibrating Costs: Gas Repricings and EIP-8037
Glamsterdam also incorporates several execution layer gas repricings, designed to calibrate transaction costs more accurately to their actual resource consumption, especially at higher throughput levels. EIP-8037, which proposes an increase in state-creation gas costs, lies at the heart of this effort. Its purpose is to ensure that a higher gas limit does not inadvertently lead to unchecked state growth, maintaining the network’s long-term health and decentralization.
Entering Soldøgn, the EIP-8037 specification featured dynamic per-state-byte pricing, tied to the block gas limit. This complexity made testing combinatorially challenging and benchmarking nearly intractable. Early in the week, teams collaboratively decided to simplify this, opting to drop dynamic pricing in favor of a fixed cost_per_state_byte. Future repricing adjustments will be handled at specific fork boundaries, rather than within a single fork, streamlining development and predictability.
The accounting model for EIP-8037 underwent an iterative refinement process throughout the week. A Monday breakout shifted state-gas accounting from mid-execution to the end of the call-frame. A Tuesday follow-up addressed account creation costs, code deposit costs, and CREATE-transaction reverts. By Wednesday, reservoir refund/refill edge cases surfaced, necessitating a re-evaluation. A Thursday breakout reverted accounting to the opcode level, concluding that the primary complexity resided in 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 final repricing numbers.
This intensive, iterative problem-solving highlights a core strength of interop weeks: the ability to condense weeks or even months of asynchronous development, specification refinement, implementation, testing, and debugging into just a few days of focused, in-person collaboration.
By Friday, these three critical development threads converged, culminating in the week’s headline achievement: a credible and well-supported target for a 200 million post-Glamsterdam gas limit floor. This significant increase is made possible by the combined efforts: ePBS provides the structural framework and increased execution time within each slot, BAL optimizations deliver the necessary throughput headroom for clients under this new structure, and EIP-8037 ensures that a higher gas limit does not result in unsustainable state growth.
The Week’s Triumphs and Unfinished Business
Beyond the core Glamsterdam pillars, a myriad of other topics were debated and decided upon during dedicated breakout sessions.
Consensus Layer (CL) teams finalized decisions on several smaller Glamsterdam EIPs: EIP-8061 (exit/consolidation churn increase) was included in glamsterdam-devnet-1; EIP-8080 (exits via the consolidation queue) was declined for inclusion; EIP-8045 (slashed-validator duty removal) was scoped down to proposer duties within the look-ahead window only; and EIP-7688 (SSZ stable containers) remains within Glamsterdam’s scope but was held out of glamsterdam-devnet-1 while the team addresses bounded gossip-message size for attestations under progressive lists.
A Wednesday morning EL/CL sync architecture breakout led to the deferral of EIP-8237 from Glamsterdam, preserving optionality for a longer-term "top-up sync" architecture in a future fork. In its place, the group agreed to draft a new EIP that standardizes forkchoiceUpdated / newPayload / getPayload sequencing, specifies a snap-sync initiation handshake, and tightens valid/invalid consistency between the engine API surfaces.
The theme of hardening was pervasive throughout the week. A Thursday session delved into fork-choice compliance testing frameworks, the Diamond repository of reproducible CL edge-case scenarios, and buildoor, EthPandaOps’s external-builder testing tool. The latter was demoed mid-session, prompting a rapid-fire stream of attack scenarios suggested by attendees on the spot, showcasing the real-time, adversarial testing environment.
Glimpses into Ethereum’s Future: Beyond Glamsterdam
Several breakout sessions extended their gaze beyond Glamsterdam, focusing on "Hegotà" and subsequent planned upgrades, outlining the long-term vision for Ethereum.
A deliberately proposal-agnostic session on native Account Abstraction kicked off, meticulously working through the fundamental requirements and constraints any future design must satisfy. Feature-set goals included alternative signature schemes, aggregation, batching, recovery mechanisms, gas sponsorship, and flexible nonces for keystore wallets. These ambitions were carefully balanced against hard constraints related to public-mempool compatibility, statelessness, and robust Layer 2 (L2) Denial-of-Service (DoS) resistance.
A Thursday FOCIL (Forward-Compatible Index Lists) breakout provided implementation updates, revealing that early prototypes were already functional. The immediate next steps include multi-client interop and a dedicated FOCIL devnet. Two notable design decisions were also made: disabling FOCIL during periods of 2-epoch non-finality (mirroring proposer-boost circuit-breaker behavior), and adopting an index-based bookmark approach to ensure compatibility with frame transactions and EIP-7702.
Looking further ahead, a long-running ETH P2P track sketched out a QUIC-based replacement for libp2p, envisioning a new peer-to-peer networking layer with privacy-by-default and slot-aware integration. Alongside this, an erasure-coded broadcast prototype demonstrated impressive performance, simulating approximately six times faster propagation than the existing GossipSub protocol on 2.4 MB payloads. The CL track also surfaced strong sentiment towards eventually deprecating validator consolidations entirely. The vision is to declare a final fork that supports them, then mandate an exit-then-redeposit process thereafter, as a cleaner, long-term solution to managing validator-set state growth.
Evolving Governance: Refining the AllCoreDevs Process
On Wednesday afternoon, Nixo and Ansgar, the two co-leads for the AllCoreDevs Execution (ACDE) calls, facilitated a crucial session to gather input from core contributors on the overall ACD process. The discussion revisited the "headliner construct," a mechanism for prioritizing major themes for hard forks, and debated the merits of maintaining a "strawmap" outlining future fork plans. Additionally, the criteria for EIP SFI (Signaling for Inclusion) were formalized, defining the readiness of Ethereum Improvement Proposals for inclusion in a fork.
The consensus from the room favored retaining headliners but with greater flexibility, accepting "theme + candidate EIP" as a viable pattern rather than rigid EIP-centric focus. The straw map’s specific year assignments for forks beyond 2026 were flagged as overly canonicalized and likely to be softened, acknowledging the dynamic nature of development. A new four-point SFI definition was put forward, with ACDT (AllCoreDevs Testing) signaling readiness and ACDE/ACDC (AllCoreDevs Consensus) retaining the final call. A new prioritization-ordering process, to be produced after Call For Inclusion (CFI) decisions and reflected in the meta-EIP, will replace SFI’s previous role in driving devnet inclusion, commencing with the Hegotà upgrade.
On the call-coordination front, Alex Stokes announced a three-month sabbatical, with Pari stepping in to cover ACDC moderation in the interim, and Barnabas filling in for ACDT. The leadership structure for these critical coordination calls will now see Nixo and Ansgar chairing ACDE, Pari as interim on ACDC, and Mario, Barnabas, and Danceratopz rotating ACDT moderation. These changes reflect the ongoing commitment to robust and transparent governance within Ethereum’s core development.
A Collaborative Endeavor: Beyond the Code
Beyond the major technical advancements, the in-person environment fostered progress on a wide array of supporting initiatives. Teams leveraged the collaborative atmosphere to develop better test harnesses, significantly compressing Hive feedback loops from hours to minutes. Improvements to engine-API plumbing were made, including gossip deduplication, batched calls, and light-client-driven head discovery. Crucial discussions also took place regarding hard tradeoffs around client diversity, a cornerstone of Ethereum’s resilience. The comprehensive list of all session notes and detailed outcomes remains publicly available at soldogn.xyz.
The success of Soldøgn was a testament to the collective effort. Special appreciation was extended to EthPandaOps for their instrumental role in organizing and energizing the group daily, and to every contributor who worked tirelessly under the midnight sun, including the Ethrex crew, who marked their first interop attendance.
The Road Ahead: From Prototype to Production
With the Soldøgn Interop concluded, core developers now return home to translate the week’s prototypes and refined specifications into production-ready code. The coming weeks will be characterized by intense, heads-down work: hardening client implementations against the new specifications, finalizing comprehensive test coverage, and transforming Soldøgn’s draft pull requests into merged code.
As always, the final decisions on critical parameters such as the 200 million gas limit target and the definitive repricing numbers will be publicly discussed and announced on the regular AllCoreDevs calls. These discussions are expected to be the major topics of the upcoming weeks, bringing the Glamsterdam upgrade closer to its mainnet deployment. The Soldøgn Interop stands as a powerful reminder of the collaborative spirit and relentless dedication driving Ethereum’s continuous evolution.
