Glamsterdam on Sepolia: Ethereum’s Scaling Bet Moves From Capacity to Architecture
Glamsterdam reached Sepolia on 6 October 2026. The milestone tests a redesigned block pipeline—not merely a larger block.
Executive summary
Ethereum’s Glamsterdam upgrade activated on the Sepolia testnet at epoch 353,024—slot 11,296,768—at 13:53:36 UTC on 6 October 2026. Two days later, the most useful interpretation is neither “Ethereum has solved scaling” nor “this is only a testnet.” Sepolia is the first long-lived public proving ground for a package that changes who constructs a block, how clients discover independent work inside it, and how the protocol charges for the state that execution leaves behind. The upgrade therefore tests whether Ethereum can raise Layer 1 capacity without weakening verification or making state growth an unpriced subsidy.
Three features carry the thesis. Enshrined proposer-builder separation (ePBS, EIP-7732) brings the exchange between validators and specialist block builders into consensus, reducing dependence on trusted relay middleware and giving execution validation more time. Block-level access lists (BALs, EIP-7928) describe the accounts and storage touched by a block, creating the data dependency map clients need for parallel execution and more efficient state handling. State-creation and state-access repricing (EIP-8037 and EIP-8038) makes persistent storage and database work more closely reflect their resource burden. The official Glamsterdam meta-EIP lists these alongside a wider bundle of execution, consensus and networking changes.
The package is coherent because each component constrains the others. Bigger blocks are useful only if they can propagate and validate on time; parallel execution is useful only if conflicts can be identified; higher throughput is sustainable only if state growth and access are correctly priced. Glamsterdam is best understood as an attempt to turn that three-way dependency into protocol machinery.
The caveat is decisive: this is not yet a mainnet result. Ethereum’s official deployment table still leaves Hoodi and mainnet activation undecided. Sepolia’s activation establishes that the fork can run on a public testnet; it does not establish production readiness, economic robustness under mainnet builder competition, or the safe ceiling for gas-limit increases. Institutional users should treat the milestone as a meaningful reduction in technical uncertainty, not as a throughput promise with a delivery date.
What changed on 6 October
The Ethereum Foundation’s testnet announcement scheduled Glamsterdam for Sepolia at epoch 353,024 and required node operators to update both execution and consensus clients. The canonical Glamsterdam deployment page records the same epoch, slot and timestamp while marking Hoodi and mainnet as not yet determined. Sepolia’s network configuration now identifies Gloas as its active consensus fork at that epoch, with the corresponding Amsterdam execution timestamp. This evidence supports a narrow but important claim: the scheduled public-testnet transition occurred and the upgraded chain configuration is live. It does not support declaring mainnet ready.
The scope is broader than its three headline ideas. EIP-7773, the Glamsterdam meta-EIP, enumerates 17 included EIPs, plus networking changes. Among them are ETH-transfer logs, revised block gas accounting, a slot-number opcode, a larger maximum contract size, changes to calldata and access-list costs, a deterministic factory contract, validator and exit-churn changes, removal of the remaining SELFDESTRUCT burn behavior, and builder execution requests. Treating the fork as a single-feature release therefore misses both its ambition and its integration risk.
timeline
title Glamsterdam's path to public testnet
2025-12 : Fusaka activates on mainnet
: PeerDAS changes blob-data verification
2026-08 : Platåberget opens for early public testing
: Developers warn about hard-capped gas assumptions
2026-09 : Sepolia date and client releases confirmed
2026-10-06 : Glamsterdam activates on Sepolia
: ePBS, BALs and repricing enter long-lived public testing
Undecided : Hoodi activation
: Mainnet activationThe timeline matters because Ethereum’s upgrade process is deliberately staged. Devnets and the temporary Platåberget network exposed breaking assumptions before a persistent public testnet carried the fork. Sepolia now broadens the participant set: client implementations, validators, infrastructure providers, wallets and applications encounter the same rules. Hoodi remains the venue expected to test validator operations more directly, while mainnet represents a separate governance and risk decision. A successful fork boundary is an entry ticket to the next phase, not the end of testing.
A new market structure inside consensus
Today’s Ethereum block market already separates proposing from building in practice. A validator commonly chooses a bid assembled by a specialist builder, with relay infrastructure mediating the exchange. This delivered an efficient market for block construction, but placed critical coordination outside the protocol. EIP-7732’s central move is to recognize that reality and encode a fair exchange between proposer and builder in consensus.
The EIP-7732 specification gives three strategic motivations. First, an honest proposer should receive the builder’s payment and an honest builder should have its revealed payload recognized without trusting a relay to complete the exchange. Second, separating consensus-block validation from later execution-payload validation gives validators more of the slot to execute and verify data. Third, removing the full execution payload from the consensus block’s critical path improves propagation conditions. In combination, those properties can create more room for larger payloads without compressing validator deadlines.
flowchart LR
subgraph Externalized[Pre-Glamsterdam market]
B1[Builder] -->|bid and payload| R[Trusted relay]
R -->|blinded block exchange| P1[Proposer]
P1 --> A1[Attesters validate consensus and execution on a tight path]
end
subgraph Enshrined[Glamsterdam ePBS]
B2[Builder commits bid] --> P2[Proposer commits header]
P2 --> C[Consensus block is attested]
B2 -->|later payload reveal| E[Payload timeliness committee and execution validation]
C --> E
E --> N[Next-slot fork choice]
endThis is not equivalent to abolishing builders, MEV or concentration. It relocates the exchange boundary. Relays may lose their consensus-critical role, but sophisticated construction remains capital-, latency- and information-intensive. The ePBS design also introduces new failure modes. The EIP explicitly discusses a “free option” in which a builder may rationally withhold a payload when withholding becomes more profitable, causing missed execution payloads and degraded user experience. It also describes collusion and reorganization conditions affecting builder safety. The protocol can make the exchange trust-minimized without making the market structurally competitive.
For institutions, this distinction is material. Removing trusted middleware reduces one operational dependency and makes the settlement process easier to reason about at the protocol level. Yet concentration metrics for builders, payload-withholding rates, payment reliability and censorship behavior remain necessary. Governance should ask whether risk has been eliminated, transferred or made measurable. In ePBS, much of it is transferred into explicit consensus rules—which is valuable—but not erased.
Parallelism needs a map
Ethereum has traditionally executed transactions in canonical order. Multicore hardware cannot safely process arbitrary state transitions in parallel unless the client knows which transactions touch overlapping data. EIP-7928 adds a block-level access list: a structured account of the state locations read or written during the block. That record turns implicit dependencies into explicit data.
The immediate value is not a marketing number for transactions per second. It is optionality in client design. A client can use the dependency information to schedule non-conflicting work concurrently, validate state changes, support more efficient syncing, and retrieve the relevant portions of state. Geth’s Sepolia-ready v1.17.7 release notes document dedicated handling for encoding and hashing BALs as well as BAL-aware state synchronization. Its prior v1.17.6 release described parallel block execution driven by the access list. These are implementation-level signs that the proposal is no longer only theoretical.
But a dependency map has costs. It increases block-related data, creates new validation logic, and adds another artifact that clients must agree on. Parallel speedups depend on workload shape: a block full of transactions competing for the same popular state cannot be parallelized as effectively as a block with independent interactions. Faster hardware paths can also widen performance dispersion among client implementations. The right Sepolia questions are therefore empirical: Do clients derive and validate the same BAL reliably? What is the bandwidth and storage overhead? How much wall-clock execution time is saved under realistic contention? Does sync recover correctly around missing or late access-list data?
Capacity is an output of aligned constraints. Optimizing only one corner makes the system more brittle.
Repricing state: the less visible half of scaling
The most economically consequential part of Glamsterdam may also be the least legible to end users. State is persistent data that every fully verifying node must be able to work with. If creating and repeatedly accessing that state is underpriced, applications pay too little relative to the long-lived burden placed on node operators. Raising the gas limit under those conditions accelerates the subsidy.
The Ethereum Foundation’s repricing impact analysis says state-operation prices were last broadly adjusted in the 2021 Berlin fork, while Ethereum’s state has grown materially since. EIP-8037 increases and separately meters state creation—new accounts, storage slots and deployed bytecode—while EIP-8038 raises selected state-access costs to reflect measured work on today’s larger database. The stated engineering target is a schedule compatible with roughly a threefold increase in base throughput. That is a performance target, not a forecast that mainnet capacity will triple immediately.
Historical transaction replay found that the large majority of transactions were unchanged, according to the Foundation analysis. The exceptions fall into economically important categories: transactions that still succeed but consume different gas; transactions fixed by raising their gas limit; and potentially broken contracts that rely on hardcoded gas assumptions, fixed call stipends, branching on remaining gas, or presigned transactions with fixed limits. This is precisely why a testnet phase has value. Aggregate compatibility can look excellent while a small tail contains old, immutable or systemically connected contracts.
The repricing also changes what “cheaper Ethereum” means. Users may see lower unit fees when supply expands, even as particular state-heavy operations become more expensive in gas terms. That is not a contradiction. The protocol is attempting to price scarce resources more accurately while increasing total safe capacity. Applications that create durable state should bear more of that cost; computation that can exploit parallel hardware may benefit from expanded headroom. A uniform fee narrative obscures this redistribution.
What Sepolia proves—and what it cannot
The activation demonstrates multi-client coordination across a hard-fork boundary on a long-lived public network. It allows infrastructure to exercise new payload flows, access-list handling, gas estimation and contract behavior under common rules. It also gives researchers a live environment in which failure is costly enough to be informative but not financially equivalent to a mainnet incident.
It cannot reproduce mainnet economics. Sepolia does not have mainnet’s builder revenues, order-flow competition, validator incentives, DeFi composability or adversarial value at risk. A payload-withholding strategy that is irrational on a testnet may become rational when a mainnet opportunity is large. A compatibility issue in a rarely used Sepolia contract may correspond to an immutable, high-value mainnet dependency. Nor does testnet stability select a safe production gas limit automatically: client diversity, consumer hardware, state growth and worst-case blocks all matter.
The deployment status reinforces this caution. The official roadmap page describes Sepolia as the current milestone, while the protocol deployment table leaves Hoodi and mainnet unset. Those blanks are not administrative trivia. They preserve the option to respond to evidence. Any report assigning a firm mainnet date today would outrun the primary sources.
Institutional implications
For infrastructure operators, the immediate issue is observability. Existing monitors built around a single proposer-delivers-full-block mental model may miss the distinction among beacon-block commitment, payload reveal, payload timeliness and execution validation. Service-level objectives should separate consensus participation from payload availability rather than compressing both into “block produced.” Client diversity becomes more valuable when a fork changes both halves of an Ethereum node at once.
For application and custody teams, repricing is the near-term exposure. The Foundation says ordinary users need take no action and that most affected cases can be addressed through gas-limit changes, but systems with fixed gas constants, presigned transaction templates or assumptions inherited from the 2,300-gas transfer pattern deserve review. The economic question is broader than whether a transaction fails: updated estimation may alter batching, relaying and treasury policies for state-intensive workflows.
For investors and risk committees, the upgrade should not be valued as a simple capacity multiple. Its more durable contribution is architectural: less relay trust on the block-production path, explicit data dependencies for parallelism, and resource prices intended to protect decentralization as capacity rises. Evidence of value should arrive as distributions, not slogans—payload-reveal timing, missed-slot rates, client performance, BAL overhead, affected-contract counts, builder concentration and node resource requirements.
flowchart TD
S[Sepolia evidence] --> Q1{Stable across clients?}
Q1 -->|No| F1[Fix specifications or implementations]
Q1 -->|Yes| Q2{Payload and BAL metrics acceptable?}
Q2 -->|No| F2[Tune incentives, networking or limits]
Q2 -->|Yes| H[Proceed to Hoodi decision]
H --> Q3{Validator lifecycle and production-like tests pass?}
Q3 -->|No| F3[Delay or revise deployment]
Q3 -->|Yes| M[Consider mainnet activation]
M --> G[Choose capacity conservatively and monitor]Risks and counterarguments
The strongest counterargument is complexity. Glamsterdam does not merely optimize a mature pipeline; it adds consensus machinery for builder commitments and payload timeliness, a new block-level state artifact, revised gas accounting and many smaller changes in one fork. Each component may be defensible independently while their interaction enlarges the test surface. Ethereum’s multi-client design limits monoculture risk but makes specification clarity and interoperability testing non-negotiable.
A second concern is centralization by capability. Parallel execution and larger blocks can reward highly tuned machines even if minimum node requirements remain formally accessible. ePBS can remove relay trust while leaving sophisticated builders dominant. Repricing can slow state growth but disadvantage applications whose public value is not captured by their ability to pay. These are distributional choices, not purely technical optimizations.
A third concern is false precision. The Foundation links repricing to a performance target supporting roughly three times base throughput, and Sepolia clients can test high gas-limit configurations. Neither figure should be read as a mainnet commitment. Sustainable capacity is the minimum of execution, propagation, database, proof and home-node constraints under adversarial load. Testnet peak capacity is evidence for that calculation, not the answer.
The counterweight is that refusing architectural change also has a cost. Keeping block construction dependent on relay trust, leaving data dependencies implicit, and charging state according to outdated performance assumptions would constrain capacity or shift more load onto fewer professional operators. Glamsterdam’s complexity is partly the price of making existing realities explicit and accountable.
Conclusion
Glamsterdam’s Sepolia activation is important because Ethereum is testing a theory of safe scaling, not simply a bigger meter. The theory says that block-market trust can be internalized into consensus, execution can be parallelized when dependencies are explicit, and durable state can be priced closely enough to its social cost that capacity increases do not hollow out verification.
Sepolia has moved that theory from short-lived development networks into a shared public environment. The next evidence should be operational: cross-client stability, payload-reveal behavior, access-list overhead and usefulness, contract compatibility, and node performance under sustained load. Until Hoodi and mainnet dates are chosen, the honest conclusion is conditional. Glamsterdam has crossed a consequential test boundary; it has not crossed the production finish line.
Primary sources
Research cut-off: 8 October 2026, 00:00 UTC. Testnet status and undecided deployment dates are stated as of that cut-off.