Glamsterdam’s Sepolia Test: Ethereum Rebuilds the Machinery of Capacity
Glamsterdam links protocol-native block building, parallel-friendly validation and sustainable state pricing. Editorial illustration.
Research date: 11 October 2026.
Executive summary
Ethereum’s Glamsterdam upgrade crossed an important threshold on 6 October when it activated on Sepolia. The public Forkcast planning tracker now marks that fork complete, while the Ethereum Foundation’s launch notice records the activation point as epoch 353,024, slot 11,296,768 at 13:53:36 UTC. The distinction matters: a public-testnet deployment is strong evidence that the package has moved beyond private development networks, but it is not a mainnet launch. The Foundation’s announcement leaves both Hoodi and mainnet dates undecided; any precise mainnet date circulating without a newer core-developer decision should therefore be treated as a target, not a commitment.
The upgrade is best understood as an attempt to change Ethereum’s capacity function, not as a collection of conveniences. Its three linked interventions attack three different constraints. Enshrined proposer-builder separation (ePBS) moves a critical block-market exchange into consensus and gives execution payloads more time to propagate. Block-level access lists (BALs) make state dependencies explicit so clients can prefetch data and perform parts of validation in parallel. Revised gas accounting makes durable state creation and access better reflect their long-run burden on nodes. Together they seek to permit more work without turning ordinary node operation into an industrial activity.
Our thesis is deliberately narrower than “Glamsterdam scales Ethereum.” Sepolia has demonstrated that a multi-client network can cross the fork boundary; it has not yet demonstrated stable performance at mainnet load, healthy builder competition under the new rules, or the absence of application regressions from gas repricing. The institutional significance lies in Ethereum changing the architecture that governs future capacity. The investment and operating implication is to watch validation margins, client diversity, builder concentration and state growth—not merely headline gas limits or short-term fees.
What happened, and what remains unproven
The Ethereum Foundation’s testnet announcement defines Glamsterdam as the combination of the Amsterdam execution-layer upgrade and the Gloas consensus-layer upgrade. It lists 18 scheduled core EIPs, led by EIP-7732 and EIP-7928, plus supporting networking and informational proposals. The public Forkcast schedule marks Sepolia on 6 October as complete and displays Hoodi and mainnet planning separately. This is the cleanest evidence available as of the research cutoff: activation occurred, but production deployment remains gated by further testing and coordination.
That staging is not ceremony. Unlike an application release, an Ethereum fork requires execution clients, consensus clients, validators, builders and surrounding infrastructure to converge on the same rules at the same time. The Foundation listed six Sepolia-ready consensus clients and six execution clients, but “ready” means they implement the fork rules—not that every pairing has been exhaustively proven under adversarial and peak-load conditions. Sepolia is where interface assumptions encounter a heterogeneous public network.
flowchart LR
A[Devnets and specifications] --> B[Sepolia activation<br/>6 Oct 2026]
B --> C{Observe across clients}
C -->|Stable and compatible| D[Hoodi rehearsal]
C -->|Defects or regressions| E[Fix, retest, reassess]
E --> C
D --> F{Core-developer decision}
F -->|Go| G[Mainnet activation<br/>date not yet confirmed]
F -->|No-go| EThe sequence also prevents a common analytical error: translating a successful fork directly into an earnings, throughput or fee forecast. Sepolia is a validation milestone. Hoodi is intended to be another rehearsal. Mainnet timing remains a governance and engineering output, not an input that analysts should assume.
ePBS: making the block market part of the protocol
Ethereum already has a division of labour between proposers, who are selected by consensus, and sophisticated builders, who assemble transaction payloads. Today much of that exchange depends on external relays and MEV-Boost-style middleware. EIP-7732 brings the basic exchange into the protocol: a proposer includes a builder’s commitment, the builder reveals the payload, and protocol rules handle payment and timeliness.
The design has two strategic effects. First, it reduces the relay’s role as a trusted intermediary for the core payload-for-payment exchange. It does not abolish off-protocol services; builders and validators may still use them for richer features. But the minimum viable market no longer needs the same trusted handoff. Second, it separates consensus-block validation from execution-payload validation. A payload timeliness committee reports whether the builder revealed its payload and associated blob data on time. Ethereum.org’s Glamsterdam roadmap describes this as extending the effective propagation window from roughly two seconds to about nine seconds.
That extra time is the capacity dividend. Larger payloads are only useful if data can reach validators and be checked without increasing missed slots or concentrating validation among operators with exceptional connectivity. ePBS rearranges the clock rather than simply raising a limit. For institutions, it also changes the infrastructure map: relay dependence may decline, while builder availability, payment mechanics, committee performance and monitoring become first-order operational concerns.
The counterargument is equally important. Protocol inclusion does not guarantee competitive block building. Scale economies in order flow, simulation and latency could preserve or deepen builder concentration. Nor does enshrining a market remove complexity; it moves additional state transitions and failure cases into consensus, where bugs have broad consequences. The right benchmark is therefore not “relays eliminated,” but whether the new market reduces trust dependencies while maintaining censorship resistance, builder entry and reliable payload delivery.
BALs: turning execution dependencies into usable data
Ethereum transactions interact with a shared state. Without knowing which accounts and storage locations a transaction will read or change, clients must discover dependencies during execution, constraining safe parallel work. EIP-7928 introduces an enforced block-level access list containing accessed state and post-transaction changes, with a commitment included in the block.
BALs are not a claim that every Ethereum transaction suddenly executes in parallel. They are an information layer. Clients can use the list to prefetch state from disk, identify non-conflicting work, validate transactions in parallel and calculate state roots more efficiently. That shifts a bottleneck from blind, sequential discovery toward scheduled work with an explicit dependency map. Benefits will still depend on client engineering, hardware, workload composition and the overhead of producing and distributing the lists.
This is why BALs and ePBS belong in one package. ePBS creates a longer and more structured delivery window; BALs help clients use that window efficiently. Either intervention in isolation leaves another constraint exposed.
Capacity is an end-to-end system: relaxing one bottleneck is useful only if validation and state growth remain manageable. Editorial illustration.
flowchart TB
U[More L1 demand and larger payloads] --> P[ePBS expands and formalizes<br/>the payload delivery window]
P --> V[BALs expose state dependencies<br/>for prefetch and parallel validation]
V --> S[Gas repricing charges durable state<br/>closer to its node burden]
S --> O[Potentially higher sustainable capacity]
O --> R{Observed outcomes}
R --> R1[Fees and inclusion]
R --> R2[Missed slots and finality]
R --> R3[Node hardware and sync time]
R --> R4[Builder and client concentration]Gas reform: capacity with a balance sheet
More throughput can be deceptive if every unit of activity leaves permanent data that all validating nodes must store and access. Glamsterdam therefore reprices several resources rather than treating gas as a single rough proxy for all costs. The Foundation highlights EIP-8037, which raises and separately meters state-creation costs, and EIP-8038, which updates state-access pricing. The roadmap says the state-creation model targets a predictable 120 GiB annual growth rate and separates state charges through a reservoir mechanism.
The economic logic is sound: charge actions according to the persistent burden they impose, and do not allow underpriced storage to consume the headroom created elsewhere. But repricing redistributes costs. A plain transfer to an existing account can become cheaper under EIP-2780, while deploying contracts, creating accounts or writing durable state may become more expensive. “More capacity” therefore does not imply every application becomes cheaper in the same proportion.
This redistribution is one reason application compatibility deserves more attention than the headline limit. The Foundation explicitly warns that contracts relying on fixed gas stipends, hard-coded limits or assumptions about remaining gas may need changes. A simulation that merely confirms successful execution is insufficient; teams need to examine user-facing fee variance, batch economics, paymaster policies and failure modes under congestion. For investors and operators, applications with storage-heavy business models may see different unit economics from lightweight transfers or compute-heavy activity.
Secondary changes with primary consequences
The package contains several changes that could matter independently. EIP-7708 makes native ETH transfers emit logs, improving accounting and indexing without requiring the same tracing techniques. EIP-2780 makes intrinsic transaction gas resource-based and, according to the roadmap, could make a simple transfer between existing accounts up to 71% cheaper, while retaining a surcharge when a new account must be created. EIP-8061 separates validator exit and consolidation capacity: ethereum.org estimates roughly four times the current exit capacity and twice the consolidation capacity at current staking levels.
Those staking changes carry a trade-off. Faster exits improve liquidity and reduce queue risk, and faster consolidation can shrink operational overhead. Yet the roadmap says the weak-subjectivity period would fall from about 15.7 days to roughly seven days, meaning an offline node needs a recent trusted checkpoint sooner. That is not a reason to reject the change; it is a reminder that throughput, liquidity and recovery assumptions are coupled.
For data providers, EIP-7708 may improve observability. For wallet and payment products, EIP-2780 could alter the economics of native transfers. For staking businesses, EIP-8061 changes queue behaviour and recovery procedures. Treating Glamsterdam solely as a scaling fork would miss these operating-model effects.
An institutional scorecard for the next stage
The next decision should be evidence-led. Four groups of indicators matter.
Question | Evidence to watch | Why it matters |
|---|---|---|
Does the new block pipeline remain reliable? | Payload reveal timeliness, missed slots, reorgs, finality delays | Capacity that weakens consensus reliability is not sustainable capacity |
Do clients realize parallelism safely? | Cross-client agreement, validation time, sync behaviour, BAL overhead | The theoretical gain must survive heterogeneous implementations |
Does decentralization remain affordable? | CPU, memory, bandwidth, disk growth and home-node performance | Higher limits can silently raise the minimum viable operator profile |
Does the block market become healthier? | Builder share, failed payments, relay usage, censorship signals | Removing one intermediary does not guarantee less concentration |
Are applications economically compatible? | Reverts, estimation errors, deployment and state-heavy transaction costs | Gas reform creates winners, losers and migration risk |
No single metric settles the case. A low fee could reflect spare demand rather than higher capacity; a high gas limit says nothing about validation headroom; a clean finalization event may conceal client-specific performance cliffs. Analysts should look for consistency across the system.
Risks and counterarguments
Testnet inference risk. Sepolia’s traffic, validator economics and builder incentives differ from mainnet. A successful activation proves coordination and basic interoperability, not production resilience.
Complexity risk. ePBS and BALs create new consensus objects, networking paths and duties. The design may remove off-protocol trust while increasing the amount of consensus-critical machinery. Security review and multi-client testing are therefore central, not ancillary.
Centralization risk. A longer propagation window can help geographically diverse validators, but larger payloads and specialized building may still advantage well-capitalized operators. Builder concentration and node resource requirements should be measured after deployment, not inferred from architecture.
Demand elasticity. If capacity rises, lower marginal costs can attract more activity. State repricing contains one externality, but induced demand may absorb headroom quickly. Sustainable scaling is a moving target.
Narrative risk. Markets may price Glamsterdam as an immediate fee catalyst. The package creates capacity options; realized user outcomes depend on mainnet scheduling, client optimization, operator adoption and demand. The meta-EIP, EIP-7773, remains the authoritative scope reference, and the Foundation has cautioned that mainnet activation requires a separate announcement.
Conclusion
Glamsterdam is consequential because Ethereum is changing how it budgets time, information and storage. ePBS budgets more time for a trust-minimized payload exchange; BALs provide information clients can use to parallelize validation; gas reform gives permanent state a clearer economic cost. That combination is more credible than a naked gas-limit increase because it addresses the constraints that make higher limits dangerous.
Sepolia is a meaningful success, but it is the start of public evidence collection rather than the end of the upgrade process. The mainnet case will be strongest if the next stage shows consistent client behaviour, timely payload delivery, manageable node requirements, healthy builder competition and application compatibility. Until then, the disciplined interpretation is neither dismissal nor triumphalism: Ethereum has installed a new capacity architecture on a major testnet, and the network must now prove that architecture under increasingly realistic conditions.