This past week, an assembly of over 100 Ethereum core contributors converged in the remote and striking locale of Longyearbyen, Svalbard, situated just above the Arctic Circle, for the Soldégn Interop event. This intensive, week-long gathering was dedicated to a singular, focused objective: advancing and solidifying the forthcoming Glamsterdam network upgrade. The choice of Svalbard, a territory renowned for its unique geopolitical status and its role as a custodian of global heritage, provided a distinct backdrop for a critical phase in Ethereum’s development.
The Soldégn Interop follows in the lineage of previous collaborative events, notably last year’s Berlinterop. However, it consciously reverted to the highly effective format established by earlier initiatives such as Amphora, Edelweiss, and Nyota. This format is characterized by a single-track, deeply focused approach, prioritizing multi-client progress towards a specific upgrade milestone. In this instance, the paramount goal was the robust hardening of the Glamsterdam network. By Friday, the dedicated efforts of the attendees yielded substantial results, successfully achieving three core objectives: the establishment of a consensus on a post-Glamsterdam gas limit floor set at 200 million, the deployment of stable proposer-builder separation (ePBS) implementations integrated with external builders, and the finalization of repricing figures for EIP-8037. Beyond these primary achievements, significant advancements were also made on features slated for the Hegotà upgrade, including Functional Consensus Interface Layer (FOCIL) and native account abstraction, alongside a broad spectrum of other crucial development threads.
The Strategic Allure of Svalbard: A Sanctuary for Innovation
The selection of Svalbard as the venue for such a pivotal development sprint was deliberate and multifaceted. This Norwegian archipelago holds a unique position on the global stage; it is one of the few places on Earth where individuals of any nationality can reside and work without the requirement of a visa, fostering an environment of international collaboration. Furthermore, Svalbard is home to two extraordinary institutions: the Global Seed Vault and the Arctic World Archive. These facilities, ingeniously tunneled into the permafrost outside Longyearbyen, serve as cold-storage repositories for humanity’s most vital information and resources. They safeguard backups of agricultural diversity, cultural artifacts, scientific data, and crucially, source code deemed essential for future civilizations. Notably, a snapshot of Ethereum’s source code is among the invaluable data preserved within these archives, underscoring the network’s long-term vision and commitment to permanence.
Adding a unique temporal dimension to the event, Svalbard experiences 24-hour daylight from late April through August. This perpetual daylight, mirroring Ethereum’s own commitment to continuous operation and uptime, allowed core developers to maximize their working hours, translating the concept of "always-on" into tangible development progress. This sustained period of uninterrupted productivity was instrumental in driving the week’s ambitious agenda.
Hardening Glamsterdam: Laying the Foundation for Scalability
The central aim of the Soldégn Interop was to comprehensively harden the implementations of the Glamsterdam upgrade and to establish a clear target for the gas limit that would govern the network post-upgrade. The challenge of safely increasing the gas limit is inherently complex, involving a delicate balance across multiple dimensions. Glamsterdam directly addresses several of these critical factors: it refines the mechanisms by which blocks are constructed and proposed, enhances the operational headroom available to client implementations under stress, and addresses the scaling behavior of state creation costs in tandem with overall throughput.
In practical terms, the week’s intensive work culminated in a stable, multi-client Glamsterdam devnet. This network incorporated the latest advancements in ePBS, along with refined specifications for block access lists and repricing mechanisms. Crucially, this operational devnet provided the essential benchmarking data required to support a credible proposal for an elevated gas limit. The majority of the development time was spent in deep, focused coding sessions, often extending into the early hours of the morning. These periods of intense individual contribution were strategically punctuated by breakout sessions designed to foster alignment on critical design decisions and to deliberate on the broader, long-term roadmap for Ethereum’s evolution.
The operational backbone for this ambitious undertaking was provided by three Ethereum Foundation (EF) teams. EthPandaOps delivered essential infrastructure, including ethIQ for performance analysis and a dedicated panda MCP server to facilitate agentic workflows. The Protocol Support team established soldogn.xyz as the definitive single source of truth for interop goals, schedules, and detailed session notes. Complementing these efforts, the EF Digital Studio team meticulously documented the entire week, capturing the collaborative spirit and technical breakthroughs on film, promising a documentary that will offer an intimate look into this crucial development phase.
Advancements in Proposer-Builder Separation (ePBS)
ePBS represents a significant architectural shift in how blocks are constructed and proposed on Ethereum. Beyond refining the existing proposer-builder relationship, ePBS fundamentally restructures network slots by introducing explicit deadlines for critical processes such as block construction, payload revelation, and attestation. This formalization of timelines significantly increases the operational window for block execution, thereby creating crucial headroom necessary for safely raising the gas limit.
The week commenced with an ambitious target for the development teams: establishing a four-Execution Layer (EL) to four-Consensus Layer (CL) Glamsterdam devnet by Monday evening. The initial attempts, as is often the case in complex multi-client integrations, revealed a number of issues that necessitated a recalibration of the timeline, pushing the stable target to Tuesday. By Tuesday, a four-by-three configuration was running stably, paving the way for the commencement of rigorous stress testing.
From Tuesday onwards, the development focus shifted to a continuous ePBS hardening cycle: subjecting the system to stress tests, identifying and exposing edge cases, implementing fixes, and repeating the process. A dedicated breakout session on Tuesday morning significantly streamlined the Builder API specifications. This session clarified the validator registration process, the flow of bids, headers, and commitments, the trust model governing builder payments, and the crucial circuit-breaker mechanisms. Mid-week debugging efforts zeroed in on specific cross-client edge cases, particularly concerning the invalidation of beacon requests triggered by execution-layer requests. A newly developed test suite in this area highlighted a critical gap across all client implementations, underscoring the importance of this collaborative testing. By Thursday morning, CL teams reported stable ePBS performance, while EL-side bid pathways were still undergoing intensive debugging. These issues were progressively resolved throughout Thursday and into Friday. Two particularly contentious questions remained for the All-Core-Developers (ACD) discussions: whether a request signature should explicitly commit to the receiving builder, and how to design a resilient system for 1 ETH-staked builders that could withstand potential peer-to-peer Sybil-based liveness attacks. By Friday, nearly all participating clients were successfully synchronized on the glamsterdam-devnet-2 network, with the external builder pipeline having undergone comprehensive end-to-end testing.
Optimizing Block Access Lists (BALs)
If ePBS addresses the consensus layer’s contribution to Glamsterdam’s scaling strategy, the execution layer’s counterpart involves two primary components: gas repricings and the implementation of Block-Level Access Lists (BALs), as detailed in EIP-7928. By providing clients with advance knowledge of a block’s read and write sets, BALs enable significant performance enhancements, including parallel execution, batched I/O operations, and parallel state-root computations. These efficiencies are critical in determining the maximum block size that clients can comfortably process.
The BAL track at Soldégn operated on separate devnets, distinct from the Glamsterdam ePBS chains. This isolation ensured that optimization benchmarks were not conflated with the stabilization efforts of the consensus layer. Each optimization was implemented behind its own feature flag, allowing the week’s measurement work to compare their performance in isolation rather than as a single, bundled implementation. The dedicated BAL benchmark dashboard and leaderboard provided real-time insights into each client’s performance under worst-case scenarios across the test suite. By focusing on improving the slowest execution paths first, the development teams aimed to elevate the gas limit floor uniformly across all implementations, rather than benefiting only the fastest ones.
Refining Gas Repricings for Sustainable Growth
Glamsterdam incorporates a series of gas repricings within the execution layer, meticulously calibrating costs to better reflect the actual resource utilization at higher throughput levels. Central to this effort is EIP-8037, which increases the gas cost associated with creating new state. This adjustment is designed to prevent an unbounded proliferation of state growth that could otherwise accompany a higher gas limit.
Leading up to the Soldégn Interop, the EIP-8037 specification featured dynamic per-state-byte pricing that was intrinsically linked to the block gas limit. This dynamic pricing model presented significant challenges for testing, leading to a combinatorially complex fuzz matrix for each gas limit band, and making benchmarking nearly intractable. Early in the week, the development teams reached a consensus to move away from dynamic pricing. Instead, they opted for a fixed cost_per_state_byte, with any future repricing adjustments to be handled at future fork boundaries rather than dynamically within a single fork.
The accounting model itself underwent a more iterative development process. An initial breakout session on Monday shifted state-gas accounting from mid-execution to the end of the call frame. A follow-up session on Tuesday addressed account creation costs, code deposit costs, and the handling of CREATE transaction reverts. By Wednesday, edge cases related to reservoir refunds and refills necessitated a significant rethinking of the model. A breakout session on Thursday saw a reversion of the accounting model to the opcode level, with the realization that the primary complexity resided within the reservoir model itself, rather than in the computation of accounting. By Friday, the specification had stabilized on bal-devnet-6, and the BAL track successfully delivered the finalized repricing numbers.
This comprehensive development arc exemplifies a critical aspect of interop events: the ability to resolve complex issues related to specifications, implementation, testing, debugging, and design within hours rather than weeks. At their most effective, interop weeks can compress what would typically take a month of asynchronous progress into each and every day.
By the conclusion of the Soldégn Interop, the three principal development threads – ePBS, BAL optimizations, and gas repricings – converged on a significant headline figure: a credible 200 million gas limit floor for the post-Glamsterdam era. This substantial increase in transactional capacity is achievable through the synergistic integration of these advancements. ePBS structures the network slot to allocate more time for execution, BAL optimizations provide clients with the necessary throughput headroom within this enhanced structure, and EIP-8037 ensures that the increased gas limit does not lead to unsustainable state growth.
Exploring Additional Glamsterdam Development Threads
Beyond the core areas of ePBS, BALs, and gas repricings, the Soldégn Interop also saw considerable progress on a range of other crucial Glamsterdam-related EIPs and architectural discussions. Consensus layer (CL) teams finalized decisions on several smaller Glamsterdam EIPs. EIP-8061, which proposes an increase in exit and consolidation churn, was successfully integrated into glamsterdam-devnet-1. Conversely, EIP-8080, concerning exits via the consolidation queue, was declined for inclusion in the current upgrade. EIP-8045, aimed at removing 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 intentionally held out of glamsterdam-devnet-1 while the team addressed challenges related to bounded gossip message sizes for attestations under progressive lists.
A significant architectural breakout session on Wednesday morning, involving both EL and CL representatives, led to the decision to defer EIP-8237 out of Glamsterdam. This decision was made to preserve flexibility for a potentially longer-term "top-up sync" architecture in a future fork. In its place, the participants agreed to draft a new EIP that would standardize the sequencing of forkchoiceUpdated, newPayload, and getPayload calls. This new EIP will also specify a handshake for snap-sync initiation and refine the consistency of valid/invalid states between the engine API surfaces.
The theme of hardening implementations was pervasive throughout the week. A dedicated session on Thursday explored the development of fork-choice compliance testing frameworks. The Diamond repository, which houses reproducible CL edge-case scenarios, was a key focus. Additionally, buildoor, PandaOps’s external builder testing tool, was demonstrated mid-session, eliciting a continuous stream of attack scenarios suggested by attendees in real-time, further stress-testing the system’s resilience.
Envisioning the Future: Beyond Glamsterdam
Several breakout sessions at Soldégn looked beyond the immediate scope of Glamsterdam, focusing on the Hegotà upgrade and subsequent network evolutions. A proposal-agnostic session on native Account Abstraction initiated these discussions, carefully examining the fundamental requirements and constraints that any future design must satisfy. The envisioned feature set includes advanced capabilities such as alternative signature schemes, aggregation, batching, enhanced recovery mechanisms, gas sponsorship, flexible nonce management, and secure keystore wallets. These functionalities are balanced against critical hard constraints, including public mempool compatibility, statelessness, and robust resistance against denial-of-service (DoS) attacks on Layer 2 solutions.
A dedicated FOCIL breakout session on Thursday concentrated on implementation updates. Early prototypes for FOCIL were already demonstrating functionality, with immediate next steps involving multi-client interoperability testing and the establishment of a dedicated FOCIL devnet. Two significant design decisions emerged from this session: the decision to disable FOCIL during periods of two-epoch non-finality, mirroring the behavior of the proposer-boost circuit breaker, and the adoption of an index-based bookmark approach to ensure compatibility with frame transactions and EIP-7702.
Looking further ahead, a long-running Ethereum Peer-to-Peer (P2P) networking track sketched out a potential QUIC-based replacement for the current libp2p implementation. This proposed system prioritizes privacy-by-default and aims for seamless, slot-aware integration. Furthermore, a prototype for erasure-coded broadcast demonstrated simulated propagation speeds approximately six times faster than GossipSub for 2.4 MB payloads. The CL track also indicated a strong sentiment towards the eventual deprecation of consolidations entirely. The proposed approach involves declaring a final fork that supports consolidations and then mandating an exit-then-redeposit mechanism, presenting a cleaner long-term solution for managing validator set state growth.
Refining the All-Core-Developers (ACD) Process
On Wednesday afternoon, Nixo and Ansgar, the two co-leads for the All-Core-Developers Executive (ACDE), facilitated a session dedicated to gathering input from core contributors regarding the ongoing refinement of the ACD process. This session revisited the concept of "headliners," which serve as focal points for hard forks, and engaged in a debate concerning the advantages and disadvantages of maintaining a "strawmap" – a living document outlining potential fork compositions. The criteria for EIP Special Fork Inclusion (SFI) were also formalized. The consensus within the room favored retaining headliners but advocated for a more flexible approach regarding the rigidity of EIP-versus-theme alignment, accepting a "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, indicating that ACDE and the All-Core-Developers Coordination (ACDC) would retain final decision-making authority, with the All-Core-Developers Technical (ACDT) signaling readiness. A novel prioritization-ordering process, to be implemented after CFI decisions and reflected in meta-EIPs, will supersede the previous role of SFI in driving devnet inclusion, commencing with the Hegotà upgrade.
In terms of call coordination, Alex Stokes announced his intention to take a three-month sabbatical, commencing the following week. Pari will assume moderation duties for ACDC during this interim period, while Barnabas will step in for ACDT. The current leadership structure for ACD calls is as follows: Nixo and Ansgar will chair ACDE, Pari will serve as interim ACDC moderator, and Mario, Barnabas, and Danceratopz will rotate moderation responsibilities for ACDT.
Addressing Remaining Technical Challenges and Future Outlook
In addition to the substantial progress made on the core Glamsterdam features, teams utilized the in-person collaboration to advance a wide array of other critical areas. This included improvements to test harnesses, significantly compressing Hive feedback loops from hours to mere minutes. Enhancements were also made to engine API plumbing, such as gossip deduplication, batched calls, and light-client-driven head discovery. The sessions also facilitated difficult but necessary trade-off discussions regarding client diversity and numerous other technical subjects. A comprehensive repository of session notes is publicly available at soldogn.xyz.
The immediate next steps following the Soldégn Interop involve development teams returning to their respective workstreams to transform the week’s prototypes into production-ready implementations. The coming weeks are expected to be characterized by intensive efforts focused on hardening client implementations against the newly defined specifications, finalizing test coverage, and merging the draft pull requests generated during the interop into the main codebase.
As is customary, final decisions regarding key values, such as the 200 million gas limit target and the precise repricing numbers, will be formally announced and shared publicly during the AllCoreDevs calls. These critical decisions are anticipated to be the primary focus of discussions in the immediate future.
The success of the Soldégn Interop is a testament to the dedication and collaborative spirit of the over 100 core contributors who traveled to the remote location at 78° North. Special commendation is due to EthPandaOps for their instrumental role in organizing and supporting the daily activities of the group, and to all who worked tirelessly under the perpetual daylight to ensure the achievement of daily goals. The participation of the Ethrex crew, marking their first interop event, was also a welcome addition. The week was undeniably marked by exceptional productivity, and the forthcoming documentary promises a valuable record of these pivotal moments in Ethereum’s ongoing evolution.
