Ethereum Glamsterdam Upgrade 2026: BALs, ePBS, Gas Changes, and User Impact

For broader context, the TokenToolHub blockchain advanced guides explain how protocol upgrades move from research to specifications, client implementations, devnets, public testnets, and mainnet. Glamsterdam matters because it changes both the way blocks are built and the way execution clients understand the work inside those blocks.

What the Glamsterdam name means

Ethereum upgrades affect two closely connected protocol layers. Amsterdam is the execution-layer name, following the convention of using past Devcon and Devconnect cities. Gloas is the consensus-layer name, following the convention of star names. Glamsterdam combines Gloas and Amsterdam into one convenient network-upgrade name.

The combined label is useful for users and application teams, but specifications and client implementations still distinguish the two layers. Execution clients must implement the EVM, gas, block-structure, state, and networking changes. Consensus clients must implement the builder, payload-timing, validator-duty, consensus-data, and fork-choice changes. Validators and node operators need compatible versions of both.

What Scheduled for Inclusion means

EIP-7773 lists proposals under Scheduled for Inclusion. This is stronger than a proposal merely being discussed or considered. It indicates that core developers have selected the feature for the upgrade and implementations or tests are expected to support it.

Scheduled does not mean the text is frozen. Several individual EIPs remain in Draft or Review states, parameter values can be refined, and implementation details can change as cross-client testing exposes edge cases. The fork meta EIP itself remains a Draft until the upgrade process matures.

How the mainnet date becomes final

The normal path is not a single announcement made months in advance. Client teams stabilize the full feature set on devnets, publish compatible releases, activate the upgrade on public testnets, review failures and performance, then coordinate a mainnet timestamp through All Core Developers calls. The activation fields in EIP-7773 are filled when those decisions are made.

A responsible integration should therefore track three separate facts: the target quarter, the current scheduled EIP set, and the final activation timestamp. Mixing them together creates avoidable operational risk.

Why Ethereum needs Glamsterdam

Ethereum wants more L1 capacity without making blocks too difficult to propagate, validate, store, or sync on accessible hardware. Simply raising the gas limit increases the amount of execution and data that can enter a block, but it can also increase worst-case processing time, database pressure, block size, and state growth.

Glamsterdam addresses those constraints as one connected design rather than treating throughput as a single dial.

The result is not one feature that makes Ethereum faster. It is a coordinated attempt to make higher throughput safe: more time for payload work, more information for parallel processing, tighter accounting for worst-case resources, and better lifecycle handling for the actors that build and validate blocks.

Glamsterdam impact map

The upgrade reaches much further than validators. Users may see different fees and more reliable ETH-transfer indexing. Wallets must update estimation assumptions. dApps need to test receipts, gas-sensitive flows, and state-heavy behavior. Contract teams gain larger deployment limits and new opcodes. Builders become explicit protocol actors. Node operators receive new block, network, and consensus responsibilities.

ePBS: enshrined proposer-builder separation

EIP-7732 fundamentally changes how an Ethereum block is validated. Today, proposers frequently use off-protocol software and relays to outsource execution-payload construction to specialized builders. The economic relationship exists, but core consensus does not fully own the exchange of a payload for payment.

ePBS brings that relationship into the protocol. A builder becomes a staked consensus-layer actor. The beacon block contains a signed commitment to an execution payload rather than embedding the complete payload immediately. The commitment includes the execution block hash and the value the builder commits to pay the proposer. The builder reveals the corresponding payload later in the slot.

Proposer and builder jobs become explicit

The proposer is responsible for the consensus block and selects a builder bid or self-builds. The builder assembles the execution payload, commits to it, and reveals it according to protocol deadlines. Payment logic and builder collateral are handled through consensus rules instead of depending entirely on a private relationship with a relay.

This does not guarantee that every off-protocol service disappears. Builders and proposers may still use relays or middleware for discovery, privacy, policy, or advanced services. The important difference is that Ethereum provides a native settlement and validation foundation.

