Just over 100 Ethereum core contributors braved the extreme northern latitudes this past week, gathering far above the Arctic Circle in Longyearbyen, Svalbard, for the Soldõgn Interop. The intensive week-long summit was entirely dedicated to advancing, testing, and hardening the upcoming Glamsterdam network upgrade.
The Soldõgn gathering followed in the footsteps of last year’s Berlinterop, yet it deliberately returned to the focused, single-track format utilized during previous milestone sessions like Amphora, Edelweiss, and Nyota. Rather than spreading efforts across divergent ideas, the attendees maintained a laser-like focus on multi-client progress geared explicitly toward bringing Glamsterdam closer to production readiness. By the time Friday arrived, the collaborative sprint had successfully delivered on its three primary objectives: achieving firm alignment on a post-Glamsterdam gas limit floor of 200 million, running stable enshriined Proposer-Builder Separation (ePBS) implementations alongside external builders, and locking in final EIP-8037 repricing figures. Furthermore, the group carved out substantial momentum for subsequent roadmap features such as FOCIL and native account abstraction, alongside a broad spectrum of secondary technical topics.
Why Svalbard?
Choosing Svalbard as the backdrop for a critical protocol upgrade was far from arbitrary. Located in the high Arctic, Svalbard stands as one of the very few regions on Earth where individuals of any nationality can live and work freely without requiring a visa. Beyond its unique geopolitical status, the remote archipelago plays a vital role in safeguarding human heritage and knowledge. It houses both the Global Seed Vault and the Arctic World Archive, two secure cold-storage vaults tunneled deep into the permafrost outside Longyearbyen. These facilities preserve critical agricultural crops, historical books, films, manuscripts, and core digital source code for future generations, a collection that notably includes a digital snapshot of Ethereum’s own source code.
Adding a poetic touch to the technical gathering, Svalbard experiences continuous daylight from late April through August, meaning the sun never sets during this window. This natural 24/7 uptime mirrors the relentless, uninterrupted operation of the Ethereum network itself—a thematic parallel that core developers leaned into as they coded deep into the polar night.
Harden Glamsterdam, Scale Ethereum
The overarching mission of the Svalbard summit was two-fold: harden the client implementations of Glamsterdam and establish a concrete, data-backed target for a post-upgrade gas limit floor. Safely raising the gas limit is a multifaceted engineering challenge. It requires solving several complex variables simultaneously, including how blocks are constructed and proposed, how much operational headroom client software maintains under heavy network load, and how state-creation costs scale in proportion to overall throughput.
In practical terms, this meant the week needed to culminate in a stable, multi-client Glamsterdam devnet running the latest iterations of ePBS, along with refined pricing and block access list specifications accompanied by robust benchmarking data. The majority of the week was spent heads-down writing code, frequently stretching into the early hours of the morning. These marathon coding sessions were regularly punctuated by focused breakout discussions designed to align on architectural design decisions and debate long-term roadmap trajectories.
Crucial infrastructure was provided throughout the week by three teams from the Ethereum Foundation. EthPandaOps rolled out ethIQ alongside a dedicated panda Model Context Protocol (MCP) server to assist engineering teams with agentic workflows. Protocol Support established soldogn.xyz as the single source of truth for all interop goals, daily schedules, and technical notes. Meanwhile, the Ethereum Foundation Digital Studio team documented the entire week on film, setting the stage for what is expected to be the community’s very first interop documentary.
ePBS
Enshrined Proposer-Builder Separation (ePBS) fundamentally restructures Ethereum slots by introducing strict, formalized deadlines for block construction, payload reveals, and attestations. By making the timing boundaries for execution explicit, the protocol gains the necessary operational headroom required to safely elevate the network gas limit.
Teams initially set out to launch a 4 Execution Layer by 4 Consensus Layer Glamsterdam devnet by Monday evening. Early deployment attempts quickly surfaced subtle networking and state bugs, pushing the target to Tuesday, at which point a stable 4-by-3 configuration was successfully brought online, opening the door for rigorous stress testing. The remainder of the week evolved into an intensive ePBS hardening cycle characterized by continuous stress testing, edge-case discovery, immediate patching, and repeat evaluations.
A Tuesday morning Builder API breakout session significantly streamlined the specification around validator registration, the complex bid-header-commitments flow, the underlying trust model for builder payments, and circuit-breaker behavior. Mid-week debugging sessions zeroed in on intricate cross-client edge cases, particularly regarding execution-request invalidation of beacon requests, where a newly introduced test suite exposed previously overlooked gaps across every single client implementation.
By Thursday morning, Consensus Layer teams reported stable ePBS functionality, while Execution Layer-side bid pathways underwent concurrent debugging before stabilizing toward the end of the week. Two deeply nuanced questions remain subjects of ongoing debate among AllCoreDevs: whether a request signature ought to commit strictly to the receiving builder, and how to ensure that a validator design requiring only 1 ETH staked by the builder remains resilient against peer-to-peer, Sybil-based liveness attacks. By Friday, nearly all client implementations were successfully running together on the glamsterdam-devnet-2 network, with the external builders pipeline fully validated end-to-end.
BAL Optimizations
While ePBS represents the consensus-layer pillar of the Glamsterdam scaling narrative, the execution-layer counterpart relies heavily on gas repricings and Block-Level Access Lists (BALs), formalized under EIP-7928. By supplying clients with precise information regarding a block’s read and write sets ahead of time, BALs unlock parallel execution, batched input-output operations, and concurrent state-root calculations. Together, these optimizations dictate the sheer volume of data and computation a client can comfortably process within a single block.
The Soldõgn BAL track operated on its own dedicated devnets, entirely separated from the Glamsterdam ePBS chains to prevent performance metrics and optimization benchmarks from becoming entangled with consensus-layer stabilization tasks. Each optimization was isolated behind its own feature flag, allowing measurements to evaluate specific changes independently rather than as an unwieldy bundle. The BAL benchmark dashboard and public leaderboard successfully highlighted the worst-case scenarios for each client across the broader test suite. By zeroing in on lifting the slowest computational paths, the engineering teams systematically raised the gas limit floor across the board, rather than merely boosting the fastest individual client implementation.
Gas Repricings
Glamsterdam incorporates a series of execution-layer gas repricings aimed at recalibrating costs to accurately reflect resource consumption under higher throughput conditions. Central to this effort is EIP-8037, which increases the gas cost associated with writing brand-new state data, ensuring that an elevated gas limit does not inadvertently unleash uncontrolled state bloat.
Prior to the summit, the EIP-8037 specification relied on dynamic pricing per state byte tied directly to the prevailing block gas limit. This dynamic approach rendered testing combinatorially complex, requiring massive fuzz matrices for every individual gas limit band, while making systematic benchmarking nearly intractable. Early in the week, developers reached a consensus to eliminate dynamic pricing in favor of a fixed cost per state byte, pushing any future repricing adjustments to hard fork boundaries rather than handling them dynamically within a single fork.
The underlying accounting model experienced a more iterative refinement process. A Monday breakout session shifted state-gas accounting from mid-execution to the end of the call frame. A Tuesday follow-up successfully resolved account creation costs, code deposit expenses, and the handling of CREATE-transaction reverts. However, Wednesday testing exposed reservoir refund and refill edge cases that demanded a complete structural rethink. Ultimately, a Thursday breakout reverted the accounting logic back to the individual opcode level after concluding that the true architectural 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 entire trajectory exemplifies the immense value of in-person interop events: the unique capability to resolve convoluted specification, implementation, testing, debugging, and design dilemmas within hours instead of weeks. At their peak, these gatherings compress a month of asynchronous progress into a single day. By Friday, all three technical threads converged to establish the summit’s headline figure: a credible 200 million post-Glamsterdam gas limit floor, made possible by the structural timing advantages of ePBS, the throughput headroom provided by BALs, and the state-growth protections of EIP-8037.
Other Glamsterdam Threads
Beyond ePBS, BALs, and gas repricings, the remaining scope of the Glamsterdam upgrade was thoroughly debated and refined across numerous breakout sessions. Consensus Layer teams finalized decisions regarding smaller EIPs. EIP-8061, which increases the exit and consolidation churn limit, was incorporated directly into glamsterdam-devnet-1. Conversely, EIP-8080, which proposed exits via the consolidation queue, was formally declined for inclusion. EIP-8045, targeting slashed-validator duty removal, was significantly descoped to apply exclusively to proposer duties within the look-ahead window. Meanwhile, EIP-8037 and EIP-7688 concerning SSZ stable containers remain within the broader Glamsterdam scope, though EIP-7688 was held out of the initial devnet while developers address bounded gossip-message sizing for attestations under progressive lists.
During a Wednesday morning sync architecture breakout between the Execution and Consensus layers, developers chose to defer EIP-8237 out of Glamsterdam. This decision preserves architectural optionality for a more comprehensive "top-up sync" framework in a future network upgrade. In its place, attendees agreed to draft an alternative EIP that standardizes forkchoiceUpdated, newPayload, and getPayload sequencing, outlines a clear snap-sync initiation handshake, and tightens valid-and-invalid consistency across engine API surfaces.
Client hardening remained a persistent focus throughout the week. A dedicated Thursday session explored fork-choice compliance testing frameworks, examined the Diamond repository containing reproducible Consensus Layer edge-case scenarios, and demonstrated buildoor, EthPandaOps’s external-builder testing tool, which was subjected to a continuous stream of impromptu attack scenarios proposed by attendees on the spot.
Beyond Glamsterdam
Looking past the immediate horizon of Glamsterdam, several breakout discussions turned their attention toward Hegotá and subsequent network upgrades.
A deliberately proposal-agnostic session kicked off explorations into native Account Abstraction, carefully mapping out the functional requirements and strict constraints that any future design must satisfy. Desired feature sets—including alternative signature schemes, transaction aggregation, batching, account recovery, gas sponsorship, flexible nonces, and smart keystore wallets—were weighed against unforgiving constraints such as public mempool compatibility, statelessness preservation, and resistance to Layer 2 denial-of-service vectors.
A Thursday FOCIL breakout highlighted tangible implementation progress, noting that early software prototypes were already operational, with multi-client interoperability and a dedicated FOCIL devnet established as immediate next milestones. Key design choices finalized during the session included disabling FOCIL during periods of two-epoch non-finality to mirror existing proposer-boost circuit-breaker behavior, and adopting an index-based bookmark approach to ensure seamless compatibility with frame transactions and EIP-7702.
Looking even further ahead, a persistent peer-to-peer networking track sketched out a QUIC-based alternative to libp2p featuring default privacy and slot-aware integration. This track also reviewed an erasure-coded broadcast prototype that demonstrated roughly six times faster propagation speeds compared to standard GossipSub when handling 2.4-megabyte payloads. Additionally, the Consensus Layer track surfaced strong community sentiment favoring the eventual deprecation of validator consolidations entirely—suggesting a final network upgrade to support them one last time, followed by a transition where validators must perform a formal exit-then-redeposit procedure as a cleaner long-term solution to validator-set state growth.
ACD Process
On Wednesday afternoon, AllCoreDevs Execution co-leads Nixo and Ansgar hosted an open session to gather structured feedback from core contributors regarding the broader AllCoreDevs process. The discussion revisited the headliner construct, weighed the practical benefits and drawbacks of utilizing a strawmap, and formalized criteria for EIP Readiness for Implementation (SFI).
Attendees expressed a broad desire to retain upgrade headliners while loosening the rigidity between EIPs and overarching themes, ultimately accepting a flexible "theme plus candidate EIP" pattern. The per-fork year assignments outlined in the strawmap past 2026 were widely criticized as overly canonicalized and are expected to be softened. A newly revised four-point SFI definition was introduced, establishing that AllCoreDevs Testing signals implementation readiness while the Execution and Consensus layers retain final authorization authority. Furthermore, a modernized prioritization and ordering process—triggered following Core Consensus Decisions and reflected in the corresponding meta-EIP—will replace SFI’s historical role in dictating devnet inclusion, starting with the Hegotá upgrade cycle.
On the call-coordination front, Alex Stokes announced a three-month sabbatical beginning the following week. Pari will step in to moderate AllCoreDevs Consensus meetings during his absence, while Barnabas Busa will temporarily cover AllCoreDevs Testing duties. In summary, Nixo and Ansgar chair AllCoreDevs Execution, Pari serves as interim moderator for Consensus, and Mario, Barnabas, and Danceratopz rotate moderation responsibilities for Testing.
Everything Else
Beyond these major focal points, engineering teams utilized the rare in-person environment to advance numerous auxiliary projects. Improvements ranged from optimized test harnesses that compressed Hive feedback loops from hours down to minutes, to engine API plumbing enhancements covering gossip deduplication, batched calls, and light-client-driven head discovery, alongside candid discussions addressing the ongoing challenges of client diversity. A comprehensive repository of session notes remains publicly accessible via the event portal.
Next Steps
With the Svalbard summit concluded, participating teams are returning home to transition their Arctic prototypes into production-ready software. The coming weeks will see developers focused heavily on hardening client implementations against newly minted specifications, finalizing comprehensive test coverage, and converting Soldõgn’s draft pull requests into merged codebase features.
As is standard practice within the Ethereum ecosystem, final decisions concerning critical economic values, such as the 200 million gas limit target and definitive repricing numbers, will be formally confirmed and shared transparently during upcoming AllCoreDevs calls. The community extended its gratitude to all the contributors who traveled to 78°N to make the summit a resounding success, with special recognition directed toward EthPandaOps for keeping the multi-client tracks coordinated, and to the Ethrex development crew for participating in their first-ever interop.
Ethereum & Smart Contracts
Ethereum & Smart Contracts
Ethereum & Smart Contracts
