Longyearbyen, Svalbard – High above the Arctic Circle, amidst the perpetual daylight of Longyearbyen, Svalbard, over 100 Ethereum core contributors recently concluded the "Soldøgn Interop." This intensive week-long gathering was dedicated to the "Glamsterdam" network upgrade, a pivotal step in Ethereum’s ongoing evolution towards greater scalability and efficiency. The secluded, unique setting proved fertile ground for focused development, culminating in significant breakthroughs that promise to enhance the network’s capacity and robustness.
The interop successfully solidified three critical objectives for Glamsterdam: a firm alignment on a post-Glamsterdam gas limit floor of 200 million, the successful implementation of stable ePBS (Execution-Proposer-Builder Separation) with external builders, and the finalization of repricing numbers for EIP-8037. Beyond Glamsterdam, the gathering also saw meaningful progress on features earmarked for the subsequent "Hegotå" upgrade, including FOCIL and native account abstraction, alongside a myriad of other crucial discussions.
The Arctic Crucible: A Unique Setting for Intense Development
The choice of Svalbard, an archipelago nestled at 78° North latitude, was more than just a picturesque backdrop; it was a deliberate decision reflecting Ethereum’s ethos of continuous operation and long-term resilience. Svalbard stands as one of the rare places on Earth where individuals of any nationality can reside and work without a visa, embodying a spirit of global collaboration.
Moreover, Longyearbyen is famously home to the Global Seed Vault and the Arctic World Archive. These cold-storage facilities, burrowed deep into the permafrost, safeguard humanity’s most vital data – from crop seeds to historical manuscripts and critical source code, including a snapshot of Ethereum’s own foundational code. This symbolic connection to preserving the future resonated deeply with the developers working on the next generation of a decentralized global computer.
Perhaps most fittingly, from late April through August, Svalbard experiences the phenomenon of the "midnight sun," where the sun never sets. This provided a literal "24/7 uptime" environment, mirroring Ethereum’s own design principles and allowing core developers to maximize their productivity throughout the week. The relentless daylight underscored the intense, round-the-clock focus demanded by the Soldøgn Interop.
A Legacy of Focused Collaboration: The Interop Format
The Soldøgn Interop continued a tradition of highly focused, multi-client development sprints that have become instrumental in guiding Ethereum’s network upgrades. While last year’s Berlinterop adopted a broader format, Soldøgn returned to the highly effective single-track model championed by previous gatherings such as Amphora, Edelweiss, and Nyota. This structure ensures concentrated progress towards specific upgrade goals, with Glamsterdam’s hardening being the primary focus.
These interops are crucial for fostering real-time collaboration among the diverse teams developing various Ethereum client implementations. By bringing together the brightest minds in a shared physical space, complex technical challenges that might otherwise take weeks or months to resolve asynchronously can be tackled in a matter of hours or days, significantly accelerating the development roadmap.
Glamsterdam’s Mandate: Hardening and Scaling Ethereum
The overarching goal of the Soldøgn Interop was unequivocally clear: to harden Glamsterdam implementations and establish a credible target for a post-upgrade gas limit floor. Raising the gas limit safely is a multi-faceted challenge, requiring careful consideration of how blocks are constructed and proposed, the operational headroom of client implementations under stress, and the scalability of state-creation costs relative to network throughput.
The week’s work was designed to culminate in a stable, multi-client Glamsterdam development network (devnet) running the latest specifications for ePBS, repricing, and block access lists. Crucially, it aimed to gather robust benchmarking data to support a definitive gas limit proposal. Much of the week involved developers heads-down, immersed in writing code, often stretching into the early hours, punctuated by frequent breakout sessions to align on design decisions and strategize for longer-term roadmap items.
Crucial infrastructure support was provided by three Ethereum Foundation (EF) teams: EthPandaOps deployed ethIQ and a panda MCP server to streamline agentic workflows; Protocol Support managed the soldogn.xyz portal, serving as the central hub for interop goals, schedules, and notes; and the EF Digital Studio team meticulously documented the entire week on film, promising an unprecedented interop documentary.
Deep Dive into ePBS: Reshaping Block Construction
A cornerstone of the Glamsterdam upgrade is ePBS (Execution-Proposer-Builder Separation). This critical mechanism not only refines the relationship between block proposers and builders but fundamentally restructures the slot system itself. By introducing explicit deadlines for block construction, payload reveal, and attestations, ePBS precisely defines the time allocated for execution. This increased clarity and structure are vital for creating the necessary headroom to safely increase the network’s gas limit.
The ePBS track began with an ambitious goal: to achieve a stable 4 Execution Layer (EL) x 4 Consensus Layer (CL) Glamsterdam devnet by Monday evening. Initial attempts revealed a series of issues, pushing the target to Tuesday, when a 4×3 configuration finally achieved sufficient stability for stress testing to commence.
The remainder of the week was dedicated to an intensive ePBS hardening cycle: stress testing, identifying and addressing edge cases, and continuous iteration. A pivotal Tuesday-morning breakout session on the Builder API substantially simplified the specification concerning validator registration, the bid/header/commitments flow, the trust model for builder payments, and circuit-breaker behavior. Mid-week debugging efforts zeroed in on complex cross-client edge cases, particularly regarding the invalidation of beacon requests by execution requests. A new test suite revealed a surprising gap across nearly all client implementations, highlighting the value of such in-person interops. By Thursday morning, CL teams reported stable ePBS functionality, while EL-side bid pathways were debugged and resolved through Thursday and into Friday.
Two significant questions remain subject to active debate among AllCoreDevs (ACD): 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 P2P Sybil-based liveness attacks. Despite these open points, by Friday, nearly all clients were successfully running together on glamsterdam-devnet-2, with the external builders pipeline thoroughly tested end-to-end.
BAL Optimizations: Boosting Execution Layer Throughput
While ePBS addresses the consensus layer’s scaling story, the execution layer’s parallel efforts revolve around gas repricings and Block-Level Access Lists (BALs), as defined by EIP-7928. BALs are designed to provide clients with upfront information about a block’s read/write set. This crucial data enables parallel execution, batched I/O operations, and parallel state-root computation – all factors that directly influence the maximum block size clients can efficiently process.
The Soldøgn BAL track operated on its own dedicated devnets, distinct from the Glamsterdam ePBS chains. This separation ensured that optimization benchmarks were not conflated with consensus-layer stabilization efforts. Each optimization was placed behind its own feature flag, allowing for isolated measurement and comparison. 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 effectively raise the overall gas limit floor, rather than merely optimizing for the fastest individual implementation.
Gas Repricings: Calibrating Costs for Future Throughput
Glamsterdam also incorporates several execution layer gas repricings, recalibrating operational costs to better reflect actual resource usage at higher throughput levels. Central to this is EIP-8037, which proposes an increase in state-creation gas costs. The intent is to raise the price of writing new state, thereby preventing a higher gas limit from leading to unbounded state growth, which could negatively impact network health.
Heading into Soldøgn, the EIP-8037 specification included dynamic per-state-byte pricing tied to the block gas limit. This dynamic approach presented significant testing and benchmarking hurdles, requiring a combinatorial fuzz matrix for each gas limit band, making practical measurement nearly intractable. Early in the week, teams decisively agreed to drop dynamic pricing in favor of a fixed cost_per_state_byte, with future repricing adjustments to be handled at subsequent fork boundaries, rather than within a single fork.
The accounting model for EIP-8037 followed a more iterative and at times challenging path. A Monday breakout 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. By Wednesday, reservoir refund/refill edge cases emerged, necessitating a complete re-evaluation. A Thursday breakout reverted accounting to the opcode level, concluding that the primary complexity lay in the reservoir model itself, not in the accounting computation. By Friday, the specification had stabilized on bal-devnet-6, with the BAL track delivering the final repricing numbers. This intensive, iterative process perfectly exemplified the power of interops: resolving complex spec, implementation, testing, debugging, and design issues in hours rather than weeks, effectively compressing months of asynchronous progress into each day.
By the end of the week, these three critical threads—ePBS, BAL optimizations, and gas repricings—converged to yield the week’s headline achievement: a credible 200 million post-Glamsterdam gas limit floor. This substantial increase in capacity is directly attributable to ePBS structuring the slot to provide more execution time, BAL optimizations granting clients the necessary throughput headroom, and EIP-8037 ensuring that the higher gas limit does not result in unchecked state growth.
Other Glamsterdam Threads: Refining the Upgrade Scope
Beyond the core pillars of ePBS, BALs, and repricings, the remaining scope of Glamsterdam was meticulously addressed through a series of focused breakout sessions.
Consensus Layer (CL) teams finalized decisions on several smaller Glamsterdam EIPs: EIP-8061 (exit/consolidation churn increase) was formally included in glamsterdam-devnet-1; EIP-8080 (exits via the consolidation queue) was declined for inclusion; EIP-8045 (slashed-validator duty removal) was refined to cover only proposer duties within the look-ahead window; and EIP-7688 (SSZ stable containers) remains within Glamsterdam’s scope but was held out of glamsterdam-devnet-1 pending further work on bounded gossip-message size for attestations under progressive lists.
A Wednesday-morning breakout on EL/CL sync architecture led to the deferral of EIP-8237 from 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 across the engine API surfaces.
Hardening remained a constant theme throughout the week. A Thursday session delved into fork-choice compliance testing frameworks, the Diamond repository of reproducible CL edge-case scenarios, and buildoor, PandaOps’s external-builder testing tool. The latter was demonstrated live, eliciting a rapid-fire stream of attack scenarios from attendees, which were then immediately tested, highlighting the real-time problem-solving capabilities of the interop format.
Beyond Glamsterdam: Glimpses into Ethereum’s Future
Several breakouts at Soldøgn looked beyond the immediate Glamsterdam upgrade, peering into the future with "Hegotå" and subsequent forks.
A deliberately proposal-agnostic session on native Account Abstraction kicked off discussions, meticulously working through the requirements and constraints any future design must satisfy. Feature-set goals like alternative signature schemes, aggregation, batching, recovery, gas sponsorship, and flexible nonces were explored alongside critical hard constraints such as public-mempool compatibility, statelessness, and L2 DoS resistance.
A Thursday FOCIL breakout provided updates on its implementation. Early prototypes were reported as functional, with multi-client interop and a dedicated FOCIL devnet identified as immediate next steps. Two key design decisions were made: FOCIL will be disabled during two-epoch non-finality (mirroring proposer-boost circuit-breaker behavior), and an index-based bookmark approach will be adopted for compatibility with frame transactions and EIP-7702.
Looking even further ahead, a long-running ETH P2P track sketched out a QUIC-based replacement for libp2p, envisioning privacy-by-default and slot-aware integration. An erasure-coded broadcast prototype demonstrated impressive results, simulating approximately six times faster propagation than GossipSub for 2.4 MB payloads. The CL track also revealed strong sentiment towards eventually deprecating consolidations entirely, proposing a final fork that supports them before requiring exit-then-redeposit for validators, as a cleaner long-term solution to validator-set state growth.
Refining the ACD Process: Governance and Leadership
On Wednesday afternoon, Nixo and Ansgar, the two AllCoreDevs Execution (ACDE) co-leads, facilitated a crucial session to gather input from core contributors on the overall ACD process. The discussion revisited the "headliner construct," debated the merits and drawbacks of maintaining a "strawmap" for future upgrades, and formalized the EIP SFI (Specification Finalization Initiative) criteria. The consensus was to retain headliners but introduce greater flexibility, allowing for a "theme + candidate EIP" pattern. The per-fork year assignments in the strawmap beyond 2026 were deemed overly canonicalized and likely to be softened. 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 CFI (Call for Inclusion) decisions and reflected in the meta-EIP, will replace SFI’s traditional role in driving devnet inclusion, starting with Hegotå.
In terms of call coordination, Alex Stokes announced a three-month sabbatical commencing next week. During this period, Pari will cover ACDC moderation, with Barnabas stepping in for ACDT. The leadership structure for these crucial calls was clarified: Nixo and Ansgar will continue to chair ACDE, Pari will serve as interim ACDC moderator, and Mario, Barnabas, and Danceratopz will rotate ACDT moderation duties. This ensures continuity and robust leadership during a period of intense development.
Everything Else: The Unsung Progress
Beyond the meticulously planned agenda items, the in-person collaboration at Soldøgn facilitated progress on countless other crucial tasks. Teams optimized test harnesses, compressing Hive feedback loops from hours to minutes, significantly accelerating development cycles. Improvements were made to engine-API plumbing, including gossip deduplication, batched calls, and light-client-driven head discovery. Developers also engaged in frank discussions about hard tradeoffs concerning client diversity, among many other topics. The comprehensive session notes, providing a full account of these myriad discussions, are available at soldogn.xyz.
Next Steps: From Arctic Prototyping to Production Readiness
With the Soldøgn Interop now concluded, core development teams return home with a clear mandate: to transform the prototypes and breakthroughs achieved in Svalbard into production-ready code. The coming weeks will be characterized by heads-down work, focusing on hardening client implementations against the new specifications, finalizing comprehensive test coverage, and merging Soldøgn’s draft PRs into the main codebase.
As is standard practice, the final decisions for critical values such as the 200 million gas limit target and the definitive repricing numbers will be publicly discussed and announced during upcoming AllCoreDevs calls, which are expected to heavily feature these topics in the immediate future.
The Ethereum community extends its profound gratitude to every contributor who journeyed to 78°N and contributed to the success of this monumental week. Special recognition is due to EthPandaOps for their exceptional organizational prowess, and to everyone who worked tirelessly under the midnight sun to meet daily goals – including the Ethrex crew, who made their impactful debut at this interop. It was an incredibly productive week, a testament to the power of focused, collaborative effort, and the community eagerly anticipates the full short film documenting this historic event.