Payload timing is separated from consensus timing

Before ePBS, the complete execution payload sits on a tight validation path. EIP-7732 decouples consensus validation from execution-payload validation in both logic and time. Validators can process the consensus commitment while the payload is propagated and checked under its own deadline.

A Payload Timeliness Committee attests to whether the builder revealed the payload on time. This lets the protocol reason explicitly about a commitment that exists before the complete payload is available. It also creates rules for missed reveals, disagreement, and partial-block conditions that previously sat outside core consensus.

Why ePBS creates scaling headroom

The official Glamsterdam roadmap describes an expansion of the practical propagation window from roughly two seconds to about nine seconds. More time does not make execution free, but it reduces the pressure to broadcast, execute, and validate larger payloads inside one narrow hot path.

That additional headroom supports higher gas limits and larger data workloads, provided execution clients can also process the work quickly. This is why ePBS is paired with BAL optimization and gas repricing rather than presented as an isolated throughput feature.

What builders and staking services must test

Builders need to test registration, deposits, bid construction, payload commitments, reveal deadlines, payments, exits, request processing, invalid payload handling, and recovery from missed or late messages. Staking pools must update proposer workflows, monitoring, circuit breakers, relay assumptions, fee accounting, and failure handling.

EIP-8282 supports the lifecycle with dedicated builder deposit and exit predeploys on Ethereum's execution-request bus. A builder can register or top up through the deposit contract and an authorized execution address can request a full exit through the exit contract.

BALs: block-level access lists

EIP-7928 adds a block-level access list that records the addresses and storage locations accessed during block execution, together with post-execution values for relevant changes. The block header commits to the encoded list through a block access list hash.

This is different from optional transaction access lists. A transaction author may not know every state location a complex call will reach, and existing transaction lists are not an enforced complete description. A BAL is produced for the entire executed block and must accurately represent the accesses required by the specification.

Parallel disk reads

Execution clients currently discover many state dependencies while running transactions. A BAL gives the client an upfront map of accounts and storage keys. That allows the client to fetch unrelated state in parallel or batch reads efficiently instead of waiting for each transaction to reveal the next database location.

Parallel validation and state-root computation

When transactions do not conflict on the same state, their work can be scheduled more independently. BAL data can also help clients compute sections of the post-state and state root in parallel. The speedup depends on client architecture, workload conflicts, disk behavior, and validation design, so BALs create a capability rather than guaranteeing identical performance for every block.

Executionless state updates and faster sync

Because the list contains post-execution values, a syncing node can apply validated state changes without replaying every transaction to discover the same results. Networking companions such as EIP-8159 define how peers exchange BAL data. This can improve state healing and sync workflows as the chain processes more activity.

BAL validation remains essential

The list is not trusted merely because a builder supplies it. Clients must check its commitment, structure, size, ordering, uniqueness, and agreement with execution. Malicious or malformed lists need early rejection so the new data structure does not become a denial-of-service surface.

Does Glamsterdam raise Ethereum's gas limit to 200M?

The accurate answer is more careful than a yes or no.

At the May 2026 Soldøgn interoperability event, client teams reported a credible 200M post-Glamsterdam gas-limit floor based on ePBS timing, BAL optimization, repricing, and multi-client testing. Ethereum.org also describes EIP-8037 as supporting sustainable scaling toward that level.

However, EIP-7773 does not encode an automatic mainnet jump to 200M. Ethereum's gas limit is influenced by proposer preferences and moves gradually under the EIP-1559 one-over-1024 adjustment rule. The network needs coordinated client defaults, validator preferences, builder support, and continued worst-case testing.

EIP-8261 is advisory, not a hard consensus ceiling

EIP-8261 proposes an optional epoch-based gas-limit schedule in consensus-client configuration. A scheduled value would act as the default and recommended maximum for supporting clients. Operators could still configure another value, and blocks outside the recommendation would remain valid because the EIP changes no consensus rule.

