This past week, a dedicated cohort of over 100 Ethereum core contributors convened in the remote and unique setting of Longyearbyen, Svalbard, situated above the Arctic Circle, for the Soldægn Interop event. This intensive, week-long gathering was singularly focused on advancing the Glamsterdam network upgrade, a critical step in Ethereum’s ongoing evolution. The event marked a return to a focused, single-track format, echoing successful previous interop events like Amphora, Edelweiss, and Nyota, with the primary objective of hardening the Glamsterdam network. By the conclusion of the week, significant progress was announced, including the establishment of a post-Glamsterdam gas limit floor of 200 million, the successful implementation and testing of stable proposer-builder separation (ePBS) with external builders, and the finalization of repricing numbers for EIP-8037.
The choice of Svalbard as a venue was deliberate and symbolic. As one of the few locations globally where individuals can live and work without visa restrictions, it fosters an environment of international collaboration. Furthermore, Svalbard is home to the Global Seed Vault and the Arctic World Archive, facilities designed for long-term data preservation, housing backups of humanity’s most valuable assets, including a snapshot of Ethereum’s source code. The continuous daylight during the Arctic summer, mirroring Ethereum’s 24/7 uptime, provided an uninterrupted operational window for the core developers.
Soldægn Interop followed last year’s Berlinterop, but its structure was more aligned with the intensive, collaborative approach seen in earlier events such as Amphora, Edelweiss, and Nyota. The core of the week was dedicated to a singular, multi-client effort aimed at achieving specific technical objectives for the Glamsterdam upgrade. This concentrated approach is crucial for synchronizing development efforts across different client implementations and ensuring a cohesive network upgrade.
Harden Glamsterdam, Scale Ethereum: The Core Objectives
The central mission of the Soldægn Interop was to solidify the Glamsterdam network upgrade and establish a target for a post-upgrade gas limit floor. The challenge of safely increasing Ethereum’s gas limit is a multifaceted technical problem, and Glamsterdam addresses several key aspects: optimizing block production and proposal mechanisms, enhancing the headroom available to client implementations under load, and refining the cost scaling of state creation in conjunction with increased throughput.
The week’s work culminated in a stable, multi-client Glamsterdam development network (devnet) operational with the latest ePBS specifications, refined block access list (BAL) standards, and comprehensive benchmarking data. This data serves as the foundation for proposing a credible and robust gas limit increase.
Much of the developers’ time was spent in deep, focused coding sessions, often extending into the early hours of the morning. These periods of intense development were interspersed with breakout sessions designed to align on critical design decisions and discuss the long-term roadmap for Ethereum’s scalability.
Three key Ethereum Foundation (EF) teams provided essential infrastructure and support throughout the event. EthPandaOps delivered ethIQ, a performance monitoring tool, and a panda Message Coordination Protocol (MCP) server to streamline agentic workflows. The Protocol Support team established soldogn.xyz as the central hub for interop goals, schedules, and meeting notes, serving as the single source of truth. The EF Digital Studio team documented the entire week, promising the release of the first interop documentary.
ePBS: Restructuring Block Production for Scalability
A significant focus of the Soldægn Interop was on Proposer-Builder Separation (ePBS), a consensus-layer enhancement designed to optimize how blocks are constructed and proposed. ePBS fundamentally restructures the slot timeline by introducing explicit deadlines for block construction, payload revelation, and attestation. This structured approach provides greater certainty regarding the time allocated for execution, thereby increasing the potential for a higher gas limit.
The week commenced with an ambitious goal: a stable 4 execution layer (EL) and 4 consensus layer (CL) Glamsterdam devnet by Monday evening. Initial testing revealed numerous issues, necessitating a shift in the target to Tuesday, when a 4×3 configuration achieved sufficient stability for rigorous stress testing to commence.
The remainder of the week was dedicated to an iterative ePBS hardening cycle: stress testing, identifying edge cases, implementing fixes, and repeating the process. A breakout session on Tuesday morning significantly simplified the Builder API specification, clarifying validator registration, the bid/header/commitments flow, the trust model for builder payments, and circuit-breaker mechanisms. Mid-week debugging efforts zeroed in on cross-client edge cases, particularly concerning the invalidation of beacon requests by execution requests. A newly developed test suite exposed a gap in every client implementation. By Thursday morning, CL teams reported stable ePBS operation, while EL-side bid pathways were still undergoing debugging, with resolutions achieved by Friday. Two contentious issues remained for the All-Core-Devs (ACD) discussions: whether a request signature should commit to the receiving builder and how to maintain the resilience of a 1 ETH-staked-builder design against peer-to-peer Sybil-based liveness attacks.
By Friday, nearly all participating clients were operating in unison on glamsterdam-devnet-2, with the external builder pipeline tested end-to-end, marking a substantial step forward for ePBS implementation.
BAL Optimizations: Enhancing Execution Layer Throughput
Complementing the consensus-layer advancements of ePBS, the execution layer’s scalability was addressed through two primary mechanisms: gas repricings and Block-Level Access Lists (BALs), as outlined in EIP-7928. By providing clients with upfront information about a block’s read and write sets, BALs enable parallel execution, batched I/O operations, and parallel state-root computation. These capabilities are critical determinants of the block size that clients can comfortably process.
The BAL track at Soldægn operated on separate devnets, distinct from the Glamsterdam ePBS chains, ensuring that optimization benchmarks were not conflated with consensus-layer stabilization efforts. Each optimization was implemented behind its own feature flag, allowing for isolated comparison of their performance. The BAL benchmark dashboard and leaderboard highlighted the worst-case scenarios encountered by each client across the test suite. By focusing on improving the slowest execution paths, the development teams aimed to lift the gas limit floor across the entire network, rather than solely benefiting the most optimized implementations.
Gas Repricings: Calibrating Costs for Higher Throughput
Glamsterdam incorporates several execution-layer gas repricings, designed to align costs more accurately with resource utilization at higher throughput levels. EIP-8037, which increases the state-creation gas cost, is central to this effort. By raising the price of writing new state, it prevents a higher gas limit from leading to unbounded state growth.
Leading up to Soldægn, the EIP-8037 specification featured dynamic per-state-byte pricing tied to the block gas limit. This complexity made combinatorial testing challenging, requiring a separate fuzz matrix for each gas limit band, and rendered benchmarking nearly intractable. Early in the week, the teams agreed to abandon dynamic pricing in favor of a fixed cost_per_state_byte, with future repricing adjustments to be managed at fork boundaries rather than within a fork.
The accounting model itself underwent an iterative refinement process. An initial breakout session on Monday shifted state-gas accounting from mid-execution to the end of the call frame. A subsequent follow-up on Tuesday addressed account creation costs, code deposit costs, and CREATE-transaction reverts. Mid-week, challenges emerged with reservoir refund and refill edge cases, necessitating a reevaluation of the approach. By Thursday, the accounting model reverted to the opcode level, recognizing that the primary complexity lay within the reservoir model rather than the accounting computation itself. By Friday, the specification had stabilized on bal-devnet-6, and the BAL track delivered the final repricing numbers.
This iterative development process highlights a crucial benefit of interop events: the ability to resolve complex specification, implementation, testing, debugging, and design issues within hours rather than weeks. These intensive weeks can compress weeks of asynchronous progress into a single day.
By the end of the week, the three convergent threads—ePBS, BAL optimizations, and gas repricings—led to a critical consensus: a credible 200 million post-Glamsterdam gas limit floor. This substantial increase is achievable due to ePBS structuring the slot to allocate more time for execution, BAL optimizations providing clients with the necessary throughput headroom within that structure, and EIP-8037 ensuring that the increased gas limit does not result in uncontrolled state expansion.
Other Glamsterdam Threads: Evolving the Network
Beyond the core advancements in ePBS, BALs, and gas repricings, the Soldægn Interop addressed numerous other aspects of the Glamsterdam upgrade through dedicated breakout sessions.
Consensus layer teams finalized decisions on several smaller Glamsterdam EIPs. EIP-8061, which increases exit and consolidation churn, was successfully integrated into glamsterdam-devnet-1. EIP-8080, proposing exits via the consolidation queue, was declined for inclusion in this upgrade. EIP-8045, concerning the removal of slashed validator duties, was scoped down to apply only to proposer duties within the look-ahead window. EIP-7688, focusing on SSZ stable containers, remains within the Glamsterdam scope but was held out of glamsterdam-devnet-1 while teams worked through the challenges of bounded gossip message sizes for attestations under progressive lists.
A critical synchronization breakout session between the EL and CL teams on Wednesday morning resulted in the deferral of EIP-8237 from Glamsterdam. This decision preserves optionality for a more comprehensive "top-up sync" architecture in a future fork. In its place, the teams agreed to draft an EIP that standardizes the sequencing of forkchoiceUpdated, newPayload, and getPayload calls, specifies a snap-sync initiation handshake, and tightens consistency between the engine API surfaces for valid and invalid states.
Hardening and testing were pervasive themes throughout the week. A session on Thursday explored fork-choice compliance testing frameworks, the Diamond repository of reproducible CL edge-case scenarios, and buildoor, EthPandaOps’s external builder testing tool. Demonstrations of buildoor showcased its ability to simulate a continuous stream of attack scenarios proposed on the spot by attendees.
Beyond Glamsterdam: Laying the Groundwork for Future Upgrades
Several breakout sessions at Soldægn looked ahead to the Hegotæ and subsequent forks, focusing on foundational elements for future network evolution.
A proposal-agnostic session on native Account Abstraction initiated discussions on the requirements and constraints that any future design must satisfy. Key feature-set goals, including alternative signature schemes, aggregation, batching, recovery mechanisms, gas sponsorship, flexible nonces, and keystore wallets, were considered alongside critical hard constraints such as public mempool compatibility, statelessness, and Layer 2 Denial-of-Service (DoS) resistance.
A dedicated FOCIL (Forward-Compatible Interoperability Layer) breakout on Thursday focused on implementation updates. Early prototypes have demonstrated functionality, with multi-client interoperability and a dedicated FOCIL devnet identified as immediate next steps. Two notable design decisions were made: disabling FOCIL during periods of two-epoch non-finality, mirroring the behavior of the proposer-boost circuit breaker, and adopting an index-based bookmark approach for compatibility with frame transactions and EIP-7702.
Further down the roadmap, a long-running ETH Peer-to-Peer (P2P) track outlined plans for a QUIC-based replacement for libp2p, incorporating privacy-by-default features and slot-aware integration. A prototype for erasure-coded broadcast demonstrated approximately six times faster propagation than GossipSub on 2.4 MB payloads. The CL track also revealed a strong sentiment toward the eventual deprecation of consolidations. This approach would involve declaring a final fork that supports them, followed by a mandatory exit-then-redeposit process, seen as the cleaner long-term solution for managing validator-set state growth.
ACD Process: Refining Governance and Coordination
On Wednesday afternoon, the All-Core-Devs (ACD) co-leads, Nixo and Ansgar, facilitated a session to gather input from core contributors regarding the ACD process. This discussion revisited the "headliner" construct, debated the merits of a strawmap, and formalized EIP Specification and Feature Inclusion (SFI) criteria. The consensus was to retain headliners but to loosen the rigidity between EIPs and themes, accepting a "theme plus candidate EIP" model as a viable approach. The per-fork year assignments on the strawmap beyond 2026 were identified as overly canonicalized and likely to be softened. A new four-point SFI definition was proposed, with ACD Technical (ACDT) signaling readiness and ACD Execution (ACDE) and ACD Coordination (ACDC) retaining final decision-making authority. A new prioritization and ordering process, to be implemented after CFI (Consensus-Fork-Improvement) decisions and reflected in a meta-EIP, will replace the old role of SFI in driving devnet inclusion, starting with Hegotæ.
Regarding call coordination, Alex Stokes announced a three-month sabbatical commencing the following week. Pari will assume ACDC moderation responsibilities during this interim period, and Barnabas will cover ACDT. The interim leadership structure will see Nixo and Ansgar chair ACDE, Pari as interim ACDC moderator, and Mario, Barnabas, and Danceratopz rotating ACDT moderation.
Everything Else: Broadening the Scope of Progress
In addition to the major themes, participants leveraged the in-person gathering to advance progress on a wide array of topics. These included improving test harnesses, significantly compressing Hive feedback loops from hours to minutes; enhancing engine API plumbing, such as gossip deduplication, batched calls, and light-client-driven head discovery; and addressing complex tradeoffs related to client diversity. The comprehensive list of session notes is publicly available on soldogn.xyz.
Next Steps: From Interop to Production
Following the Soldægn Interop, teams will return to their respective development efforts to transition the week’s prototypes into production-ready code. The coming weeks will be characterized by intensive work on hardening client implementations against the new specifications, finalizing test coverage, and merging the draft pull requests generated at Soldægn.
As is customary, final decisions on key parameters, such as the 200 million gas limit target and the definitive repricing numbers, will be made and communicated publicly during AllCoreDevs calls. These decisions are anticipated to be the primary focus of upcoming discussions.
The success of the Soldægn Interop is a testament to the dedication and collaborative spirit of the Ethereum core contributor community. The unique Arctic setting provided an unparalleled environment for focused development, yielding significant progress towards a more scalable and robust Ethereum network. The forthcoming documentary is expected to offer a compelling visual narrative of this intense and productive week.
