Layla Zulfa
Just over 100 Ethereum core contributors recently concluded the Soldøgn Interop, a week-long, intensive work session held in the remote Arctic outpost of Longyearbyen, Svalbard. This high-stakes gathering above the Arctic Circle focused primarily on hardening the upcoming "Glamsterdam" network upgrade, a pivotal step in Ethereum’s ongoing scalability roadmap. The collaborative effort culminated in significant progress across key technical domains, notably establishing a post-Glamsterdam gas limit floor of 200 million, stabilizing ePBS implementations with external builders, and locking in final repricing numbers for EIP-8037. Beyond Glamsterdam, developers also advanced features for the subsequent "Hegotå" upgrade, including FOCIL and native account abstraction, alongside a myriad of other critical topics.
The Strategic Significance of Interop Events
The Soldøgn Interop is the latest in a series of crucial, focused gatherings designed to accelerate Ethereum’s development trajectory. Following in the footsteps of previous successful interops like Amphora (2021), Edelweiss (2023), Nyota (2024), and Berlinterop (2025), Soldøgn returned to a single-track format, prioritizing deep, multi-client collaboration on a specific network upgrade. These events are essential for fostering direct communication, resolving complex technical disagreements in real-time, and rapidly iterating on implementation challenges that would otherwise take weeks or months to address asynchronously. The compressed timeline of an interop week, where a month of progress can be achieved in days, underscores their value in maintaining Ethereum’s ambitious development pace. The goal of "hardening Glamsterdam" specifically referred to ensuring robust, secure, and performant implementations across various client teams (such as Geth, Erigon, Nethermind, Besu for the execution layer, and Lighthouse, Teku, Prysm, Nimbus for the consensus layer), which is paramount for a seamless network upgrade.
Svalbard: A Symbolic and Practical Setting for Decentralized Development
The choice of Longyearbyen, Svalbard, as the venue for Soldøgn was both symbolic and highly practical. Situated at 78°N latitude, it is one of the northernmost settlements on Earth. Svalbard stands out as one of the few places globally where individuals, regardless of nationality, can reside and work without a visa, embodying a spirit of open access and collaboration that resonates with Ethereum’s decentralized ethos. Furthermore, Svalbard is home to the Global Seed Vault and the Arctic World Archive, two renowned cold-storage facilities burrowed into the permafrost, safeguarding humanity’s most critical data, including a snapshot of Ethereum’s source code, for millennia to come. This aligns with Ethereum’s commitment to long-term resilience and preservation. From late April through August, Svalbard experiences the phenomenon of the "midnight sun," with 24/7 daylight – a poetic parallel to Ethereum’s own commitment to 24/7 uptime and continuous operation. This perpetual daylight, as core developers noted, was fully leveraged, enabling extended work hours and an immersive environment for intense focus.
Glamsterdam: Scaling Ethereum for the Future
The primary objective of the Soldøgn Interop was to solidify Glamsterdam implementations and establish a definitive target for a post-upgrade gas limit floor. Raising Ethereum’s gas limit safely is a multifaceted challenge, involving intricate considerations of how blocks are constructed and proposed, the operational headroom of client implementations under peak load, and the scaling of state-creation costs relative to transaction throughput. Glamsterdam directly addresses several of these dimensions.
The week’s efforts were designed to achieve a stable multi-client Glamsterdam development network running the latest specifications for ePBS (enshrined Proposer-Builder Separation), repricing mechanisms, and block access lists (BAL). This stable devnet, coupled with comprehensive benchmarking data, was crucial for validating a credible proposal for the increased gas limit. Much of the week was characterized by developers deeply engaged in coding, often extending into the early morning hours, interspersed with focused breakout sessions to synchronize on design decisions and strategize future roadmap items.
Crucial infrastructure support was provided by three Ethereum Foundation (EF) teams. EthPandaOps deployed ethIQ for performance monitoring and a "panda MCP server" to facilitate agentic workflows. Protocol Support managed soldogn.xyz, serving as the central repository for interop goals, schedules, and detailed notes. The EF Digital Studio team documented the entire week on film, with an upcoming interop documentary expected to capture the essence of this historic gathering.
Deep Dive into Glamsterdam’s Core Components
Enshrined Proposer-Builder Separation (ePBS): Enhancing Consensus Layer Efficiency
ePBS is a cornerstone of the Glamsterdam upgrade, fundamentally restructuring the block production process. It aims to clean up the relationship between block proposers (validators) and block builders by introducing explicit deadlines for block construction, payload reveal, and attestations within each slot. This restructuring delineates more time for execution processes, directly contributing to the capacity to safely increase the gas limit.
The week began with an ambitious goal: to establish a stable 4 Execution Layer (EL) x 4 Consensus Layer (CL) Glamsterdam devnet by Monday evening. Initial attempts revealed several integration 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: rigorous stress testing, identification and resolution of edge cases, and repeated iteration. A pivotal Builder API breakout session on Tuesday morning significantly streamlined 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, particularly concerning execution-request invalidation of beacon requests. A new test suite exposed a critical gap across all client implementations, which was subsequently addressed. By Thursday morning, CL teams reported stable ePBS, while EL-side bid pathways were debugged and resolved through Thursday and Friday. Two genuinely contentious questions remain for All Core Devs (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. Despite these, by Friday, nearly all clients were successfully running together on glamsterdam-devnet-2, with the external builders pipeline thoroughly tested end-to-end.
Block-Level Access List (BAL) Optimizations: Boosting Execution Layer Throughput
While ePBS fortifies the consensus layer, the execution layer’s scaling story in Glamsterdam is largely driven by gas repricings and Block-Level Access Lists (EIP-7928). BALs provide clients with upfront information about a block’s read/write set, enabling crucial optimizations such as parallel execution, batched I/O operations, and parallel state-root computation. These optimizations are vital for determining the maximum block size that clients can comfortably process without performance degradation.
The Soldøgn BAL track operated on dedicated devnets, distinct from the Glamsterdam ePBS chains, to ensure that optimization benchmarks were not conflated with consensus-layer stabilization efforts. Each optimization was implemented behind its own feature flag, allowing for isolated comparison and measurement throughout the week. The newly developed BAL benchmark dashboard and leaderboard were instrumental in highlighting each client’s worst-case scenarios across the test suite. By systematically addressing and improving the slowest paths first, teams could collectively elevate the gas limit floor across all implementations, rather than merely optimizing for the fastest ones.
Gas Repricings: Calibrating Resource Usage with EIP-8037
Glamsterdam integrates several Execution Layer gas repricings aimed at better aligning transaction costs with actual resource usage, especially at higher throughput levels. EIP-8037, specifically designed to increase state-creation gas costs, is central to this effort. Its purpose is to prevent an increased gas limit from leading to unbounded state growth, ensuring the long-term health and sustainability of the Ethereum network.
Entering Soldøgn, the EIP-8037 specification featured dynamic per-state-byte pricing tied to the block gas limit, a complexity that made testing combinatorially arduous and benchmarking nearly impossible. Recognizing this challenge, teams quickly agreed early in the week to simplify the design by replacing dynamic pricing with a fixed cost_per_state_byte. Future repricing adjustments would then be handled at subsequent hard fork boundaries rather than within a single fork.
The accounting model itself evolved iteratively throughout the week. A Monday breakout session shifted 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. The Thursday breakout ultimately reverted accounting to the opcode level, concluding that the primary complexity resided in the reservoir model, not the accounting computation itself. By Friday, the specification had stabilized on bal-devnet-6, with the BAL track delivering the final repricing numbers.
This rapid, iterative problem-solving exemplified the profound benefits of interop events. The ability to resolve complex specification, implementation, testing, debugging, and design issues in hours rather than weeks is a hallmark of these in-person collaborations.
By the close of the week, these three critical threads—ePBS enhancements, BAL optimizations, and EIP-8037 repricings—converged to yield the week’s headline achievement: a credible and well-supported proposal for a 200 million post-Glamsterdam gas limit floor. This substantial increase, a more than six-fold jump from the current 30 million gas limit, is made possible by ePBS restructuring the slot to allocate more time for execution, BAL optimizations providing clients with the necessary throughput headroom, and EIP-8037 ensuring that a higher gas limit does not result in unsustainable state growth.
Other Glamsterdam Development Threads
Beyond the core pillars of ePBS, BALs, and repricings, numerous other aspects of the Glamsterdam scope were addressed and refined through 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 ultimately declined for inclusion. EIP-8045 (slashed-validator duty removal) was scoped down to address only proposer duties within the look-ahead window. EIP-7688 (SSZ stable containers) remains within Glamsterdam’s scope but was held out of glamsterdam-devnet-1 while the team works through issues related to bounded gossip-message size for attestations under progressive lists.
A Wednesday morning breakout session focused on EL/CL sync architecture 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, allowing for more comprehensive design and testing. In its place, the group agreed to draft a new EIP that would standardize forkchoiceUpdated, newPayload, and getPayload sequencing, specify a snap-sync initiation handshake, and tighten valid/invalid consistency across 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 (a collection of reproducible CL edge-case scenarios), and buildoor, PandaOps’s external-builder testing tool. The latter was demonstrated mid-session, eliciting a rapid stream of attack scenarios suggested by attendees, which were then immediately tested, showcasing the efficacy of such tools in identifying vulnerabilities.
Glimpses Beyond Glamsterdam: The Road to Hegotå and Future Forks
Several breakout sessions extended discussions beyond Glamsterdam, looking towards the "Hegotå" upgrade and subsequent forks, outlining the long-term vision for Ethereum.
A deliberately proposal-agnostic session on native Account Abstraction initiated discussions, meticulously working through the fundamental requirements and constraints that 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 innovation. These ambitions were balanced against hard constraints such as public-mempool compatibility, statelessness, and robust L2 DoS resistance, ensuring the security and integrity of the network.
A Thursday FOCIL (Fast Optimistic Confirmation of Inactivity Leaks) breakout provided updates on implementation progress. Early prototypes were already functional, with multi-client interop and a dedicated FOCIL devnet identified as immediate next steps. Two significant design decisions were made: disabling FOCIL during periods of 2-epoch non-finality (mirroring proposer-boost circuit-breaker behavior for stability), and adopting an index-based bookmark approach to ensure compatibility with frame transactions and EIP-7702.
Further into the future, a long-running ETH P2P track sketched out plans for a QUIC-based replacement for libp2p. This new peer-to-peer networking layer aims for privacy-by-default features and slot-aware integration. Additionally, an erasure-coded broadcast prototype was presented, simulating approximately six times faster propagation than GossipSub for 2.4 MB payloads, indicating significant potential for network efficiency improvements. The CL track also expressed a strong sentiment towards eventually deprecating consolidations entirely. The proposed approach involves declaring a final fork that supports them, then mandating an exit-then-redeposit process thereafter, as a cleaner long-term solution to managing validator-set state growth.
Refining the All Core Devs (ACD) Process
On Wednesday afternoon, Nixo and Ansgar, the two ACDE (All Core Devs Execution) co-leads, facilitated a session to gather input from core contributors regarding the ACD process itself. The discussion revisited the "headliner construct" for hard forks, debated the merits and drawbacks of maintaining a "strawmap" for future development, and formalized the EIP SFI (Specification Freeze Index) criteria. There was broad consensus to retain headliners but to introduce more flexibility, accepting "theme + candidate EIP" as a viable pattern. The per-fork year assignments in the straw map beyond 2026 were deemed overly canonicalized and likely to be softened, acknowledging the dynamic nature of development. A new four-point SFI definition was put forward, with ACDT (All Core Devs Testing) signaling readiness and ACDE/ACDC (All Core Devs Consensus) retaining the final call. A new prioritization-ordering process, generated after CFI (Call For Inclusion) decisions and reflected in the meta-EIP, will supersede SFI’s previous role in driving devnet inclusion, commencing with Hegotå.
On the call-coordination front, Alex Stokes announced a three-month sabbatical, with Pari covering ACDC moderation in the interim and Barnabas stepping in for ACDT. The updated leadership structure sees Nixo and Ansgar chairing ACDE, Pari as interim ACDC moderator, and Mario, Barnabas, and Danceratopz rotating ACDT moderation.
Beyond the Planned Agenda: Unseen Progress and Collaboration
In addition to the extensive agenda, the invaluable in-person time allowed teams to make significant progress on a wide array of other crucial topics. These included developing improved test harnesses, which compressed Hive feedback loops from hours to mere minutes, substantially accelerating testing cycles. Enhancements to engine-API plumbing, such as gossip deduplication, batched calls, and light-client-driven head discovery, were also advanced. Difficult tradeoffs around client diversity were discussed, aiming to foster a resilient and decentralized network while ensuring compatibility. The full, comprehensive list of session notes is publicly available at soldogn.xyz.
The success of Soldøgn was a testament to the collaborative spirit and dedication of the Ethereum community. Special recognition was extended to EthPandaOps for their instrumental role in organizing and energizing the group daily, and to every individual who worked tirelessly under the midnight sun to meet daily objectives. This included the Ethrex crew, who marked their first interop attendance with a highly productive contribution.
Next Steps and Future Outlook
Following the Soldøgn Interop, development teams will return home to transition the prototypes and refined specifications into production-ready code. The upcoming weeks are expected to involve intense, heads-down work on hardening client implementations against the new specifications, finalizing comprehensive test coverage, and merging the draft pull requests from Soldøgn into the main codebase.
As is customary, the final decisions for critical values such as the 200 million gas limit target and the definitive repricing numbers will be publicly deliberated and finalized during the upcoming AllCoreDevs calls. These calls are anticipated to feature these topics prominently in the immediate future, providing transparency and finality to the significant progress made during the Soldøgn Interop. The event stands as a powerful demonstration of Ethereum’s ongoing commitment to robust, collaborative, and ambitious decentralized development.