This distinction matters. A roadmap target describes tested operating capacity. A client schedule coordinates defaults. A consensus maximum determines block validity. They are not interchangeable.

A higher limit does not guarantee permanently cheap transactions

More capacity can reduce congestion pressure when demand is unchanged, but fees remain market-driven. Demand can rise to use the new capacity. Individual operations are also being repriced, so a state-heavy or data-heavy transaction may consume more gas even while the network supports more aggregate execution.

Users should think in terms of better sustainable capacity, not a fixed promise that every transaction becomes cheaper.

Gas accounting, calldata, and state changes

EIP-2780: resource-based intrinsic transaction gas

EIP-2780 replaces the universal flat 21,000 intrinsic assumption with named components that reflect the work a transaction performs. Its current specification uses a transaction base, recipient access, value-transfer work, account writes, and state creation where applicable.

A transfer of ETH to an existing EOA can remain 21,000 under the current values. A zero-value transaction to an existing account can be lower. A self-transfer can be lower still. A transfer that creates a new account carries a separate state-creation cost. Wallets must therefore estimate the specific transaction rather than applying 21,000 as a universal truth.

The EIP also distinguishes state-independent intrinsic validity costs from state-dependent runtime charges. A transaction may pass the intrinsic check but run out of gas during pre-execution state work, in which case it can be included, charged for consumed gas, and revert. Wallet simulations and explanations must handle that outcome correctly.

EIP-7778: block gas accounting without refunds

Gas refunds remain useful to transaction senders for qualifying cleanup such as clearing storage. The problem is that subtracting those refunds from block gas accounting allows a block to contain more gross computation than its headline gas limit suggests.

EIP-7778 separates the two views. The user can still receive the refund when calculating paid transaction gas, but the block accounts for the work before refunds. This makes the block limit better reflect actual computational load and closes a path for oversized workloads.

EIP-7976: higher calldata floor

EIP-7976 raises the floor to 64 gas per calldata byte for both zero and nonzero bytes. The purpose is to reduce worst-case execution-payload size and create headroom for larger gas limits without allowing blocks dominated by cheap raw data.

The floor mainly matters when calldata is the dominant resource. Transactions doing substantial EVM computation may already pay more than the floor. Rollups and applications that still publish meaningful data as calldata should benchmark the change. Blob pricing is a separate mechanism, so teams should not assume a calldata repricing directly changes blob gas.

EIP-7981: access-list data surcharge

Transaction access lists take block space but historically have not paid the same data-footprint floor as calldata. EIP-7981 adds a surcharge based on their address and storage-key bytes, currently aligned with the 64-gas-per-byte floor. This prevents a transaction from combining access lists and calldata to bypass the intended block-size protection.

EIP-8037: state creation gas and the reservoir

EIP-8037 introduces a cost per state byte and harmonizes the cost of creating accounts, storage slots, contract code, and EIP-7702 delegation state. Its target is to bound average state growth around a sustainable annual level under a reference gas limit.

State creation is metered in a separate state-gas dimension. A reservoir is reserved for state work, while ordinary execution uses execution gas. The GAS opcode reports ordinary gas left rather than the hidden reservoir. Contract teams that use gasleft-sensitive control flow, forward almost all remaining gas, estimate deployment at hard boundaries, or create large amounts of state should test carefully.

EIP-8038: state-access and write repricing

EIP-8038 raises selected costs to reflect the larger state database and measured client work. In the current specification, cold account access rises from 2,600 to 3,000, account-write cost becomes 9,000, storage-write cost becomes 10,000, and CREATE access becomes 12,000. Some warm and cold-storage read values remain unchanged.

Protocols that loop over many accounts, write storage repeatedly, inspect external code, or rely on exact gas thresholds should benchmark the final fork specification. The individual constants are protocol parameters and remain subject to the final testing process.

Contract-size, EVM, deployment, and observability changes

EIP-7954: larger contracts and initcode

