Ethereum Core Developers Converge in Arctic for Soldøgn Interop, Charting Course for Glamsterdam Upgrade and 200M Gas Limit

Just over 100 Ethereum core contributors recently concluded the Soldøgn Interop, an intensive week of collaborative development held above the Arctic Circle in Longyearbyen, Svalbard. The pivotal gathering focused on hardening the upcoming Glamsterdam network upgrade, achieving significant milestones including the alignment on a post-Glamsterdam gas limit floor of 200 million, stable ePBS implementations with external builders, and finalized EIP-8037 repricing numbers. This progress is a crucial step in Ethereum’s ongoing evolution towards enhanced scalability, efficiency, and decentralization.

A Unique Setting for Critical Development

The choice of Longyearbyen, Svalbard, for the Soldøgn Interop was both strategic and symbolic. This remote archipelago, one of the northernmost inhabited places on Earth, offers a unique environment where individuals of any nationality can reside and work without a visa, fostering an inclusive atmosphere for global collaboration. Beyond its accessible borders, Svalbard is renowned for its cold-storage facilities, including the Global Seed Vault and the Arctic World Archive. These subterranean repositories, carved into the permafrost, safeguard humanity’s most vital assets—from crop diversity to cultural heritage and critical source code, including a snapshot of Ethereum’s own foundational code. This parallel with Ethereum’s mission to build a resilient, enduring digital infrastructure resonated deeply with the developers.

Adding to the unique atmosphere, late April through August in Svalbard experiences 24/7 daylight, a phenomenon known as the "midnight sun." This constant uptime served as a metaphor for Ethereum’s own round-the-clock operation, with core developers maximizing the extended daylight hours for intense, focused work sessions that often stretched into what would typically be the early morning. This environment, far removed from daily distractions, facilitated an unparalleled level of concentration and productivity among the diverse group of engineers and researchers.

Glamsterdam: A Leap Towards Scalability

The Soldøgn Interop represents a continuation of Ethereum’s interop series, following events like last year’s Berlinterop and returning to the highly focused, single-track format pioneered by Amphora, Edelweiss, and Nyota. These gatherings are vital for Ethereum’s multi-client architecture, ensuring that different client implementations (like Geth, Erigon, Lighthouse, Prysm, Teku, etc.) remain compatible and robust as the network evolves. The primary objective of Soldøgn was to "harden Glamsterdam," a forthcoming network upgrade designed to significantly improve Ethereum’s transaction processing capabilities and overall throughput.

Glamsterdam addresses several multi-dimensional challenges inherent in safely raising the network’s gas limit—the maximum amount of computational work a block can contain. These challenges include optimizing how blocks are built and proposed, ensuring client implementations can handle increased loads, and managing the scaling of state-creation costs alongside higher transaction throughput. The ultimate goal of the week was to establish a stable multi-client Glamsterdam development network, complete with the latest ePBS (Ethereum Proposer-Builder Separation), repricing, and block access list specifications, supported by robust benchmarking data to justify a credible gas limit increase. The successful outcome of a 200 million gas limit floor—a substantial increase from the current 30 million gas limit—underscores the profound impact of the week’s work. This enhancement promises lower transaction fees and greater capacity for decentralized applications (dApps), opening new possibilities for developers and users alike.

Key Technical Achievements: ePBS, BAL, and Gas Repricing

The Soldøgn Interop saw significant progress across three core technical pillars of the Glamsterdam upgrade:

• Enhanced Proposer-Builder Separation (ePBS): A cornerstone of Glamsterdam, ePBS aims to further refine the proposer/builder relationship, a critical component introduced during "The Merge" to improve censorship resistance and network efficiency. ePBS restructures block slots by introducing explicit deadlines for block construction, payload revelation, and attestations. This creates more predictable time allocations for execution, directly contributing to the headroom needed for a higher gas limit.

  • The week began with the ambitious goal of establishing a 4 Execution Layer (EL) x 4 Consensus Layer (CL) Glamsterdam devnet. Initial attempts revealed crucial issues, pushing the target to a stable 4×3 configuration by Tuesday, enabling stress testing.
  • The remainder of the week involved an intensive ePBS hardening cycle: continuous stress testing, identification and resolution of edge cases, and iterative fixes. A Tuesday morning breakout session on the Builder API led to a substantial simplification of specifications related to validator registration, the bid/header/commitments flow, builder payment trust models, and circuit-breaker behaviors.
  • Mid-week debugging uncovered cross-client edge cases, particularly concerning execution-request invalidation of beacon requests, highlighting a gap across all client implementations. By Thursday, CL teams reported stable ePBS, with EL-side bid pathways resolving by Friday. Two contentious questions remain for 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 P2P Sybil-based liveness attacks.
  • By Friday, nearly all clients were successfully running together on glamsterdam-devnet-2, with the external builders pipeline tested end-to-end, marking a significant step towards a more robust and efficient block production process.

