This past week, a gathering of just over 100 Ethereum core contributors braved the extreme conditions above the Arctic Circle, convening in Longyearbyen, Svalbard, for the Soldõgn Interop. The intensive week-long workshop was entirely dedicated to advancing and hardening the upcoming Glamsterdam network upgrade.
The Soldõgn event followed last year’s Berlinterop but marked a return to the streamlined format used in earlier milestones like Amphora, Edelweiss, and Nyota. Rather than a sprawling conference, the format relies on a single-track week of focused, multi-client progress geared toward a singular upgrade objective—in this instance, putting the finishing touches on Glamsterdam.
By the time Friday arrived, the collaborative engineering group had successfully delivered on its three primary core goals. The participants reached critical alignment on a post-Glamsterdam gas limit floor of 200 million, established stable ePBS (Ethereum Proposer-Builder Separation) implementations running smoothly with external builders, and locked in final EIP-8037 repricing numbers. Alongside these milestones, the contributors made meaningful headway on features slated for the subsequent Hegotá fork, including FOCIL and native account abstraction, while touching upon a broad array of auxiliary protocol topics.
Why Svalbard?
Choosing Svalbard as the backdrop for a major protocol gathering carries both symbolic and practical weight. It stands as one of the very few locations on Earth where individuals of any nationality can live and work without requiring a visa. Beyond its unique geopolitical status, Svalbard is renowned for housing the Global Seed Vault and the Arctic World Archive. These secure, cold-storage facilities are tunneled deep into the permafrost just outside Longyearbyen, preserving vital global assets such as crop seeds, historical books, films, ancient manuscripts, and foundational open-source code—including a dedicated snapshot of Ethereum’s repository—to safeguard human knowledge for millennia.
Furthermore, from late April through August, Svalbard experiences the phenomenon of the midnight sun, meaning it enjoys 24/7 daylight and continuous operational uptime. This perpetual illumination mirrors the relentless, around-the-clock nature of the Ethereum network itself, a parallel that core developers leaned into heavily as they coded through the nights.
Harden Glamsterdam, Scale Ethereum
The core mandate of the Svalbard gathering was to harden existing Glamsterdam implementations and establish a definitive, realistic target for a post-upgrade gas limit floor. Safely expanding the network’s gas limit is a multifaceted engineering challenge. Glamsterdam directly addresses several core dimensions of this challenge, including how blocks are built and proposed, the operational headroom client software maintains under heavy network load, and how state-creation costs scale in tandem with overall execution throughput.
In practical terms, this required the participants to wrap up the week with a stable, multi-client Glamsterdam devnet operating with the latest ePBS configurations, updated repricing frameworks, and block access list specifications. Backed by rigorous benchmarking data, these components provide the quantitative foundation needed to anchor a credible and safe gas limit proposal.
The vast majority of the week was spent heads-down writing software, frequently stretching into the early hours of the morning. These intense coding sessions were punctuated by regular breakout discussions designed to reach consensus on intricate design choices and debate long-term roadmap trajectories.
Infrastructure for the gathering was heavily supported by three Ethereum Foundation teams. EthPandaOps deployed ethIQ alongside a specialized panda MCP server to assist engineers with agentic workflows; the Protocol Support team maintained soldogn.xyz as the single source of truth for all interoperability goals, schedules, and documentation; and the EF Digital Studio team documented the entire week on film, promising the community its very first dedicated interop documentary.
ePBS
Beyond cleaning up the economic and technical relationship between block proposers and builders, ePBS fundamentally restructures network slots by introducing strict deadlines for block construction, payload reveals, and attestations. By making the timing constraints of block execution explicit, the architecture generates crucial processing headroom, which in turn facilitates a safe increase in the gas limit.
Teams initially entered the week targeting the deployment of a 4 Execution Layer by 4 Consensus Layer Glamsterdam devnet by Monday evening. Initial deployment attempts immediately surfaced subtle edge cases and bugs, pushing the operational target to Tuesday. By Tuesday afternoon, a stable 4-by-3 configuration was up and running, allowing stress testing to commence.
The remainder of the week transformed into an iterative ePBS hardening cycle: stress testing the network, exposing edge cases, patching the code, and repeating the process. A Tuesday-morning Builder API breakout session streamlined the specification regarding validator registrations, the bid-header-commitments pipeline, trust models for builder payouts, and the behavior of circuit breakers. Mid-week debugging sessions zeroed in on cross-client edge cases, particularly surrounding execution-request invalidations of beacon requests. A newly deployed test suite exposed synchronization gaps across virtually every client implementation.
By Thursday morning, Consensus Layer teams were reporting stable ePBS functionality, while Execution Layer bid pathways continued to undergo active debugging before being resolved toward the end of the week. Two questions remain genuinely contentious within All Core Developers discussions: whether a request signature should explicitly commit to the receiving builder, and how to design a 1-ETH staked builder framework that remains robust against peer-to-peer, Sybil-based liveness attacks.
By Friday, nearly all client implementations were successfully running together on glamsterdam-devnet-2, successfully validating the external builders pipeline from end to end.
BAL Optimizations
If ePBS represents the consensus-layer pillar of the Glamsterdam scaling strategy, its execution-layer counterpart relies on two dominant components: gas repricings and Block-Level Access Lists (BALs), formalized under EIP-7928. By providing client software with explicit information concerning a block’s read and write sets ahead of execution, BALs facilitate parallel transaction execution, batched input-output operations, and parallel state-root computations. These capabilities collectively determine the maximum size of a block that clients can process comfortably without performance degradation.
The BAL track at Soldõgn operated on dedicated devnets, entirely separate from the Glamsterdam ePBS chains. This separation ensured that optimization benchmarks were not confounded by consensus-layer stabilization efforts. Each optimization was engineered behind its own feature flag, enabling developers to measure their performance impacts in isolation rather than as an amorphous bundle. The BAL benchmark dashboard and its accompanying leaderboard surfaced the worst-case scenarios for each client across the test suite. By zeroing in on and lifting these slowest execution paths, developers could elevate the network’s gas limit floor uniformly, rather than benefiting only the fastest individual client implementations.
Gas Repricings
Glamsterdam incorporates several execution layer gas repricings designed to recalibrate costs so they accurately reflect resource consumption under conditions of elevated throughput. Central to these changes is EIP-8037, which enacts an increase in the gas cost associated with state creation. By raising the economic barrier to writing brand-new state data to the blockchain, the protocol ensures that a higher gas limit does not result in unchecked, exponential state growth.
Prior to the Svalbard gathering, the EIP-8037 specification relied on dynamic pricing per state byte tied directly to the block gas limit. This dynamic model made testing combinatorially complex, requiring separate fuzzing matrices for every potential gas limit band while rendering benchmarking nearly intractable. Early in the week, developers agreed to abandon dynamic pricing in favor of a fixed cost per state byte, deferring future pricing adjustments to explicit network fork boundaries rather than managing them dynamically within a single fork.
The underlying accounting model underwent an iterative design process. A Monday breakout session shifted state-gas accounting from mid-execution checks to the end of call frames. A Tuesday follow-up successfully resolved account creation costs, code deposit expenses, and the handling of reverted CREATE transactions. Mid-week testing exposed edge cases related to reservoir refunds and refills, forcing a comprehensive architectural rethink.
A Thursday breakout ultimately reverted the accounting mechanics back to the individual opcode level after concluding that the primary engineering complexity lay within the reservoir model rather than the base accounting computations. By Friday, the specification had stabilized on bal-devnet-6, with the BAL track delivering finalized repricing metrics.
This rapid cycle underscored the immense value of in-person developer gatherings, demonstrating an ability to resolve complex specification, implementation, testing, debugging, and architectural challenges within hours instead of weeks.
Ultimately, these three parallel threads converged to produce the defining headline metric of the week: a credible 200 million post-Glamsterdam gas limit floor. This significant scalability leap is made possible because ePBS structures slot timing to afford execution greater breathing room, BAL optimizations grant clients the requisite throughput capacity within that window, and EIP-8037 guarantees that the expanded gas limit does not lead to runaway state bloat.
Other Glamsterdam Threads
Beyond ePBS, BALs, and gas repricings, the remainder of the Glamsterdam upgrade scope was heavily debated and refined across numerous breakout sessions.
Consensus Layer teams finalized decisions regarding smaller EIPs included in the upgrade. EIP-8061, which increases the exit and consolidation churn limit, was successfully integrated into glamsterdam-devnet-1. Conversely, EIP-8080, proposing exits via the consolidation queue, was declined for inclusion. EIP-8045, focused on the removal of duties for slashed validators, was significantly narrowed in scope to apply solely to proposer duties within the active look-ahead window. Meanwhile, EIP-8045 and EIP-7688, introducing SSZ stable containers, remain formally within the Glamsterdam scope but were temporarily held out of glamsterdam-devnet-1 while developers work to ensure bounded gossip-message sizing for attestations under progressive lists.
During a Wednesday morning execution and consensus layer sync architecture session, developers decided to defer EIP-8237 out of Glamsterdam. This move preserves architectural optionality for a more comprehensive top-up synchronization mechanism in a future network upgrade. In its place, the room agreed to draft a new EIP that standardizes the sequencing of forkchoiceUpdated, newPayload, and getPayload engine API calls, specifies a formalized snap-sync initiation handshake, and tightens valid-and-invalid state consistency across engine API surfaces.
System hardening remained a consistent theme throughout the week. A Thursday session addressed fork-choice compliance testing frameworks, highlighting the Diamond repository of reproducible consensus-layer edge cases. Additionally, EthPandaOps demonstrated buildoor, an external builder testing tool, which was subjected to a continuous stream of real-time attack scenarios suggested by attendees during the session.
Beyond Glamsterdam
Several breakout discussions looked further down the development roadmap toward the Hegotá upgrade and subsequent forks.
A deliberate, proposal-agnostic session on native account abstraction opened discussions by outlining the strict functional requirements and technical constraints any future design must satisfy. Feature-set goals—including alternative signature schemes, signature aggregation, transaction batching, account recovery, gas sponsorship, flexible nonces, and keystore-based wallets—were weighed against hard constraints such as public mempool compatibility, statelessness, and resistance to Layer 2 denial-of-service attacks.
A Thursday breakout dedicated to FOCIL (Filter-Order Consensus-Enforced Inclusion Lists) focused on recent implementation updates. Early prototypes were already functional, with multi-client interoperability testing and a dedicated FOCIL devnet established as immediate next steps. Attendees reached consensus on two key design choices: disabling FOCIL during periods of two-epoch non-finality to mirror existing proposer-boost circuit-breaker mechanics, and adopting an index-based bookmark approach to maintain compatibility with frame transactions and EIP-7702.
Looking even further ahead, a persistent peer-to-peer networking track sketched out a QUIC-based replacement for libp2p featuring default privacy and slot-aware integration. The track also reviewed an erasure-coded broadcast prototype that demonstrated roughly six times faster propagation speeds compared to GossipSub when handling 2.4-megabyte payloads. Additionally, the consensus layer track registered strong community sentiment favoring the eventual deprecation of validator consolidations entirely—envisioning a final network upgrade supporting them followed by a strict policy of requiring validators to exit and redeposit—as a cleaner long-term solution for managing validator-set state growth.
ACD Process
On Wednesday afternoon, All Core Developers Execution (ACDE) co-leads Nixo and Ansgar hosted an open session to gather feedback from core contributors regarding the broader All Core Developers (ACD) governance process. The discussion revisited the headliner construct, debated the operational utility of the strawmap, and formalized the criteria for EIP SFI (Specification Freeze Indicator) readiness.
Participants expressed a strong desire to retain upgrade headliners while loosening the rigidity between EIPs and broader themes, accepting a "theme plus candidate EIP" framework as a viable organizational pattern. The multi-year per-fork timeline assignments on the straw map extending past 2026 were widely criticized as overly canonicalized and slated for softening. A new four-point SFI definition was introduced, establishing that while All Core Developers Testing (ACDT) signals readiness, final approval authority remains with ACDE and All Core Developers Consensus (ACDC). A revised prioritization-ordering process—taking effect after Core Feature Inclusion decisions are made and reflected in the meta-EIP—will replace the former role of SFI in driving devnet inclusions, starting with the Hegotá upgrade.
Regarding call coordination logistics, Alex Stokes announced that he will begin a three-month sabbatical starting next week. Pari will step in to moderate ACDC calls during his absence, while Barnabas will cover ACDT moderation duties. Overall, upgrade coordination leadership remains structured with Nixo and Ansgar chairing ACDE, Pari serving as interim moderator for ACDC, and a rotating committee of Mario, Barnabas, and Danceratopz handling ACDT moderation.
Everything Else
Beyond these major tracks, development teams utilized the in-person environment to advance numerous auxiliary projects. These included refining test harnesses to compress Hive feedback loops from hours down to minutes, improving engine API plumbing—such as gossip deduplication, batched calls, and light-client-driven head discovery—and navigating complex trade-offs surrounding client diversity. Comprehensive notes covering every session from the week remain publicly accessible via the event portal.
Next Steps
With the Svalbard gathering concluded, core contributors return to their home bases to transition their experimental prototypes into production-ready code. The coming weeks will see heads-down engineering efforts focused on hardening client implementations against updated specifications, finalizing comprehensive test coverage, and turning the draft pull requests generated in Soldõgn into merged, operational code.
As is standard protocol, definitive decisions regarding specific network parameters—such as the finalization of the 200 million gas limit target and exact repricing figures—will be deliberated and shared publicly during upcoming AllCoreDevs calls.
The core developer community extended its gratitude to everyone who traveled to 78° degrees North to make the week an operational success, with a special acknowledgment to EthPandaOps for maintaining organizational momentum and to the Ethrex team for participating in their first interop.
Comments (0)