EIP-7954 raises maximum deployed contract code from 24,576 bytes to 65,536 bytes and maximum initcode from 49,152 bytes to 131,072 bytes. Complex applications gain more room for features, libraries, and generated logic without splitting solely to satisfy the existing size cap.

Larger does not automatically mean better. Bigger contracts can be harder to review, upgrade, verify, and optimize. Teams should use the additional space deliberately, keep privileges modular, and compare the exact source and bytecode introduced by an upgrade.

EIP-8024: deeper stack access

EIP-8024 introduces SWAPN, DUPN, and EXCHANGE instructions that allow compilers to access or rearrange deeper stack items beyond the existing convenient depth of sixteen. The design preserves backward compatibility with existing bytecode and uses immediate operands so static analysis remains practical.

Most Solidity developers will experience this through future compiler output rather than hand-written opcodes. Compiler, disassembler, tracer, debugger, verifier, and security-tool teams must recognize the new instructions correctly.

EIP-7843: SLOTNUM

SLOTNUM exposes the current consensus slot number directly to EVM code at a fixed gas cost. Contracts no longer need to infer the slot by hardcoding a slot duration against block timestamp or submit and verify a beacon proof merely to obtain the value.

Applications should still distinguish a slot from a block. Slots can be missed, and slot number is not a guarantee that a block was produced for every prior slot.

EIP-7708: standard ETH-transfer logs

EIP-7708 creates protocol logs for nonzero ETH transfers between different accounts, including top-level transactions and value-moving CALL, SELFDESTRUCT, CREATE, and CREATE2 paths covered by the specification. This closes an observability gap between native ETH and token transfers.

Wallets, exchanges, bridges, accounting platforms, and indexers can move away from fragile trace-only detection for many ETH movements. They still need to test reverted execution, log ordering, duplicate internal accounting, and historical data before switching production pipelines.

EIP-7997: deterministic factory contract

EIP-7997 formalizes the availability of a widely used minimal CREATE2 factory at a known address. Participating EVM chains can use the same factory and deterministic inputs to deploy applications or smart accounts at matching addresses across networks.

This can simplify multi-chain configuration and reduce address confusion. It does not make every deployment safe. Initcode, salt selection, environment-dependent constructors, factory return data, and chain adoption still require verification.

EIP-7610 and EIP-8246 close edge cases

EIP-7610 makes contract creation fail when the destination address already has non-empty storage, even if other historical creation checks might allow it. This removes an unusual state ambiguity and aligns deployment with a stricter definition of an empty destination.

EIP-8246 removes the remaining rare cases where SELFDESTRUCT burns ETH. Code, storage, and nonce clearing can still occur for the limited same-transaction behavior preserved after EIP-6780, but remaining balance is retained rather than silently destroyed. Contracts should not use SELFDESTRUCT as a general upgrade or cleanup mechanism.

Every EIP currently scheduled in EIP-7773

The following table reflects the Scheduled for Inclusion section of EIP-7773 as checked on August 16, 2026. Individual specifications can continue to change before activation.

Supporting networking and informational EIPs

EIP-7773 separately lists networking proposals and informational guidance. These items may not appear in the same scheduled Core list, but they explain how clients exchange the larger or newer data structures and how operators coordinate capacity.

What wallet users should expect

No ETH conversion or token migration

ETH remains ETH. Users do not need to swap, bridge, wrap, convert, or send assets to a migration address. A message claiming that Glamsterdam requires an ETH upgrade transaction is a scam.

Wallet software should update automatically

Most users will rely on wallet providers, RPC services, exchanges, and applications to upgrade their infrastructure. The visible changes may include different gas estimates for some transactions, improved ETH-transfer history, and better behavior under higher network capacity.

Gas outcomes can differ by transaction shape

A simple transfer, contract interaction, account-creating transfer, EIP-7702 delegated call, contract deployment, and data-heavy transaction no longer fit one easy fee narrative. Users should trust a current simulation and gas estimate for the exact operation rather than copying a historical limit.

