In a remarkable convergence of technical expertise and commitment to blockchain innovation, over one hundred core contributors to the Ethereum network recently convened in Longyearbyen, Svalbard, above the Arctic Circle, for the Soldø¥gn Interop. This intensive, week-long event was dedicated to the critical advancement of the Glamsterdam network upgrade, focusing on hardening its infrastructure and paving the way for significant scalability improvements. The gathering, echoing the focused, single-track format of previous key interop events like Amphora, Edelweiss, and Nyota, underscored the Ethereum community’s dedication to collaborative development and problem-solving.
The Soldø¥gn Interop built upon the momentum generated by last year’s Berlinterop, but returned to a more concentrated format. This approach prioritizes deep, multi-client progress toward specific, high-impact upgrades. For Soldø¥gn, the primary objective was to solidify the foundation for Glamsterdam, a crucial upgrade poised to enhance Ethereum’s throughput and efficiency. By Friday, the dedicated core developers had successfully achieved three pivotal goals: establishing a clear consensus on a post-Glamsterdam gas limit floor of 200 million, ensuring the stable operation of proposer-builder separation (ePBS) implementations with external builders, and finalizing the repricing numbers for EIP-8037. Beyond these core achievements, substantial headway was also made on features slated for the subsequent Hegotá upgrade, including advancements in Fully Online Consensus (FOCIL) and native account abstraction, alongside discussions on a broad spectrum of other critical network enhancements.
The Strategic Choice of Svalbard: A Symbol of Resilience and Global Collaboration
The selection of Longyearbyen, Svalbard, as the venue for the Soldø¥gn Interop was a deliberate and symbolic choice. Svalbard stands as one of the world’s unique locations where individuals from any nation can reside and work without the necessity of a visa, embodying a spirit of open access and global cooperation that mirrors Ethereum’s decentralized ethos. Furthermore, the region is home to the Svalbard Global Seed Vault and the Arctic World Archive, two vital cold-storage facilities embedded within the permafrost. These archives safeguard crucial backups of humanity’s agricultural heritage, cultural records, and technological blueprints, with a snapshot of Ethereum’s source code also preserved. The perpetual daylight during the Arctic summer, from late April through August, provided a fitting backdrop of "24/7 uptime," a characteristic directly analogous to the continuous operation of the Ethereum network itself. This uninterrupted daylight allowed developers to maximize their collaborative efforts, working intensely under the midnight sun to drive progress.
Hardening Glamsterdam: Laying the Groundwork for Scalability
The overarching objective of the Soldø¥gn week was to comprehensively harden the Glamsterdam upgrade and establish a definitive target for the post-upgrade gas limit floor. Safely increasing the gas limit, a critical metric for network transaction capacity, is a multifaceted challenge. Glamsterdam addresses several key components of this challenge, including the intricate processes of block construction and proposal, the headroom available to client implementations under load, and the scaling of state creation costs in conjunction with increased throughput.
In practical terms, the successful conclusion of the interop week resulted in a stable, multi-client Glamsterdam development network. This network was configured to run the latest ePBS implementations, incorporate updated block access list specifications, and generate crucial benchmarking data. This data serves as a foundational element for proposing a credible and safe increase to the gas limit. The majority of the developers’ time was spent in deep, focused coding sessions, often extending into the early hours of the morning. These intense coding periods were interspersed with productive breakout sessions designed to foster alignment on critical design decisions and to deliberate on the long-term roadmap for the Ethereum protocol.
The operational success of the interop week was significantly supported by three dedicated Ethereum Foundation (EF) teams. EthPandaOps provided essential infrastructure, deploying ethIQ for performance monitoring and a panda MCP server to facilitate agentic workflows for the development teams. The Protocol Support team established soldogn.xyz as the definitive, single source of truth for interop goals, schedules, and comprehensive meeting notes. Furthermore, the EF Digital Studio team meticulously documented the entire week’s proceedings, promising the release of a forthcoming documentary that will offer an in-depth look at this pivotal event.
ePBS: Revolutionizing Block Construction and Execution
The implementation of enhanced Proposer-Builder Separation (ePBS) represents a significant architectural shift within the consensus layer. Beyond streamlining the relationship between block proposers and builders, ePBS fundamentally restructures the slot lifecycle by introducing explicit deadlines for block construction, payload unveiling, and attestation submission. This explicit time allocation for execution significantly expands the available window for processing transactions, thereby creating the necessary headroom to safely increase the network’s gas limit.
The week commenced with an ambitious target: the establishment of a stable 4 execution layer (EL) by 4 consensus layer (CL) Glamsterdam development network by Monday evening. Initial attempts revealed a number of challenges, necessitating a revised target of Tuesday for a 4×3 configuration to run reliably, allowing for the commencement of stress testing.
Following this, the remainder of the week was dedicated to a rigorous ePBS hardening cycle: persistent stress testing, the identification and exposure of edge cases, iterative bug fixing, and repeated testing. A crucial breakout session on Tuesday morning significantly simplified the specification surrounding validator registration, the bid submission and payload commitment flow, the trust model for builder payments, and the behavior of circuit-breaker mechanisms. Mid-week debugging efforts concentrated on addressing cross-client edge cases, particularly concerning the invalidation of beacon chain requests by execution layer responses. A newly developed test suite effectively highlighted a critical gap across all client implementations in this area. By Thursday morning, CL teams reported stable ePBS operation, while EL-side bid pathways were still undergoing intensive debugging, with resolutions achieved by Thursday and into Friday. Two specific technical points remained subjects of robust debate within the All-Core-Devs (ACD) community: the question of whether a request signature should explicitly commit to the receiving builder, and the challenge of designing a system where a 1 ETH-staked builder mechanism remains resilient against peer-to-peer Sybil-based liveness attacks.
By the close of the Soldø¥gn Interop, nearly all participating clients were successfully operating in tandem on the glamsterdam-devnet-2 network, with the external builder pipeline undergoing end-to-end testing. This achievement marks a significant milestone in preparing the network for the Glamsterdam upgrade.
BAL Optimizations: Unlocking Execution Layer Throughput
If ePBS represents the consensus layer’s contribution to the Glamsterdam scaling initiative, then the execution layer’s counterpart is comprised of two primary advancements: gas repricings and Block-Level Access Lists (BALs), as detailed in EIP-7928. By providing clients with comprehensive information about a block’s read and write sets upfront, BALs enable parallel execution, batched I/O operations, and parallel state-root computation. These efficiencies are paramount in determining the maximum block size that clients can comfortably and reliably process.
The BAL optimization track at Soldø¥gn operated on separate development networks, distinct from the Glamsterdam ePBS chains, ensuring that optimization benchmarks were not influenced by the complexities of consensus layer stabilization. Each optimization was implemented behind its own feature flag, allowing the week’s measurement efforts to compare them in isolation rather than as a monolithic bundle. The dedicated BAL benchmark dashboard and leaderboard effectively highlighted each client’s worst-case performance scenarios across the comprehensive test suite. By prioritizing the optimization of the slowest execution paths, the development teams were able to elevate the gas limit floor across the board, benefiting not only the most performant implementations but all clients within the ecosystem.
Gas Repricings: Calibrating Costs for Increased Capacity
Glamsterdam incorporates a series of execution layer gas repricings, meticulously calibrated to align costs more accurately with resource utilization at higher throughput levels. EIP-8037, which addresses the gas cost of state creation, is central to this initiative. This EIP significantly increases the cost of writing new state, thereby preventing a higher gas limit from leading to unbounded state growth within the network.
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, requiring a combinatorial approach with one fuzz matrix for each gas limit band, and rendered benchmarking nearly intractable. Early in the week, the development teams reached a consensus to abandon dynamic pricing in favor of a fixed cost_per_state_byte. Future repricing adjustments will be handled at the fork boundaries, rather than dynamically within a fork.
The accounting model itself underwent a more iterative development process. A breakout session on Monday shifted state-gas accounting from the mid-execution phase to the end of the call frame. A follow-up session on Tuesday addressed account creation costs, code deposit costs, and CREATE transaction reverts. On Wednesday, edge cases related to reservoir refunding and refilling necessitated a reevaluation of the model. A breakout session on Thursday reverted the accounting mechanism to the opcode level, as it was concluded that the primary complexity resided within 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 entire developmental arc underscores one of the most significant advantages of interop events: the capacity to resolve complex specification, implementation, testing, debugging, and design issues in a matter of hours, rather than weeks. At their most effective, interop weeks can compress weeks of asynchronous progress into each and every day.
By Friday, the three distinct development threads—ePBS, BALs, and gas repricings—had converged to establish a credible target for the week: a 200 million gas limit floor post-Glamsterdam. This substantial increase in network capacity is made possible by the synergistic combination of ePBS, which restructures slots to allocate more time for execution; BAL optimizations, which provide clients with the necessary throughput headroom within this new structure; and EIP-8037, which ensures that the higher gas limit does not result in uncontrolled state expansion.
Broader Glamsterdam Developments and Future Outlook
Beyond the core advancements in ePBS, BALs, and gas repricings, the Soldø¥gn Interop saw significant progress on a range of other Glamsterdam-related EIPs and architectural discussions.
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. EIP-8080, designed to facilitate exits via the consolidation queue, was ultimately declined for inclusion in Glamsterdam. 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, focused on SSZ stable containers, remains within the Glamsterdam scope but was held out of glamsterdam-devnet-1 as developers continue to address the challenges associated with bounded gossip message sizes for attestations under progressive lists.
An architectural breakout session on Wednesday morning, involving both EL and CL representatives, led to the decision to defer EIP-8237 out of the Glamsterdam upgrade. This strategic postponement preserves optionality for a more robust, long-term "top-up sync" architecture in a future fork. In its place, the participants agreed to draft a new EIP that standardizes the sequencing of forkchoiceUpdated, newPayload, and getPayload calls. This new EIP will also specify an initiation handshake for snap-sync operations and enforce tighter consistency between the engine API surfaces for valid and invalid states.
A constant theme throughout the week was the hardening of the network. A dedicated session on Thursday explored advanced fork-choice compliance testing frameworks, including the Diamond repository, which houses reproducible CL edge-case scenarios. The buildoor tool, developed by PandaOps for external builder testing, was demonstrated mid-session, prompting a continuous stream of attack scenarios suggested by attendees in real-time.
Beyond Glamsterdam: Charting the Course for Hegotá and Future Forks
Several breakout sessions at Soldø¥gn looked ahead to the Hegotá upgrade and subsequent network evolutions. A deliberately proposal-agnostic session on native Account Abstraction initiated discussions on the fundamental 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 breakout session on Thursday focused on Fully Online Consensus (FOCIL), with implementation updates indicating that early prototypes are already functional. The immediate next steps involve multi-client interop testing and the establishment of a dedicated FOCIL development network. Two significant design decisions were reached: FOCIL will be disabled during periods of two-epoch non-finality, mirroring the behavior of the proposer-boost circuit breaker, and an index-based bookmark approach will be adopted to ensure compatibility with frame transactions and EIP-7702.
Looking further ahead, a sustained Ethereum P2P (peer-to-peer) track outlined a vision for a QUIC-based replacement for the current libp2p networking stack. This proposed system would feature privacy-by-default functionalities and slot-aware integration. Additionally, an erasure-coded broadcast prototype demonstrated approximately six times faster propagation rates than GossipSub on 2.4 MB payloads. The CL track also revealed a strong sentiment towards the eventual deprecation of consolidations entirely. The proposed approach involves declaring a final fork that supports consolidations and then enforcing a mandatory exit-and-redeposit procedure, offering a cleaner long-term solution to validator-set state growth.
Refining the All-Core-Devs (ACD) Process
On Wednesday afternoon, Nixo and Ansgar, the co-leads for the All-Core-Devs (ACD) working groups, facilitated a session to gather input from core contributors regarding the ACD process itself. The discussion revisited the concept of "headliners" as a means of community consensus for hard forks, debated the merits and drawbacks of maintaining a strawmap, and formalized the criteria for EIP Specification Freeze Indicator (SFI). The consensus among participants was to retain headliners but to loosen the rigid distinction between EIPs and broader themes, accepting a "theme + candidate EIP" as a viable development pattern. The strawmap’s per-fork year assignments beyond 2026 were identified as overly canonicalized and likely to be softened. A new four-point SFI definition was proposed, with the All-Core-Devs Technical (ACDT) committee signaling its readiness to adopt it, while the All-Core-Devs Execution (ACDE) and All-Core-Devs Consensus (ACDC) committees would retain the final decision-making authority. A new prioritization and ordering process, to be implemented after Consensus-Fork-Initial (CFI) decisions and reflected in a meta-EIP, will supersede SFI’s previous role in driving devnet inclusion, commencing with the Hegotá upgrade.
In terms of call coordination, Alex Stokes announced a three-month sabbatical commencing the following week. Pari will assume interim ACDC moderation duties during this period, and Barnabas will fill in for ACDT. The interim leadership structure for core developer calls is as follows: Nixo and Ansgar will chair ACDE, Pari will serve as interim on ACDC, and Mario, Barnabas, and Danceratopz will rotate ACDT moderation responsibilities.
Continued Progress and Next Steps
Beyond the major technical advancements and process refinements, development teams leveraged the in-person collaboration to make progress on a wide array of other critical areas. This included enhancing test harnesses, significantly compressing Hive feedback loops from hours to mere minutes. Improvements were also made to engine API plumbing, such as gossip deduplication, batched calls, and light-client-driven head discovery. The teams also grappled with difficult trade-offs concerning client diversity and addressed numerous other emergent technical challenges. A comprehensive record of all session notes is publicly available at soldogn.xyz.
The immediate next steps involve developers returning to their respective teams to translate the prototypes developed during the Soldø¥gn week into production-ready code. The coming weeks will be characterized by intensive efforts to harden client implementations against the new specifications, finalize test coverage, and merge the draft Pull Requests initiated at Soldø¥gn into the codebase.
As is customary, final decisions regarding key parameters, such as the 200 million gas limit target and the precise repricing numbers, will be made and publicly announced during AllCoreDevs calls. These crucial decisions are expected to be the primary focus of discussions in the upcoming week.
The success of the Soldø¥gn Interop is a testament to the dedication and collaborative spirit of the Ethereum core development community. The journey to enhanced scalability is ongoing, and the progress made in Svalbard marks a significant leap forward. The impending release of a documentary capturing the week’s events will offer valuable insights into the intricate work and profound dedication that underpins the continuous evolution of the Ethereum network.
