Longyearbyen, Svalbard – High above the Arctic Circle, amidst the stark beauty and perpetual daylight of Longyearbyen, Svalbard, over 100 Ethereum core contributors convened last week for the "Soldøgn Interop." This intensive, week-long gathering was dedicated to accelerating development on the upcoming "Glamsterdam" network upgrade, a pivotal step in Ethereum’s journey towards enhanced scalability and efficiency. The secluded, yet symbolically significant, location provided a unique backdrop for the focused, multi-client collaboration that has become a hallmark of Ethereum’s development process.
The Soldøgn Interop culminated in significant breakthroughs, solidifying key parameters for the Glamsterdam upgrade. Foremost among these achievements was the consensus on a post-Glamsterdam gas limit floor of 200 million, a substantial increase designed to boost network throughput. Additionally, core developers successfully implemented stable ePBS (enshrined Proposer-Builder Separation) with external builders, a critical component for block construction and efficiency. The final repricing numbers for EIP-8037, aimed at calibrating state-creation costs, were also locked in, addressing concerns about unbounded state growth. Beyond Glamsterdam, the interop laid crucial groundwork for future upgrades like "Hegotá," making meaningful progress on features such as FOCIL (Forecasting-Optimized Consensus for Increased Liveness) and native account abstraction.
A Return to Focused Interoperability
Following last year’s "Berlinterop," Soldøgn marked a return to the highly focused, single-track format reminiscent of previous successful interops like "Amphora," "Edelweiss," and "Nyota." This concentrated approach allows diverse client teams to work in lockstep, ironing out incompatibilities and hardening implementations for a specific upgrade. For Soldøgn, the singular objective was to robustly prepare the Glamsterdam upgrade for its mainnet deployment.
The week’s intense schedule saw developers working late into the Arctic’s "midnight sun," a symbolic mirroring of Ethereum’s 24/7 uptime. The collaborative spirit, combined with the unique environment, proved incredibly productive, compressing weeks of asynchronous development into a few days of face-to-face problem-solving.
Why Svalbard? A Strategic and Symbolic Choice
The choice of Longyearbyen, Svalbard, as the interop venue was both practical and profoundly symbolic. As one of the few places on Earth where individuals of any nationality can live and work without a visa, it embodies the global, permissionless ethos of Ethereum. More strikingly, Svalbard is home to the Global Seed Vault and the Arctic World Archive, two crucial cold-storage facilities tunneled deep into the permafrost. These archives safeguard humanity’s most vital information—from crop seeds to historical documents and, notably, a snapshot of Ethereum’s source code—ensuring their survival for millennia. This commitment to long-term preservation resonated deeply with Ethereum’s own mission to build a resilient, enduring digital infrastructure.
The constant daylight from late April through August provided an additional, albeit less conventional, benefit. This "24/7 uptime" for the sun mirrored Ethereum’s own continuous operation, serving as a subtle reminder of the network’s unwavering availability, which the core developers certainly capitalized on during their intense work sessions.
Hardening Glamsterdam: Scaling Ethereum’s Future
The overarching goal of the Soldøgn Interop was to "Harden Glamsterdam" and establish a credible target for a significantly increased gas limit. Raising the gas limit safely is a complex, multi-faceted challenge, requiring careful consideration of how blocks are constructed and proposed, client performance under heavy load, and the scaling of state-creation costs alongside transaction throughput. Glamsterdam addresses several of these critical dimensions through its key components: ePBS, Block-Level Access Lists (BALs), and gas repricings (EIP-8037).
By Friday, the group had successfully established a stable multi-client Glamsterdam devnet, running the latest ePBS, repricing, and block access list specifications. This operational devnet, combined with extensive benchmarking data, provided the necessary foundation to propose a robust 200 million gas limit. The week primarily involved heads-down coding, interspersed with crucial breakout sessions to align on design decisions and discuss the longer-term roadmap.
Essential infrastructure support was provided by three Ethereum Foundation (EF) teams. EthPandaOps delivered ethIQ for performance monitoring and a panda MCP server to streamline agentic workflows. Protocol Support maintained soldogn.xyz as the single source of truth for interop goals, schedules, and notes. The EF Digital Studio team diligently documented the entire week on film, promising the very first interop documentary.
ePBS: Restructuring for Greater Throughput
Enshrined Proposer-Builder Separation (ePBS) is a cornerstone of Glamsterdam’s scaling strategy. Beyond simply refining the relationship between block proposers and builders, ePBS fundamentally restructures transaction slots by introducing explicit deadlines for block construction, payload revelation, and attestations. This clear allocation of time for execution is vital, as it directly increases the headroom available for raising the gas limit without compromising network stability.
The week began with an ambitious goal: to establish a 4 Execution Layer (EL) x 4 Consensus Layer (CL) Glamsterdam devnet by Monday evening. Initial attempts revealed several issues, pushing the target to Tuesday, when a 4×3 configuration achieved sufficient stability for stress testing to commence.
The remainder of the week was dedicated to an intensive ePBS hardening cycle: stress testing, identifying edge cases, patching bugs, and repeating the process. A Tuesday-morning Builder API breakout session was particularly fruitful, significantly simplifying the specification for 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, notably regarding execution-request invalidation of beacon requests. A new test suite exposed a critical gap across all client implementations, which was swiftly addressed. By Thursday morning, CL teams reported stable ePBS, with EL-side bid pathways being debugged and resolved by Friday. Two contentious questions remained for AllCoreDevs (ACD) consideration: whether a request signature should commit to the receiving builder, and how to maintain the resilience of a 1 ETH-staked-builder design against P2P Sybil-based liveness attacks.
By Friday’s close, nearly all clients were successfully running together on glamsterdam-devnet-2, with the external builders pipeline thoroughly tested end-to-end.
BAL Optimizations: Enabling Parallel Execution
If ePBS provides the consensus-layer foundation for Glamsterdam’s scaling, Block-Level Access Lists (BALs), defined in EIP-7928, are its execution layer counterpart. BALs provide clients with crucial upfront information about a block’s read/write set, enabling advanced optimizations such as parallel execution, batched I/O operations, and parallel state-root computation. These capabilities are fundamental to determining 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 optimization benchmarks to proceed without being entangled with consensus-layer stabilization efforts. Each optimization was placed behind its own feature flag, enabling isolated measurement and comparison rather than as a single bundled update. 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 collectively elevate the gas limit floor for the entire ecosystem, rather than just for the fastest individual implementation.
Gas Repricings: Managing State Growth with EIP-8037
Glamsterdam also incorporates several Execution Layer (EL) gas repricings, recalibrating transaction costs to more accurately reflect resource usage at higher throughputs. At the heart of this is EIP-8037, which proposes an increase in state-creation gas costs. This is a critical mechanism to ensure that a higher gas limit does not lead to unbounded state growth, maintaining the long-term health and efficiency of the network.
Prior to Soldøgn, the EIP-8037 specification included dynamic per-state-byte pricing tied to the block gas limit. This approach presented significant challenges for testing (requiring a separate fuzz matrix for each gas limit band) and made benchmarking nearly impossible. Recognizing this hurdle, teams agreed early in the week to simplify the design by replacing dynamic pricing with a fixed cost_per_state_byte. Future repricing adjustments will now be handled at fork boundaries, rather than within a single fork, greatly streamlining implementation and testing.
The accounting model for gas repricing followed a more iterative path. A Monday breakout session moved state-gas accounting from mid-execution to the end-of-call-frame. A Tuesday follow-up addressed account creation costs, code deposit costs, and CREATE-transaction reverts. Wednesday’s discussions surfaced complex reservoir refund/refill edge cases, necessitating a fundamental re-evaluation. A Thursday breakout ultimately reverted accounting to the opcode level, concluding that the primary complexity resided in the reservoir model itself, not the accounting computation. By Friday, the specification for bal-devnet-6 had stabilized, with the BAL track delivering the final repricing numbers.
This iterative development process perfectly illustrates the power of interop weeks: the ability to resolve intricate specification, implementation, testing, debugging, and design challenges in mere hours, rather than the weeks or months typically required for asynchronous progress.
By Friday, the three major threads—ePBS, BAL optimizations, and gas repricings—converged to deliver the week’s headline achievement: a credible 200 million post-Glamsterdam gas limit floor. This substantial increase is deemed safe and feasible because ePBS provides more execution time within each slot, BAL optimizations offer clients the necessary throughput headroom under this new structure, and EIP-8037 ensures that the higher gas limit does not result in unsustainable state growth.
Other Glamsterdam Threads: Refining the Upgrade Scope
Beyond the core components, numerous other Glamsterdam-related topics were extensively debated and refined in breakout sessions throughout the week.
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, prioritizing simplicity.
- EIP-8045 (slashed-validator duty removal) was scoped down to proposer duties within the look-ahead window only.
- EIP-7688 (SSZ stable containers) remains within Glamsterdam’s scope but was held out of
glamsterdam-devnet-1while the team addresses bounded gossip-message size for attestations under progressive lists.
A Wednesday-morning EL/CL sync architecture breakout decided to defer EIP-8237 out of Glamsterdam. This decision was made to preserve 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, and getPayload sequencing, specifies a snap-sync initiation handshake, and tightens valid/invalid consistency between the engine API surfaces.
"Hardening" remained a constant theme. A Thursday session focused on fork-choice compliance testing frameworks, the Diamond repository of reproducible CL edge-case scenarios, and buildoor, PandaOps’s external-builder testing tool. The buildoor demo, showcasing its ability to generate numerous attack scenarios on the spot, was particularly insightful for attendees.
Beyond Glamsterdam: Glimpses into Hegotá and Future Forks
While Glamsterdam was the immediate focus, several breakout sessions looked further ahead, exploring features for the "Hegotá" upgrade and subsequent forks.
A deliberately proposal-agnostic session on native Account Abstraction kicked off discussions, working through the comprehensive 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 enhanced user experience and wallet design. These ambitious goals were balanced against strict constraints concerning public-mempool compatibility, statelessness, and robust Layer 2 DoS resistance.
A Thursday FOCIL breakout provided crucial implementation updates. Early prototypes were already functional, with multi-client interop and a dedicated FOCIL devnet identified as the immediate next steps. Two notable design decisions emerged: disabling FOCIL during 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 even further out, a long-running ETH P2P track sketched out a QUIC-based replacement for libp2p. This proposed replacement aims to offer privacy-by-default and slot-aware integration, promising significant improvements in network communication. The team also demoed an erasure-coded broadcast prototype that simulated approximately six times faster propagation than GossipSub for 2.4 MB payloads, a critical improvement for efficient data dissemination. The CL track also revealed strong sentiment towards eventually deprecating consolidations entirely, suggesting a final fork that supports them before forcing an exit-then-redeposit process afterwards. This strategic move is seen as a cleaner, long-term solution to managing validator-set state growth.
Refining the AllCoreDevs (ACD) Process
On Wednesday afternoon, Nixo and Ansgar, the two AllCoreDevs Execution (ACDE) co-leads, facilitated a crucial session to gather input from core contributors regarding the ACD process itself. The session revisited the "headliner construct," debated the merits and drawbacks of maintaining a "strawmap," and formalized the criteria for EIPs (Ethereum Improvement Proposals) to achieve "Specification Finality & Inclusion" (SFI).
The room generally favored retaining the concept of headliners but sought to loosen the rigid "EIP-vs-theme" distinction, accepting "theme + candidate EIP" as a more flexible pattern. The per-fork year assignments in the straw map beyond 2026 were flagged as overly canonicalized and likely to be softened in future iterations. A new, four-point SFI definition was put forward, with ACD Testnet (ACDT) signaling readiness and ACDE/ACD Consensus (ACDC) 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 of driving devnet inclusion, starting with the Hegotá upgrade.
On the call-coordination side, Alex Stokes announced a three-month sabbatical, with Pari stepping in to cover ACDC moderation in the interim and Barnabas filling in for ACDT. This ensures continuity in leadership, with Nixo and Ansgar chairing ACDE, Pari as interim ACDC moderator, and Mario, Barnabas, and Danceratopz rotating ACDT moderation.
Everything Else: A Week of Broad Progress
Beyond the major Glamsterdam and Hegotá initiatives, the in-person interop facilitated progress on a wide array of other critical development areas. Teams leveraged the direct collaboration to improve test harnesses, compressing Hive feedback loops from hours to mere minutes. Significant advancements were made in engine-API plumbing, including gossip deduplication, batched calls, and light-client-driven head discovery. Crucial discussions also tackled difficult tradeoffs surrounding client diversity and many other topics. The comprehensive list of session notes is publicly available at soldogn.xyz.
Next Steps: From Prototype to Production
With the Soldøgn Interop concluded, core development teams are now returning home to translate the week’s prototypes and refined specifications into production-ready code. The coming weeks will be characterized by intensive work on hardening client implementations against the new specifications, finalizing comprehensive test coverage, and merging Soldøgn’s draft PRs into the main codebase.
The final decisions regarding critical values such as the 200 million gas limit target and the definitive repricing numbers will be publicly announced and discussed during the upcoming AllCoreDevs calls, which are expected to be the primary focus of the next week.
The success of Soldøgn was a testament to the dedication and collaborative spirit of the Ethereum core contributors, who journeyed to 78°N to advance the network. Special recognition was given to EthPandaOps for their organizational prowess and to all who worked tirelessly under the perpetual daylight, including the Ethrex crew, who participated in their first interop. It was an exceptionally productive week, and the upcoming documentary promises to capture its unique spirit and achievements.