Confirm transaction meaning after the fork

Standardized ETH logs can improve history, but wallets and explorers may need time to adjust presentation. If a transfer appears twice or an internal ETH movement is displayed differently, compare the transaction receipt, call trace, and actual balance change before assuming two transfers occurred.

What wallet and dApp teams should test

What smart-contract teams should test

Re-run gas-sensitive test suites

Tests that assert exact gas consumption will change. More importantly, contracts that branch on gasleft, reserve a fixed amount for cleanup, forward nearly all remaining gas, or depend on a callee receiving a particular stipend need behavioral review. Exact gas snapshots should be separated from security properties so repricing does not hide a genuine logic failure.

Benchmark state-heavy paths

Measure new storage-slot creation, account creation, contract deployment, delegation state, account writes, external-code inspection, and repeated storage updates. Compare typical and worst-case user operations. A function that still fits within a block may nevertheless become uneconomic or exceed a product's sponsored-gas budget.

Review deployment and upgrade size

The new 64KiB code limit is an opportunity, not an instruction to remove modular design. Review proxy implementation size, initializer complexity, constructor behavior, library linking, verification support, and audit scope. Test deployment on a Glamsterdam network rather than only changing a local size constant.

Test new opcode support through the toolchain

If a compiler begins emitting SLOTNUM, SWAPN, DUPN, or EXCHANGE, confirm that the entire pipeline understands them: compiler, assembler, disassembler, debugger, tracer, verifier, static analyzer, simulator, wallet decoder, and block explorer.

Compare the exact upgrade diff

Protocol changes often prompt teams to update compilers, libraries, gas optimizations, deployment scripts, and contract architecture at the same time. Use TokenToolHub Smart Contract Diff to isolate authorization, storage, external-call, and bytecode-relevant changes before deploying a Glamsterdam-ready implementation.

What rollup teams should evaluate

Glamsterdam is an L1 upgrade, but rollups depend on L1 for data, settlement, proofs, messaging, and asset movement. The impact differs by architecture.

Separate calldata from blob economics

EIP-7976 changes the calldata floor. Blob gas remains a separate market and data path. Rollups should model fallback transactions, proof submissions, governance calls, forced inclusion, bridge messages, and any component that still uses calldata rather than assuming all data travels in blobs.

Model higher L1 execution capacity

A higher sustainable L1 gas limit can increase settlement and bridge capacity, but it can also produce larger blocks, receipts, state changes, and operational bursts. Watch confirmation assumptions, reorg handling, batch posting, L1 event ingestion, and proof-pipeline throughput.

Test multi-chain deterministic deployments

EIP-7997 can improve address consistency across participating EVM networks, especially for smart accounts and infrastructure contracts. Confirm that every target chain has the required factory code, that salts and initcode are identical, and that constructor logic does not read chain-dependent values that change the result.

The rollups buyer's guide provides additional context for comparing data availability, settlement, bridge, operator, and upgrade assumptions across L2 systems.

What node operators, validators, and builders should test

Builder registration and exits

EIP-8282 moves post-fork builder onboarding and exits into dedicated execution-layer request contracts. Operational teams should validate execution-address authorization, BLS-key separation, deposit and top-up records, request fees, queue limits, delayed processing, and safe exit procedures.

Validator churn and slashing behavior

EIP-8061 separates activation, exit, and consolidation capacity. Current parameters aim for much faster exit and consolidation processing while maintaining weak-subjectivity safety. EIP-8045 filters slashed validators out of proposer selection to reduce guaranteed missed slots during recovery from a mass-slashing event.

Staking dashboards, queue estimates, custody procedures, validator lifecycle automation, and risk models should update only after confirming the final consensus parameters.

How to verify application behavior after activation

A successful fork does not mean every application integration is correct. Teams need post-activation evidence from their own flows.

Choose representative transactions