• Block-Level Access List (BAL) Optimizations: While ePBS tackles the consensus layer aspects of Glamsterdam’s scaling, Block-Level Access Lists (EIP-7928) are its execution layer counterpart. BALs provide clients with upfront information about a block’s read/write set, enabling parallel execution, batched I/O, and parallel state-root computation. These optimizations are crucial for determining how large a block clients can efficiently handle.

  

  • The BAL track operated on dedicated devnets, isolating its optimization benchmarks from consensus-layer stabilization efforts. Each optimization was placed behind its own feature flag, allowing for isolated comparison and measurement.
  • A dedicated BAL benchmark dashboard and leaderboard were instrumental in identifying each client’s worst-case scenarios across the test suite. By focusing on improving the slowest paths first, teams could collectively raise the gas limit floor for all implementations, ensuring a broad-based performance uplift. This collaborative approach highlights Ethereum’s commitment to robust and inclusive development across its diverse client ecosystem.

• Gas Repricings (EIP-8037): Glamsterdam also includes several execution layer gas repricings designed to calibrate transaction costs more accurately to actual resource usage at higher throughputs. EIP-8037, specifically, targets state-creation gas costs, increasing the price of writing new state. This measure is crucial to prevent a higher gas limit from leading to uncontrolled state growth, which could negatively impact network health and decentralization.

  • Initially, EIP-8037 proposed dynamic per-state-byte pricing tied to the block gas limit, which proved challenging for testing and benchmarking. Early in the week, teams agreed to simplify this by adopting a fixed cost_per_state_byte, with future repricings handled at subsequent fork boundaries.
  • The accounting model for gas repricing underwent several iterations throughout the week. Monday’s breakout moved state-gas accounting from mid-execution to end-of-call-frame. A Tuesday follow-up addressed account creation costs, code deposit costs, and CREATE-transaction reverts. Wednesday’s discussions surfaced complex reservoir refund/refill edge cases, prompting a fundamental rethink. By Thursday, accounting reverted to the opcode level, as it was determined that the primary complexity lay within the reservoir model itself.
  • By Friday, the specification had stabilized on bal-devnet-6, with the BAL track delivering the final repricing numbers. This rapid iteration and resolution of complex design issues—compressing weeks of asynchronous progress into days—exemplifies the power of in-person interop events.

These three threads converged to establish the headline achievement of the week: a credible 200 million post-Glamsterdam gas limit floor. This significant increase is made possible by ePBS restructuring the slot to provide more execution time, BAL optimizations granting clients the necessary throughput headroom, and EIP-8037 ensuring that the higher gas limit does not result in unsustainable state growth.

Other Glamsterdam Threads and Future Horizons

Beyond the core pillars, several other Glamsterdam-related EIPs were deliberated:

• EIP-8061 (exit/consolidation churn increase) was included in glamsterdam-devnet-1.
• EIP-8080 (exits via the consolidation queue) was declined.
• EIP-8045 (slashed-validator duty removal) was scoped down to proposer duties within the look-ahead window.
• EIP-7688 (SSZ stable containers) remains in Glamsterdam scope but was held out of glamsterdam-devnet-1 pending work on bounded gossip-message size for attestations under progressive lists.

A Wednesday EL/CL sync architecture breakout deferred EIP-8237 out of Glamsterdam, preserving optionality for a longer-term "top-up sync" architecture. Instead, an EIP will be drafted to normalize forkchoiceUpdated / newPayload / getPayload sequencing, specify a snap-sync initiation handshake, and tighten valid/invalid consistency between engine API surfaces. Hardening was a pervasive theme, with sessions covering fork-choice compliance testing frameworks, the Diamond repo for CL edge-case scenarios, and buildoor, PandaOps’ external-builder testing tool, which demonstrated attack scenarios suggested by attendees on the spot.