Prepare known transactions for ETH transfers, ERC-20 actions, contract calls, EIP-7702 flows, access lists, deployments, state creation, storage clearing, bridge actions, rollup settlement, and sponsored transactions. Record expected balances, logs, state changes, and gas ranges.

Decode, trace, and compare

Use the TokenToolHub Transaction Decoder to inspect post-fork calldata, token movements, approvals, nested calls, fee fields, and receipt outcomes. Compare the decoded behavior with pre-fork test cases and the application's intended action.

Watch for presentation errors

A wallet or indexer may display a new ETH-transfer log and an internal trace as separate activities even when they represent one movement. A gas estimator may use a legacy intrinsic floor. A deployment dashboard may reject a large but valid contract. Treat these as integration issues until the underlying chain data shows otherwise.

Dated Glamsterdam change log

This change log separates historical planning milestones from the current activation status. It should be updated when the scheduled EIP set, public testnet dates, client releases, or mainnet timestamp changes.

Glamsterdam pre-fork checklist

How to monitor Glamsterdam without spreading stale information

Use EIP-7773 for the current fork scope and activation table. Use individual EIPs for normative technical behavior. Use Ethereum Foundation protocol announcements for public testnet and mainnet coordination. Use client release pages for exact software versions.

Roadmap pages are valuable for explanation and target windows, but a target quarter is not a timestamp. Meeting summaries are valuable for progress and unresolved issues, but a discussed parameter is not final until it appears in the accepted specification and compatible releases.

Every production note should include an as-of date. When a value changes, update the changelog rather than silently rewriting history. This is especially important for gas constants, builder collateral, queue limits, recommended gas limits, and activation times.

How Glamsterdam continues Ethereum's post-Merge UX path

Ethereum's recent upgrades increasingly connect protocol capacity with user experience. EIP-7702 introduced a path for EOAs to use delegated account logic, but it also created new wallet, authorization, and gas-accounting responsibilities. Glamsterdam builds around that environment by repricing delegated state more explicitly and making simple transaction costs more resource-aware.

The post-Merge Ethereum UX and EIP-7702 guide explains how delegation changes the account model. Glamsterdam does not replace that design. It adjusts the block, gas, and state foundations that must support increasingly capable accounts at higher throughput.

Conclusion

The Ethereum Glamsterdam upgrade is best understood as a coordinated L1 scaling package. ePBS gives the protocol more time and stronger rules around builder-proposer coordination. BALs give execution clients the state-dependency map needed for parallel reads, validation, state-root work, and new sync paths. Gas repricing protects the network from underpriced data, state creation, state access, and refund-based block-limit distortion.

The upgrade also improves application and operational details: larger contract limits, a deterministic factory, standard ETH-transfer logs, a slot-number opcode, deeper-stack instructions, safer creation edge cases, improved validator churn, slashed-proposer filtering, and dedicated builder requests.

What it does not provide yet is a final activation timestamp. Q4 2026 is the current target, while EIP-7773's activation table remains empty. Teams should use the remaining time to remove fixed gas assumptions, update indexing, test state-heavy and data-heavy flows, validate toolchain support, rehearse node upgrades, and compare contract changes. After activation, use Transaction Decoder for observed transaction behavior and Smart Contract Diff for version-level review rather than assuming a successful network fork automatically validates every application.

Frequently asked questions

References and further learning

• EIP-7773: Glamsterdam hard-fork meta specification
• Ethereum.org: Glamsterdam upgrade guide
• Ethereum.org: Protocol roadmap
• Ethereum.org: Building on Ethereum in 2026
• EIP-7732: Enshrined Proposer-Builder Separation
• EIP-7928: Block-Level Access Lists
• EIP-8037: State Creation Gas Cost Increase
• EIP-8038: State-access gas cost update
• EIP-8261: Gas Limit Schedule
• Ethereum Foundation: Soldøgn interoperability recap

Protocol specifications, scheduled features, gas parameters, client requirements, and activation dates can change before mainnet. Verify current official sources and client releases before making production decisions.