The interop also cast an eye towards future upgrades, particularly Hegotà and beyond:

• Native Account Abstraction: A proposal-agnostic session explored the requirements for native Account Abstraction, aiming to enable features like alternative signature schemes, aggregation, batching, recovery, gas sponsorship, and flexible nonces, all while maintaining public-mempool compatibility, statelessness, and L2 DoS resistance. This would dramatically enhance user experience and developer flexibility.
• FOCIL (Fork Choice Optimizations for Inactivity Leaks): An implementation update highlighted functional early prototypes, with multi-client interop and a dedicated FOCIL devnet as immediate next steps. Key design decisions included disabling FOCIL during 2-epoch non-finality and adopting an index-based bookmark approach for compatibility with frame transactions / EIP-7702.
• ETH P2P: A long-running track sketched a QUIC-based replacement for libp2p, aiming for privacy-by-default and slot-aware integration. An erasure-coded broadcast prototype simulated approximately 6x faster propagation than GossipSub on 2.4 MB payloads, promising substantial improvements in network communication efficiency.
• Validator Set State Growth: The CL track expressed strong sentiment towards eventually deprecating consolidations entirely, proposing a final fork that supports them, followed by a forced exit-then-redeposit mechanism. This is seen as a cleaner long-term solution to managing validator-set state growth and improving network efficiency.

Governance and Community Process

Mid-week, Nixo and Ansgar, the two All Core Devs Execution (ACDE) co-leads, facilitated a session to gather input on the ACD process itself. Discussions revisited the "headliner construct," debated the utility of a "strawmap," and formalized EIP "Specification Finalization (SFI)" criteria. The consensus favored retaining headliners but with increased flexibility for "theme + candidate EIP" patterns. The strawmap’s year assignments beyond 2026 were deemed overly rigid and likely to be softened. A new four-point SFI definition was introduced, granting ACDT (All Core Devs Testing) signaling readiness while ACDE/ACDC (All Core Devs Consensus) retain final authority. A new prioritization-ordering process, replacing SFI’s role in driving devnet inclusion, will commence with Hegotà.

Leadership changes were also announced: Alex Stokes will take a three-month sabbatical, with Pari covering ACDC moderation and Barnabas filling in for ACDT. The current ACD leadership structure sees Nixo and Ansgar chairing ACDE, Pari as interim on ACDC, and Mario, Barnabas, and Danceratopz rotating ACDT moderation. These robust governance processes are essential for coordinating decentralized development across a global community.

Operational Success and Next Steps

The Soldøgn Interop was supported by three Ethereum Foundation teams: EthPandaOps provided ethIQ and a panda MCP server for agentic workflows; Protocol Support established soldogn.xyz as the central hub for interop goals, schedule, and notes; and the EF Digital Studio team documented the entire week on film, promising the very first interop documentary. This logistical support was crucial for the seamless execution of the highly technical agenda.

Beyond the formal sessions, teams leveraged the in-person environment to make progress on a myriad of topics, from enhancing test harnesses (reducing Hive feedback loops from hours to minutes) to improving engine-API plumbing (gossip dedup, batched calls, light-client-driven head discovery) and navigating complex tradeoffs around client diversity. The comprehensive session notes are available at soldogn.xyz.

As core contributors return from Svalbard, the immediate next steps involve translating the prototypes and agreements from Soldøgn into production-ready code. The coming weeks will be characterized by heads-down work to harden client implementations against the new specifications, finalize test coverage, and merge the draft PRs into the main codebase. The final decisions on critical values, such as the 200 million gas limit target and definitive repricing numbers, will be formally announced and discussed during upcoming AllCoreDevs calls, which are expected to be major topics in the immediate future.

The Soldøgn Interop stands as a testament to the dedication and collaborative spirit of the Ethereum core contributors, demonstrating their ability to achieve profound technical progress in a uniquely challenging yet inspiring environment. The success of this gathering above the Arctic Circle has laid a firm foundation for the Glamsterdam upgrade, propelling Ethereum closer to its vision of a scalable, efficient, and decentralized global computing platform.