# Ethereum Glamsterdam: practical changes for developers and users

**Research date:** 30 September 2026. **Report prepared:** 1 October 2026 (Asia/Hong_Kong). This is a September 30 evidence snapshot; it has not been refreshed for October 1.

**Research question:** As of the research date, what practical changes should Ethereum’s Glamsterdam upgrade bring to developers and end users?

## Plain-language overview

Glamsterdam changes how Ethereum builds blocks, verifies their transactions, and charges for creating and using its database. Its main promise is more sustainable capacity on Ethereum mainnet: validators get more time to check transaction data, and clients get a map of the state changes that can support parallel processing. It also adds useful developer features, including ETH transfer logs, larger contracts, a slot-number instruction, and a shared deterministic deployment factory. These are foundations for scaling, rather than a guarantee that every transaction becomes cheaper or confirms faster. [Ethereum Foundation announcement](https://blog.ethereum.org/2026/09/17/glamsterdam-testnet-announcement), [upgrade overview](https://ethereum.org/roadmap/glamsterdam/).

The most immediate application concern is gas repricing. Creating accounts, storage slots, and contract code becomes more expensive in gas units. Ethereum separately meters execution and state creation, allowing each resource to use block capacity more effectively. Wallets, RPC services, bundlers, and contracts that assume fixed gas costs need testing. Some users may see cheaper execution because of increased capacity; others may pay more for state-heavy operations. The ETH price of an operation also depends on the fee market. [EIP-8037](https://eips.ethereum.org/EIPS/eip-8037), [repricing impact guide](https://blog.ethereum.org/2026/08/24/glamsterdam-repricing-testing).

**Current stage:** development and public experimentation on Platåberget, with the Sepolia activation scheduled for **6 October 2026, 13:53:36 UTC**, epoch **353024**, slot **11296768**. **Hoodi and mainnet dates are not agreed.** The official roadmap targets **Q4 2026** for mainnet. Glamsterdam combines **Gloas**, the consensus upgrade named after a star, and **Amsterdam**, the execution upgrade named after the 2022 Devconnect host city. [Announcement and activation table](https://blog.ethereum.org/2026/09/17/glamsterdam-testnet-announcement), [deployment record](https://github.com/ethereum/pm/blob/master/glamsterdam-pm.md), [roadmap](https://ethereum.org/roadmap/glamsterdam/).

## EIP comparison table

“Scheduled” below means agreed intent to include, subject to unforeseen issues before activation. It does not mean already active on mainnet. All 18 entries are independently listed in the current [EIP-7773 fork meta-record](https://eips.ethereum.org/EIPS/eip-7773) and the [EF testnet announcement](https://blog.ethereum.org/2026/09/17/glamsterdam-testnet-announcement). Individual document status is **Review**, except EIP-8246, which is **Last Call**. Document maturity and fork inclusion are separate concepts.

| Layer | EIP and current title | Practical change | When benefits reach users |
|---|---|---|---|
| Consensus | [7688 — Forward compatible consensus data structures](https://eips.ethereum.org/EIPS/eip-7688) | Stable proof layouts across future compatible changes | Verifier migration first; reduced maintenance later |
| Consensus | [7732 — Enshrined Proposer-Builder Separation](https://eips.ethereum.org/EIPS/eip-7732) | Protocol handles builder commitments and proposer payments; separates validation duties | New rules at activation; scaling depends on clients and capacity decisions |
| Consensus | [8045 — Exclude slashed validators from proposing](https://eips.ethereum.org/EIPS/eip-8045) | Avoids assigning future proposals to known slashed validators | Mainly during slashing/recovery events |
| Consensus | [8061 — Increase exit and consolidation churn](https://eips.ethereum.org/EIPS/eip-8061) | More exit and consolidation capacity; activation cap retained | Queue-dependent improvement after activation |
| Cross-layer | [8282 — Builder Execution Requests](https://eips.ethereum.org/EIPS/eip-8282) | Dedicated builder deposit/top-up and exit contracts | Builder tooling adoption and correct pre-fork deployment |
| Execution | [2780 — Resource-based intrinsic transaction gas](https://eips.ethereum.org/EIPS/eip-2780) | Replaces flat base with resource-sensitive charges | Direct, with updated estimators |
| Execution | [7708 — ETH transfers emit a log](https://eips.ethereum.org/EIPS/eip-7708) | Receipt logs for specified ETH transfers, including internal calls | Indexer, exchange and wallet adoption |
| Execution | [7778 — Block Gas Accounting without Refunds](https://eips.ethereum.org/EIPS/eip-7778) | Refunds no longer create extra block execution capacity | Direct resource protection; user refunds preserved |
| Execution | [7843 — SLOTNUM opcode](https://eips.ethereum.org/EIPS/eip-7843) | Contracts can read the consensus slot | New contract/toolchain adoption |
| Execution | [7928 — Block-Level Access Lists](https://eips.ethereum.org/EIPS/eip-7928) | Enforced map of accesses and post-transaction state values | Client parallelism and sync adoption |
| Execution | [7954 — Increase Maximum Contract Size](https://eips.ethereum.org/EIPS/eip-7954) | Runtime code 24→64 KiB; initcode 48→128 KiB | New deployments and compatible tooling |
| Execution | [7976 — Increase Calldata Floor Cost](https://eips.ethereum.org/EIPS/eip-7976) | Calldata floor becomes 64 gas per byte | Direct; data-heavy transactions may cost more |
| Execution | [7981 — Increase Access List Cost](https://eips.ethereum.org/EIPS/eip-7981) | Transaction access-list bytes receive a surcharge | Direct; transaction construction must adapt |
| Execution | [7997 — Deterministic Factory Contract](https://eips.ethereum.org/EIPS/eip-7997) | Requires canonical CREATE2 factory availability | Application adoption and other-chain support |
| Execution | [8024 — Backward compatible SWAPN, DUPN, EXCHANGE](https://eips.ethereum.org/EIPS/eip-8024) | More flexible stack instructions | Compiler adoption and redeployment |
| Execution | [8037 — State Creation Gas Cost Increase](https://eips.ethereum.org/EIPS/eip-8037) | Higher state charges and separate state-gas metering | Direct repricing; ecosystem accounting migration |
| Execution | [8038 — State-access gas cost update](https://eips.ethereum.org/EIPS/eip-8038) | Resource-based access and write pricing | Direct; fixed-gas contracts may need fixes |
| Execution | [8246 — Remove SELFDESTRUCT Burn](https://eips.ethereum.org/EIPS/eip-8246) | Preserves remaining balance in same-transaction destruction cases | Direct mainnet semantics; separate L2 migrations |

The fork also records five networking companions and two informational EIPs. They are covered separately below; they should not be presented as seven additional mandatory EVM rule changes.

## Scope, timing and evidence labels

**Confirmed fact** means inspected specifications, agreed scope records, or release content supports the statement. **Measured outcome** means a source describes observations or a benchmark, with its conditions. **Expected benefit** is a design consequence whose realized magnitude is not established. **Projection** or **author claim** is explicitly attributed and is not treated as a measured mainnet result.

[EIP-7723](https://eips.ethereum.org/EIPS/eip-7723) distinguishes Proposed (PFI), Considered (CFI), Scheduled (SFI), Declined (DFI), and Included. SFI signals strong intent and maturity, but can be reversed. Included follows activation. The meta-EIP itself is Review. Review does not establish activation, and Draft does not prevent a proposal being implemented experimentally.

The current meta-record lists **18 scheduled protocol EIPs**, **5 networking EIPs**, and **2 informational EIPs**. [Forkcast](https://forkcast.org/upgrade/glamsterdam/) reports **zero PFI and zero CFI** for Glamsterdam. Scope is therefore substantially settled, with remaining specification, readiness and deployment questions. Forkcast describes Hoodi on October 27 as proposed, to be confirmed October 8; the authoritative deployment table still says TBD. October 27 is not an agreed activation date.

Publication metadata needs care: the EF testnet announcement has September 17 in its URL, but its inspected body says **posted September 28**. The ethrex v28 release body says **September 29**, although extraction metadata incorrectly associated it with the October 6 activation time. This report uses body dates and distinguishes announcement dates from fork dates.

## Implementation and testing: what is actually established

The [devnet-11 specification](https://notes.ethereum.org/@ethpandaops/glamsterdam-devnet-11) includes the scheduled bundle and supporting changes, referencing consensus-specs **v1.7.0-beta.0** dated September 4 and execution fixtures **tests-glamsterdam-devnet@v8.1.4** dated September 3. It describes a happy-path fork-transition network for ecosystem testing, including Lido, Optimism and Arbitrum, with adversarial testing left to devnet-8. A planned matrix or fixture release is evidence of testing infrastructure, not proof that every client passed every scenario.

Its client-readiness table is explicitly a **September 8 snapshot**, containing failures, incompatible branches and open fixes. Do not treat those as September 30 release verdicts. Later [ethrex v28.0.0](https://github.com/lambdaclass/ethrex/releases/tag/v28.0.0) and [Prysm v7.2.0](https://github.com/OffchainLabs/prysm/releases/tag/v7.2.0) explicitly schedule Sepolia and describe substantive fixes. Ethrex lists BAL validation, block gas enforcement, total transaction gas caps and snap/2. Prysm lists progressive merkleization, Gloas validator/builder interfaces, signing support and a builder circuit breaker.

The EF announcement lists Sepolia releases for Lodestar 1.49.0, Nimbus 26.9.0, Prysm 7.2.0, Teku 26.9.1; and Besu 26.9.0, ethrex 28.0.0, Erigon 3.7.0, Geth 1.17.6, Nethermind 2.0.0 and Reth 2.7.0. Lighthouse and Grandine rows were blank. Only ethrex and Prysm release bodies were inspected independently. No mainnet-ready certification or complete per-EIP/per-client pass matrix is claimed.

**Common implementation status for the detailed entries below:** each scheduled EIP is in the agreed bundle and the devnet-11 list; additional individual evidence is noted where available. This establishes implementation/testing progress, not universal correctness or successful future Sepolia activation.

## Consensus layer: detailed scheduled EIPs

### EIP-7688 — Forward compatible consensus data structures

**Mechanism and problem.** Consensus objects use SSZ Merkle trees, which let contracts and off-chain verifiers prove individual facts about beacon-chain state. Adding unrelated fields or changing list capacities can currently change proof paths. This EIP adopts ProgressiveContainer and progressive list/bitlist forms for evolving objects, assigning stable field indices. Serialization remains unchanged; Merkleization changes. It retains immutable structures where conversion would create overhead or unnecessary disruption. [Specification](https://eips.ethereum.org/EIPS/eip-7688).

**Practical effects.** A staking application proving that a validator is unslashed must migrate its proof verifier once, then should need fewer updates when unrelated fields change in subsequent compatible forks. Bridges, light clients and hardware-wallet verifiers must distinguish pre-fork and post-fork proof shapes. Historical proofs still require the historical scheme. Ordinary wallets sending transactions gain no new button or immediate fee discount. Node operators receive the change through consensus-client upgrades; Prysm's release explicitly implements progressive merkleization.

**Tradeoffs and arrival.** This is a one-time breaking proof transition intended to reduce future maintenance. Stable indices require strict rules about appending fields and never reusing a removed field for a different type. Progressive structures do not mean unlimited network messages: separate runtime and message-size limits remain essential. No measured user-facing speedup is established. [EIP-7688 compatibility and security](https://eips.ethereum.org/EIPS/eip-7688), [Prysm release](https://github.com/OffchainLabs/prysm/releases/tag/v7.2.0).

### EIP-7732 — Enshrined Proposer-Builder Separation (ePBS)

**Mechanism and problem.** Today proposers often depend on external relay middleware for an exchange: reveal a builder's block in return for payment. ePBS puts commitments, builder balances and proposer payments into consensus. A proposer publishes a signed builder commitment; the builder reveals the execution payload separately. A Payload Timeliness Committee (PTC) votes on timely revelation and blob availability. Consensus agreement and execution validation are separated in time. Builders can also use trusted off-protocol payment arrangements; ePBS does not require every service in the transaction supply chain to disappear. [Specification](https://eips.ethereum.org/EIPS/eip-7732).

**Practical effects.** Validators gain new PTC duties and must update beacon nodes, validator clients, signers, proposer preferences and builder integration. Builders need the new bidding, funding and reveal lifecycle. Pools and monitoring systems must handle a consensus block separately from its execution payload, including non-revelation and invalid payloads. RPC and application infrastructure must review assumptions that a consensus head always implies immediately usable transaction execution. Smart-contract code normally does not need to opt into ePBS.

**End-user example and arrival.** Before, a proposer's payment exchange relies on a relay; after, the protocol can debit the builder's stake and arrange proposer payment. For a user swapping tokens, the primary expected benefit is a network better able to carry and validate larger payloads. It does not establish a reduction in sandwiching, faster finality, or a numerical MEV reduction. The official overview describes a propagation window expanding from approximately 2 seconds to 9 seconds; that is a protocol timing explanation, not a nine-second confirmation guarantee or a measured throughput multiplier. Capacity increases and client optimizations determine realized gains. [Overview](https://ethereum.org/roadmap/glamsterdam/).

**Security and tradeoffs.** The specification identifies a free-option risk: a builder may find withholding a committed payload profitable, causing missed execution opportunities. It also describes builder exposure to colluding proposers/attesters and PTC adversaries. More actors, partial blocks and failure modes make implementation substantially more complex. Prysm's release includes a circuit breaker for builders winning auctions without revealing. Researcher Barnabé Monnot also reports an expected hit to the best-case Fast Confirmation Rule latency under ePBS; this is discussed below as an attributed design concern, not a measured activation outcome. [EIP-7732 security](https://eips.ethereum.org/EIPS/eip-7732), [Prysm release](https://github.com/OffchainLabs/prysm/releases/tag/v7.2.0).

### EIP-8045 — Exclude slashed validators from proposing

**Mechanism and problem.** Slashed validators can currently remain eligible for proposer selection even though their proposed blocks are invalid. This creates avoidable missed slots, especially after mass slashings. The new selection process filters active validators to those not slashed. Existing proposer lookahead protects the already-computed schedule from being reshuffled by a later slashing. [Specification](https://eips.ethereum.org/EIPS/eip-8045).

**Practical effects.** Consensus clients and validator-duty infrastructure must use the updated selection rules. Applications and wallets usually require no migration. During recovery from a large slashing event, users should encounter fewer future slots assigned to participants already known to be unable to produce valid blocks. This does not fix all network outages or retroactively repair a frozen lookahead window.

**Arrival, testing and tradeoffs.** The rule acts directly at activation, with its material benefit conditional on slashings. The specification calls for testing non-selection, a complete lookahead despite slashings, and preservation of existing lookahead. No numerical reduction in missed slots is supported. Randomness and balance weighting among eligible validators remain; this is a hard-fork change to consensus selection.

### EIP-8061 — Increase exit and consolidation churn

**Mechanism and problem.** Exit congestion can leave stakers waiting a long time to leave, while slow consolidations delay shrinking the number of validator entries. The EIP restores stake-proportional exits without the activation cap, increases exit churn, and gives consolidation its own independent limit. Activation remains capped at 256 ETH per epoch. The exit quotient becomes 32768 and consolidation quotient 65536. [Specification](https://eips.ethereum.org/EIPS/eip-8061).

**Practical effects.** Staking applications and dashboards must update queue estimates and distinguish entry, exit and consolidation capacity. Operators can consolidate eligible balances more quickly and gain more exit headroom. A staker joining a heavily congested exit queue may receive an earlier exit assignment than under the old limits, but cannot assume immediate liquidity: queue demand, already assigned exits and withdrawal mechanics still matter. Wallets unrelated to staking see little direct change.

**Estimates and security.** The specification describes approximately 4× exit churn compared with the then-current cap and approximately 2× consolidation churn, dependent on total stake. These are parameter-based comparisons, not measured reductions in each user's waiting time. Its weak-subjectivity calculation shortens the estimated safe checkpoint period from about 15.7 days to about 7 days under the stated assumptions. Operators, checkpoint services and long-offline nodes must take the shorter period seriously. Faster consolidation supports later faster-finality work; it does not deliver that future upgrade at Glamsterdam activation. [EIP-8061 rationale and security](https://eips.ethereum.org/EIPS/eip-8061).

### EIP-8282 — Builder Execution Requests (cross-layer)

**Mechanism and problem.** ePBS needs builder registration, top-ups and exits. Dedicated execution-layer request contracts separate the builder lifecycle from validator deposits and exits. Requests are queued, drained by system calls and committed through the EIP-7685 request bus. Builder exits can be authorized by the execution address controlling stake, giving a path independent of the hot bidding key. Builder and validator registries become separately keyed. [Specification](https://eips.ethereum.org/EIPS/eip-8282).

**Practical effects.** Builder operators and funding tools must use the dedicated contracts, correct byte encodings, signing domains and request fees. Deposits contain a proof of possession; incorrect first-deposit signatures can cause stake to be forfeited. A cold stake-control address can request an exit instead of relying solely on a hot BLS bidding key. General-purpose dapps and wallets need changes only if exposing builder management. End users benefit indirectly from a safer, explicitly bounded builder lifecycle.

**Arrival and security.** The current specification requires deployment transactions before the fork and invalidates active-fork blocks if the necessary contracts are missing. Addresses remain sensitive to final reference-bytecode changes, so integrations must use finalized deployment guidance. Per-block dequeue caps of 64 deposits and 16 exits bound processing; demand-responsive fees discourage queue spam. Skipping validator activation churn does not skip the builder's finality-based activation condition. Devnet-11 includes the request contracts, but this research did not independently audit their deployed code or complete an address/bytecode verification.

## Execution layer: detailed scheduled EIPs

### EIP-2780 — Resource-based intrinsic transaction gas

**Mechanism.** A transaction's flat intrinsic base becomes a composition of resource costs. State-independent work is checked at transaction admission; state-dependent costs such as creating a recipient account are charged at runtime. This prevents cheap ordinary transfers from bypassing the new-account charge in EIP-8037. [Specification](https://eips.ethereum.org/EIPS/eip-2780).

**Before and after.** The current examples specify a self-transfer at 12000 intrinsic gas; a zero-value transaction to a distinct EOA at 15000; and a value transfer to an existing EOA at 21000. Funding a nonexistent EOA incurs 21000 execution gas plus 183600 state gas at the current CPSB. Delegated-account execution and calldata can add further costs. These are specification examples, not whole-transaction ETH-price forecasts. A transaction passing intrinsic validity but lacking runtime gas can be included, fail out of gas, and still incur fees.

**Who adapts.** Wallets, RPC estimators, relayers, transaction validators and account-abstraction tools must stop assuming every plain transfer costs 21000 or that every insufficient account-creation budget is rejected before inclusion. Contract developers should test funding, deployment and EIP-7702 authorizations. Nodes implement the pre-execution ordering and rollback rules. The behavior applies directly at activation; user benefit depends on updated software. Historical “reduce intrinsic gas” descriptions are incomplete: existing-account transfers and fresh-account funding differ sharply.

### EIP-7708 — ETH transfers emit a log

**Mechanism.** Specified nonzero transfers between different accounts emit an ERC-20-shaped Transfer log from the system address `0xfffffffffffffffffffffffffffffffffffffffe`: top-level transfers, CALL, CREATE/CREATE2 endowments and SELFDESTRUCT transfers. Rolled-back transfers do not become durable logs. Fee payments, base-fee burning and consensus withdrawals are deliberately excluded. [Specification](https://eips.ethereum.org/EIPS/eip-7708).

**Practical effects.** Exchanges and explorers can detect a smart-wallet ETH deposit through receipts instead of relying exclusively on execution tracing. Wallets, indexers and accounting services must recognize the system emitter, process ordering correctly and avoid double-counting transfers already detected through traces. An ETH log is not an arbitrary token contract event simply because its signature matches ERC-20 Transfer. Applications comparing receipt/log indices or simulated traces should test the new records; ethrex's latest release contains log-index corrections.

**Arrival and limitations.** Logs appear directly for qualifying post-fork transactions; simpler deposit UX requires service adoption. This is not a complete log of every ETH balance change and does not backfill history. Average receipt volume rises, strengthening the case for paginated receipt exchange. The EIP provides explicit test categories covering reverts, delegated accounts, creation and fork boundaries; no quantified deposit-speed improvement is established.

### EIP-7778 — Block Gas Accounting without Refunds

**Mechanism.** Storage-clearing refunds still reduce what the user pays, but no longer reduce the work counted against block capacity. Builders cannot use refunds to pack more gross computation than the block gas limit intends. The specification's historical example is block 20878522: 28.5M net gas plus 4.01M refunds represented 32.51M gross work. That is evidence of the accounting mismatch, not a benchmark for future throughput. [Specification](https://eips.ethereum.org/EIPS/eip-7778).

**Practical effects.** Builders update packing algorithms; infrastructure distinguishes user receipts/refunds from block resource accounting. A user clearing storage retains the qualifying refund while the block accounts for the full work. Apps have little EIP-specific code migration, but gas telemetry must not equate billed gas with available block capacity. Node operators gain a firmer computational bound. Activation directly closes this resource/DoS loophole; refund-heavy transactions can fit differently in blocks, and there is no guaranteed fee reduction.

### EIP-7843 — SLOTNUM opcode

**Mechanism.** New opcode `0x4b` returns the consensus slot number for the current block at a specified cost of 2 gas. Slot information is carried through the block header and Engine API. Previously, contracts either derived slots from timestamps with hardcoded timing assumptions or supplied and proved beacon information. [Specification](https://eips.ethereum.org/EIPS/eip-7843).

**Practical effects.** Staking, oracle and scheduling contracts can use an explicit slot value. Compilers, assemblers, EVM libraries, simulators and proof systems must support the instruction and header/API extensions. Node operators need matched CL/EL versions. Wallets benefit only through applications using it. Slots are not synonymous with execution block numbers: missed slots remain possible.

**Arrival and security.** New contracts can adopt it after activation; existing timestamp arithmetic is not automatically rewritten. It prepares applications for possible later slot-duration changes but does not itself shorten slots. The tiny opcode gas cost is a rule, not an estimate of complete application savings. Applications must still choose sound timing and finality assumptions.

### EIP-7928 — Block-Level Access Lists (BALs)

**Mechanism.** Builders supply an enforced record of accessed accounts/storage and post-transaction state changes, committed by a hash in the execution header. Clients can prefetch disk data, validate transactions in parallel, compute roots in parallel and apply state diffs during suitable synchronization paths. This differs from optional transaction access lists: it records actual accesses across the block, including system activity. [Specification](https://eips.ethereum.org/EIPS/eip-7928).

**Practical effects.** Client and infrastructure developers implement BAL generation, validation, storage, Engine API transport and peer retrieval. Contract authors do not submit BALs manually, and existing state dependencies still constrain execution. For example, independent transfers can be checked with parallel state access, while sequential trades touching one pool must preserve the original transaction semantics. Wallets normally keep submitting ordinary transactions. New-node synchronization can use recorded changes where its trust/verification model permits; a header hash commitment alone is not proof that arbitrary advertised changes are semantically valid.

**Evidence and limits.** The EIP cites approximately 72.4 KiB average compressed BAL size in its 60M-block-gas-limit analysis and historical disjoint-storage estimates of 60–80% of transactions. These are workload-specific observations, not guaranteed independence or fixed sizes at 200M. The report did not independently reproduce that analysis. Added data, validation and retention overhead trade against faster state access. Spurious read entries can force unnecessary prefetch work, so bounded item counts and valid-block-safe early rejection matter.

**Arrival and testing.** BAL commitments become mandatory with activation; performance depends on client optimization. Ethrex v28 fixes validation around system calls, withdrawals and requests as well as oversized code changes, demonstrating that implementation details are still consequential. Networking EIPs 8159/8189 deliver historical BALs and use them for sync. The legacy-account interaction motivating EIP-8253 remains an explicit concern below.

### EIP-7954 — Increase Maximum Contract Size

**Mechanism.** Runtime code rises from **24576 to 65536 bytes** (24 to 64 KiB); initcode rises from **49152 to 131072 bytes** (48 to 128 KiB). [Specification](https://eips.ethereum.org/EIPS/eip-7954).

**Practical effects.** A developer whose compiled contract exceeds 24 KiB can deploy a larger single contract rather than splitting functionality solely to satisfy the old size limit. Compiler/deployment checks, explorers, verifiers, RPC transaction admission, audit tools and zkEVM implementations must support the new bounds. Existing contracts do not grow automatically. Wallet deployment flows can enable larger smart accounts after their tools update.

**Costs and tradeoffs.** Larger contracts are allowed, not made cheap: EIP-8037 increases state-byte charges. More code also creates loading, propagation and auditing burdens. Splitting may remain sensible for security and maintainability. Rollups must independently support the limits; a 64 KiB mainnet deployment can fail on a chain retaining 24 KiB. The exact size change is confirmed; no universal deployment-cost or runtime-efficiency gain is established.

### EIP-7976 — Increase Calldata Floor Cost

**Mechanism.** The minimum calldata accounting becomes **64 gas per byte for both zero and nonzero bytes**. Ordinary byte pricing and execution interact through a floor rather than blindly adding 64 to every executed byte cost. The floor constrains data-heavy blocks as capacity rises. The standalone formula retains older base constants; combined fork implementations must compose it with EIP-2780 and other repricings. [Specification](https://eips.ethereum.org/EIPS/eip-7976).

**Practical effects.** Data-heavy publishing, batches and some bridges may pay more gas; execution-heavy transactions already above the floor may see less incremental impact. Wallets, SDKs, estimators and builders update admission and floor handling. Contract authors should compare encoded-data strategies. The direct change protects node propagation and resource budgets; it is not a blanket transaction discount.

**Mainnet versus rollups.** A rollup posting calldata to L1 is directly exposed to this L1 charge. Blob publication uses a different resource and fee market, so one cannot translate this floor into the same increase for blob-based batches. Rollup users see whatever costs and savings the operator's batching and pricing pass through.

### EIP-7981 — Increase Access List Cost

**Mechanism.** Transaction access-list bytes receive a flat **64 gas/byte surcharge**: 1280 per listed address and 2048 per storage key, in addition to access prepayment and other intrinsic/floor calculations. This closes a way to evade data-size pricing through access lists. EIP-8038 updates the underlying access costs too; EIP-7981's displayed older 2400/1900 constants are not the full combined fork schedule. [Specification](https://eips.ethereum.org/EIPS/eip-7981), [EIP-8038](https://eips.ethereum.org/EIPS/eip-8038).

**Practical effects.** Wallets, RPC `eth_createAccessList` consumers and advanced transaction builders must recompute whether an optional access list helps. A list that once saved a small access charge can become uneconomic after its data surcharge. Ordinary users need updated construction/estimation; smart contracts generally need no access-list-specific rewrite. Builders and node operators gain a more consistent resource bound at activation. This EIP concerns transaction lists, not a request for users to generate EIP-7928 BALs.

### EIP-7997 — Deterministic Factory Contract

**Mechanism.** The specification formalizes availability of the existing CREATE2 factory at `0x4e59b44847b379578588920cA78FbF26c0B4956C`, with prescribed runtime code and nonzero nonce. Identical factory, salt and initcode yield identical contract addresses. The current title is “Contract,” not older “Predeploy” wording. It permits ordinary deployment or genesis inclusion; clients must not check factory existence at the fork boundary. [Specification](https://eips.ethereum.org/EIPS/eip-7997).

**Practical effects.** Multi-chain apps and smart-wallet teams can reduce chain-specific address configuration. A wallet account can be intentionally deployed at the same address on compatible chains; existing accounts with different addresses do not merge automatically. Deployment tooling must ensure factory code and inputs match. Mainnet already has the factory, so much of the benefit is a durable ecosystem guarantee and support on new chains.

**Migration and security.** State repricing can make old presigned factory deployment transactions fail on new networks. Chains must arrange suitable deployment/genesis state; an irregular state transition is outside this EIP's scope. A common address does not imply common balances, ownership configuration or safe cross-chain signing. Rollups must adopt the factory requirement independently. Benefits require developer adoption; no numerical gas saving is established.

### EIP-8024 — Backward compatible SWAPN, DUPN, EXCHANGE

**Mechanism.** New immediate-operand stack instructions access deeper stack entries and exchange values more flexibly. The specified cost is 3 gas per instruction. The encoding deliberately avoids changing existing JUMPDEST analysis, preserving valid historical jump targets even where arbitrary data is embedded in code. [Specification](https://eips.ethereum.org/EIPS/eip-8024).

**Practical effects.** Compiler authors can generate better code for complex stack usage, potentially reducing memory spilling or awkward instruction sequences. Assemblers, disassemblers, auditors, debuggers, simulators and proof systems need correct decoding and invalid-immediate handling. Existing deployments do not acquire optimized bytecode; applications must compile/deploy with support. Wallet users benefit indirectly through future contracts. New bytecode needs compatible EVM targets on every destination chain.

**Tradeoffs and timing.** The instructions broaden compiler choices rather than removing every “stack too deep” issue. Static immediate operands support analysis; exceptional-halt and stack-boundary behavior require tests. No quantified whole-contract gas improvement was established, and the change does not require adopting EOF.

### EIP-8037 — State Creation Gas Cost Increase

**Mechanism.** State creation is priced by cost per state byte, **CPSB = 1530**, and metered separately from execution. The current accounting assigns 120 bytes to a new account and 64 to a new storage slot. Users pay both dimensions; block fullness and base-fee updating use the bottleneck dimension rather than simply summing execution and state usage. A reservoir model retains one transaction gas-limit field while separating budgets. [Specification](https://eips.ethereum.org/EIPS/eip-8037).

**Concrete charges.** At that CPSB, new-account state gas is **183600**, a new-slot state charge **97920**, and code deposition **1530 per byte**, before accompanying execution charges. These are specified component costs. They are not complete deployment receipts or fixed ETH prices. The EIP's illustrative ETH costs assume 0.08 Gwei from its cited historical fee period; this report does not assume that fee at activation.

**Practical effects.** Dapps creating many new accounts/storage entries should redesign only after measuring actual workflows. Wallets and RPCs must estimate both dimensions and support total `tx.gas` above the old execution-only cap when appropriate. The EIP retains the EIP-7825 execution cap, while specifying a total gas-limit maximum of **2^32−1**; this does not mean a transaction can execute that much EVM computation. Builders need two-resource packing; receipt and block-gas dashboards need updated interpretations. Node operators should gain a sustainable resource envelope rather than an assurance their database stops growing.

**Compatibility and security.** `GAS`/`gasleft()` sees execution gas, not the reservoir, and refills can make gas-left increase during a frame or across child-frame merging. Subtracting two readings can therefore produce a negative value, revert under checked arithmetic, or wrap under unchecked arithmetic. ERC-4337 bundlers/EntryPoint accounting cannot safely assume these deltas capture total state charges. Fixed-gas deployments and immutable gas-sensitive contracts require attention. The EIP itself says some deployed metering contracts cannot be fixed. The September devnet changed merge-time repayments; current estimator and trace behavior matters.

**Estimates and limitations.** Its target is approximately **120 GiB/year** average new state at a **150M reference gas limit**, calibrated from observed activity. The cited January 2026 Geth state size was about 390 GiB, with daily new state rising from approximately 105 to 326 MiB after a 30M→60M limit change. The EIP explicitly notes that behavioral response was nonlinear. Extrapolated growth at 200M is a model, not a guaranteed outcome or a hard storage cap. More sophisticated multidimensional packing can advantage large builders. Fees for state creation increase directly in gas units; lower market gas prices are uncertain.

### EIP-8038 — State-access gas cost update

**Mechanism.** Accessing existing state and writing it are priced separately from creating state. The current table sets cold account access **2600→3000**, keeps cold storage access **2100** and warm access **100**, introduces an account-write charge **9000**, and sets storage-write **10000**. CREATE access combines account access/write at **12000**. Access-list prepayments become **2900/address** and **2000/key**, before EIP-7981's byte surcharge. Composite old/new charges need care: the new write constants are not simply surcharges on top of every legacy composite cost. [Specification](https://eips.ethereum.org/EIPS/eip-8038).

**Practical effects.** Contract developers should test SSTORE-heavy paths, value-bearing calls, EXTCODESIZE/EXTCODECOPY, delegations and creation. Wallets/RPCs update estimates; applications with a frontend-supplied low gas limit may often recover by increasing it. Contracts forwarding a fixed stipend or branching on gas-left can fail even with a larger outer limit. Users should see normal workflows through updated software, but some legacy applications can degrade. Node operators gain pricing more aligned with contemporary database workloads.

**Measured basis and limits.** The specification describes synthetic blocks, Benchmarkoor timings, per-client regression, conservative worst-client selection, and BAL-optimized implementations, anchored at **100M gas/second**. Storage tests include a bespoke 10 GB storage contract. This is operation-pricing evidence under benchmark conditions, not a chain-wide sustained transaction rate. The research did not independently reproduce timings or establish representative hardware results for every operator. Earlier broad wording suggesting all SLOAD charges increase conflicts with the current table, which leaves cold storage reads unchanged.

**Arrival.** Costs change at activation. Benefits to sustainable capacity depend on the combined gas-limit and client rollout. The [EF historical replay](https://blog.ethereum.org/2026/08/24/glamsterdam-repricing-testing) establishes compatibility risk; it does not establish that every contract is safe or that everyone pays less.

### EIP-8246 — Remove SELFDESTRUCT Burn

**Mechanism.** Remaining ETH-burn cases are removed for contracts created and destroyed within the same transaction. At finalization, marked accounts have code/storage cleared and nonce reset, but retain any balance. Existing-contract SELFDESTRUCT behavior under EIP-6780 remains unchanged. This is not the removal of EIP-1559 fee burning. [Specification](https://eips.ethereum.org/EIPS/eip-8246).

**Practical effects.** Mainnet applications using rare same-transaction self-burn patterns must stop assuming ETH disappears. Accounting/indexing becomes simpler alongside ETH transfer logs. Ordinary users are unlikely to notice, but preserved balances can become locked or exposed to redeployment. The EIP reports a replay to approximately block 25M finding only **two post-Cancun burns** of this kind and zero finalization burns; that historical sample is not proof no dependency exists.

**Security and rollup migration.** A funded, code-free, zero-nonce account may again be a valid CREATE2 target. With a permissionless factory and public deployment inputs, someone may redeploy code and take the preserved balance. The specification explicitly flags **OP Stack L2ToL1MessagePasser burn()**, which relies on a selfdestructing constructor to remove withdrawn L2 ETH. Chains inheriting that pattern require a separate migration plan before adopting these semantics. L1 activation alone does not silently change every rollup's EVM. The Last Call deadline is November 4, 2026; that maturity milestone is separate from scheduled inclusion and activation timing.

## Supporting networking and informational EIPs

These seven are listed as companions in [EIP-7773](https://eips.ethereum.org/EIPS/eip-7773) and the EF announcement. Their individual documents were inspected and show Review status. They appear in devnet-11, but the observations below do not establish uniform adoption by every client.

| Layer/category | EIP | Main contribution | Adoption condition |
|---|---|---|---|
| EL networking | [7975 — eth/70: partial block receipt lists](https://eips.ethereum.org/EIPS/eip-7975) | Paginated receipts avoid oversized messages | Negotiated peer support |
| EL networking | [8070 — eth/72: Sparse Blobpool](https://eips.ethereum.org/EIPS/eip-8070) | Fetch custody-aligned cells instead of replicating every blob | Client and peer adoption; builders have different needs |
| CL networking | [8136 — Cell-Level Deltas for Data Column Broadcast](https://eips.ethereum.org/EIPS/eip-8136) | Exchange missing cells rather than redundant full columns | Both peers support extension |
| EL networking | [8159 — eth/71: Block Access List Exchange](https://eips.ethereum.org/EIPS/eip-8159) | Fetch historical BALs from peers | Post-Amsterdam headers and available BALs |
| EL networking | [8189 — snap/2: BAL-Based State Healing](https://eips.ethereum.org/EIPS/eip-8189) | Catch up downloaded state through BAL diffs | Post-fork data and snap/2 sync implementation |
| Informational, compute analysis | [7904 — Compute Gas Cost Analysis](https://eips.ethereum.org/EIPS/eip-7904) | Documents why compute repricing is unnecessary | No protocol change |
| Informational, CL configuration | [8261 — Gas Limit Schedule](https://eips.ethereum.org/EIPS/eip-8261) | Optional epoch-based gas-limit preferences | Client support and network/operator configuration |

### EIP-7975 — eth/70: partial block receipt lists

Large blocks can produce receipt lists above common 10 MiB message limits. Peers can request receipts starting at an index and receive a flag indicating an incomplete final list. Before, an oversized block's receipts could obstruct synchronization; after, a supporting client downloads chunks. Indexers, archive services and infrastructure gain more reliable receipt retrieval; contract/wallet APIs do not inherently change. More ETH logs and higher capacity increase its relevance. This networking change can roll out without an EVM hard fork, with older protocol versions negotiated separately. Partial lists cannot be checked against the final receipts root until assembled, so clients must bound receipt counts, per-receipt sizes and total buffered input. No measured sync-time reduction is established. [Specification](https://eips.ethereum.org/EIPS/eip-7975).

### EIP-8070 — eth/72: Sparse Blobpool

EL nodes probabilistically keep full blobs or sample cells aligned with their CL custody assignment. This reduces redundant full replication while retaining a provider backbone. New cell messages and Engine API custody/getBlobs interfaces require coordinated client upgrades. Rollup publishers and builders need reliable complete blob availability; builders are recommended to fetch eagerly, so ordinary-node estimates cannot be applied to them. Wallets and contracts need no direct change. More bandwidth headroom can enable future blob capacity, but the EIP alone sets no guaranteed L2 fee reduction.

The specification models full fetching probability **0.15** and otherwise sampling **1/8**, giving `0.15 + 0.85/8 ≈ 0.256`, approximately a **4× reduction in average blobpool data bandwidth** under its assumptions. It also reports EL bandwidth dominating CL by about 4–5× in cited Fusaka devnets. The reduction is a design estimate for this traffic class, excluding a guarantee about whole-node bandwidth, extra samples, adversarial topology or builder traffic. Provider concentration, unavailable cells, fairness heuristics and custody changes need monitoring. Ethrex's September 9 X release explanation confirms an implementation, but called it a candidate at that time; the later meta-record lists it as a networking companion. [Specification](https://eips.ethereum.org/EIPS/eip-8070), [ethrex September 9 post](https://x.com/ethrex_client/status/2097679510925676903).

### EIP-8136 — Cell-Level Deltas for Data Column Broadcast

Peers exchange cell-availability bitmaps and missing cells through a Gossipsub partial-message extension. If a node already has almost all of a column from its mempool, it requests the missing cells instead of receiving the full column. CL developers and operators gain less duplicate traffic; rollup users benefit indirectly if it helps scale availability. The extension is backward compatible, requires no hard fork, and only helps connections where both peers support it. A pull-based default adds some dissemination latency in return for lower bandwidth, with eager-push policies available. Client-specific implementation and timely peer scoring matter. No measured universal bandwidth or latency improvement is established. [Specification](https://eips.ethereum.org/EIPS/eip-8136).

### EIP-8159 — eth/71: Block Access List Exchange

Peers request BALs by block hash and verify the returned encoding against the header's BAL hash. This supplies historical data for parallel validation and executionless catch-up; normal Engine API delivery alone does not solve historical peer retrieval. Infrastructure must serve or explicitly report unavailable/pruned BALs and manage retention. Users may eventually sync nodes more conveniently through adopting clients; dapps and wallets need no separate transaction feature. The peer capability can coexist with older versions, but the BAL commitment depends on Amsterdam activation. Rate limiting and a recommended 2 MiB response soft limit bound amplification; header-hash checking is essential. No measured sync speedup was established. [Specification](https://eips.ethereum.org/EIPS/eip-8159).

### EIP-8189 — snap/2: BAL-Based State Healing

After downloading a state snapshot, a node currently heals through iterative trie-node retrieval. snap/2 instead obtains the known sequence of BALs, applies diffs in strict block order, and recomputes/verifies the state root. Node operators and infrastructure providers gain a clearer catch-up path, conditional on peers retaining the required lists. Contract developers and ordinary wallets need no direct migration. Reorg recovery may require orphaned BALs; if unavailable, synchronization may have to restart. Hash checks, final-root checks, peer reliability and response limits remain necessary. snap/1 fallback supports older peers. **Ethrex v28 explicitly implements this change**, corroborating its X description; no representative elapsed-time benchmark is claimed. [Specification](https://eips.ethereum.org/EIPS/eip-8189), [release](https://github.com/lambdaclass/ethrex/releases/tag/v28.0.0).

### EIP-7904 — Compute Gas Cost Analysis

This is now **Informational**, recommending **no opcode or precompile gas-cost changes**. Earlier “general gas repricing” descriptions are stale. The analysis benchmarks synthetic EEST blocks through Benchmarkoor on Besu, Erigon, ethrex, Geth, Nethermind and Reth with BAL-enabled optimizations, using regression and a **100M gas/s** anchor. It uses conservative client results and statistical-fit conditions. The conclusion is that examined compute operations do not warrant gas increases at that target, rather than a recommendation to lower their costs by the displayed percentages. The research did not reproduce benchmark hardware/run artifacts. It is not sustained mainnet TPS, network propagation, state-growth or zk-proving evidence. Developers and users have no EIP-specific migration; clients benefit from the underlying optimizations independently. [Current specification and methodology](https://eips.ethereum.org/EIPS/eip-7904).

### EIP-8261 — Gas Limit Schedule

An optional CL config schedule associates epochs with default and recommended maximum gas preferences. It avoids early software upgrades immediately moving gas-limit defaults before a coordinated epoch. Operators can override; the recommendation is **not a consensus ceiling or floor**. Existing gas-limit validity/rate-of-change rules remain. Clients lacking support keep their normal behavior. Wallets do not need to read this config, but gas-limited tooling must handle realized capacity correctly. Benefits depend on adoption, and erroneous scheduled values could propagate widely.

Prysm 7.2.0 release notes say the Sepolia 200M schedule entry landed after the release was cut, so its post-Gloas default remains **60M unless explicitly configured**. Its old `--suggested-gas-limit` does not control post-Gloas preferences. This proves why “fork support” does not mean every client automatically targets 200M. A **200M ambition is not an activation-enforced mainnet minimum**, nor a guaranteed 3× TPS improvement. [Specification](https://eips.ethereum.org/EIPS/eip-8261), [Prysm release instructions](https://github.com/OffchainLabs/prysm/releases/tag/v7.2.0).

## How the changes interact

**Capacity and sustainable operation.** ePBS gives execution/data availability more time outside the consensus hot path. BALs let clients exploit parallel I/O, validation and root work. State creation/access repricing addresses storage and execution bottlenecks that merely raising block limits would aggravate. Refund accounting and calldata/access-list pricing bound work and data. Receipt pagination, sparse blobpool, column deltas and BAL exchange address the networking/sync consequences of larger blocks. The result is a coordinated scaling foundation; actual throughput still depends on workloads, operator resources and gas-limit choices. [EF overview](https://blog.ethereum.org/2026/09/17/glamsterdam-testnet-announcement).

**Application features and resource prices.** Larger contracts plus separate state metering make bigger deployments feasible without lifting the execution-only transaction cap. Their state charges can nevertheless be substantially higher. The deterministic factory supports predictable deployment addresses; new stack instructions need compiler adoption. ETH logs plus removed burn edge cases simplify transfer accounting, while receipt transport handles the resulting data. Stable consensus proof structures plus SLOTNUM reduce future coupling to unrelated fork changes, after required verifier/toolchain updates.

**Mainnet versus rollups.** Mainnet gas, logs, opcode and contract limits change under the L1 fork. Rollups do not automatically inherit those EVM changes. They must update execution/proving systems, transaction accounting and applications on their own schedules. L1 settlement and blob infrastructure improvements can help rollups without changing their user EVM. Blob capacity and fee savings require subsequent configuration, infrastructure and fee-market outcomes. Optimistic withdrawal periods also depend on fraud-proof and censorship-resistance assumptions; Glamsterdam does not itself deliver FOCIL or guarantee shorter exits. EIP-8246's OP Stack burn dependency is an explicit reason to avoid treating L1/L2 compatibility as automatic.

## Authenticated X: expectations and concerns, with context

X supplied original commentary and implementation concerns, not inclusion authority. All posts below were obtained through authenticated xurl, with author/date fields and relevant thread or Article text. Technical assertions were checked against the primary evidence linked above.

- **Paweł Bylica (@chfast), September 1:** asked how ERC-4337 works with state gas, then clarified that ordinary gas inspection cannot observe it. A respondent initially framed this as merely higher cost, then acknowledged the accounting gap. The current EIP-8037 explicitly documents reservoir invisibility and bundler/EntryPoint accounting requirements, so this concern has primary specification support. [Question](https://x.com/chfast/status/2094722263379526084), [clarification](https://x.com/chfast/status/2094739921403568369).
- **Barnabé Monnot (@barnabemonnot), July 16–17**, discussing ePBS with **@katiabanina** and **Michael (@mostlyblocks)**: Monnot distinguishes replacing relay escrow from replacing all relay services. @katiabanina worries about vertical integration and barriers to new builders; @mostlyblocks argues shared merging/propagation infrastructure helps small builders. Monnot treats alternative market structures as exploratory and separately states some proposed services are outside ePBS. These are competing economic expectations, not demonstrated market outcomes. The specification supports protocol fair exchange but does not guarantee deconcentration. [Monnot's functional distinction](https://x.com/barnabemonnot/status/2077845186428711129), [concern](https://x.com/katiabanina/status/2077781787854422332), [counterpoint](https://x.com/mostlyblocks/status/2077835684874801519), [exploratory qualification](https://x.com/barnabemonnot/status/2078127476526497825).
- **Monnot, August 2, Article “Ethlabs is online. Week 6.”:** the retrieved `article.plain_text` describes ePBS increasing best-case Fast Confirmation Rule latency from roughly 13 to 24 seconds, with optimization work underway. This is an author-reported design estimate, not this report's benchmark or an economic-finality figure. The EIP supports the underlying execution/consensus separation; the precise FCR numbers were not independently reproduced. It also places shorter slots in a proposed later upgrade, not Glamsterdam. [Full Article post](https://x.com/barnabemonnot/status/2083974773168566766).
- **green (@forereth), July 12:** questions storage-clear incentives and whether code-loading costs adequately reflect larger contracts. Those concerns are useful review questions. The post's then-current storage-price assumptions should not override the September 30 EIP-8038 table, which leaves cold storage reads at 2100. [Thread root](https://x.com/forereth/status/2076275203886223611), [follow-up](https://x.com/forereth/status/2076277563224097105).
- **ethrex (@ethrex_client), September 29:** says v28 schedules Sepolia and adds snap/2; the inspected release corroborates both. Its June compute/stateful benchmark ranking claims lacked independently inspected run conditions here and are therefore **not used as measured upgrade performance**. [Release explanation](https://x.com/ethrex_client/status/2104884118555078743), [repository release](https://github.com/lambdaclass/ethrex/releases/tag/v28.0.0).
- **Nixo (@nixorokish), September 24:** reports zero-nonce storage-account cleanup among features moved to considered status for Hegotá. This supports the later-fork context for EIP-8253 but does not make it a Glamsterdam inclusion. [Post](https://x.com/nixorokish/status/2103164113841250376).

## Candidates, deferred/excluded EIPs and unresolved scope

There are **no currently listed PFI/CFI Glamsterdam EIPs** in the inspected Forkcast view. Older articles describing dozens still under consideration are stale. A frozen scope can still receive fixes or emergency removals. The current Review meta-EIP omits its historical proposed/declined lists, consistent with EIP-7723; absence of those sections is not evidence that every earlier proposal was accepted.

**EIP-7610 is removed.** It would reject contract creation onto accounts with nonempty storage. The [removal PR](https://github.com/ethereum/EIPs/pull/12189) was approved and merged August 20; current EIP-7773 omits it and devnet-11 marks it removed. The Ethereum overview still naming it as scheduled is stale. Use the current meta-record and merged decision.

**EIP-8253 is a later-fork candidate, not confirmed for Glamsterdam.** It proposes a one-time nonce bump on 28 legacy mainnet accounts to prevent creation/storage collisions without a permanent runtime check. Its document is Draft. Its author argues that removing 7610 leaves a formal inconsistency between executing storage wipes and applying BAL diffs; triggering it on mainnet requires an infeasible-looking address preimage, but that does not erase the specification concern. Devnet-11 excludes it; ACDE #245 lists the late-inclusion discussion, and Nixo's September 24 post places cleanup in Hegotá consideration. This report establishes its exclusion from current Glamsterdam scope, but does not claim a complete inspected final vote transcript or guaranteed Hegotá inclusion. [Specification](https://eips.ethereum.org/EIPS/eip-8253), [author's original argument](https://gist.github.com/jochem-brouwer/72b97452ba440da909e5da5bdf876817), [ACDE #245 agenda](https://github.com/ethereum/pm/issues/2211).

**Other important exclusions:** FOCIL (7805), delayed execution (7886), shorter-block-latency proposal (7782), EOF meta (7692), and metered larger-code proposal (7907) are absent from current scheduled scope and appear in the historical DFI list. FOCIL is part of the later Hegotá roadmap; ePBS does not supply its transaction-inclusion guarantee. EIP-7954 increases code size without adopting all of 7907. Frame Transactions (8141) discussed in a Hegotá agenda or experimental “on top of Glamsterdam” network should not be misclassified as Glamsterdam. Current gas metering under 8037 does not imply inclusion of the separate multidimensional proposal 8011. [Historical meta-record](https://github.com/ethereum/EIPs/blob/a08f51fec5b2b5da457adb05b8cffb487fb4f7de/EIPS/eip-7773.md), [ACDE #245](https://github.com/ethereum/pm/issues/2211), [roadmap](https://ethereum.org/roadmap).

**Historical DFI inventory, with a currentness limit.** The inspected pre-removal meta revision records the following 41 declined EIPs. This is a historical exclusion inventory, cross-checked for absence from the current scheduled list, not a claim that every later consideration status was individually refreshed:

2926 (Chunk-Based Code Merkleization); 5920 (PAY); 6404 (SSZ transactions); 6466 (SSZ receipts); 7619 (Falcon512 verifier); 7668 (Remove bloom filters); 7686 (Linear EVM memory limits); 7692 (EOFv1 Meta); 7745 (Trustless log index); 7782 (Reduce Block Latency); 7791 (GAS2ETH); 7793 (Conditional Transactions); 7805 (FOCIL); 7819 (SETDELEGATE); 7872 (Max blob flag for local builders); 7886 (Delayed execution); 7903 (Remove Initcode Size Limit); 7907 (Meter Contract Code Size And Increase Limit); 7919 (Pureth Meta); 7923 (Linear, Page-Based Memory Costing); 7932 (Secondary Signature Algorithms); 7937 (EVM64); 7942 (Available Attestation); 7949 (genesis.json schema); 7971 (Hard Limits for Transient Storage); 7973 (Warm Account Write Metering); 7979 (Call and Return Opcodes); 8011 (Multidimensional Gas Metering); 8013 (Static relative jumps and calls); 8030 (P256 transaction support); 8032 (Size-Based Storage Gas Pricing); 8051 (ML-DSA verifier); 8053 (Milli-gas); 8057 (Inter-Block Temporal Locality Gas Discounts); 8058 (Contract Bytecode Deduplication Discount); 8059 (Gas Units Rebase); 8062 (0x01 validator sweep withdrawal fee); 8068 (Neutral effective balance); 8071 (Prevent consolidations as withdrawals); 8080 (Let exits use consolidation queue); 8254 (Cap Deposit Requests Per Block). [Inspected revision](https://github.com/ethereum/EIPs/blob/a08f51fec5b2b5da457adb05b8cffb487fb4f7de/EIPS/eip-7773.md).

Forkcast's extracted view displays **37** declined in one section and **44** in another, with details collapsed. Those totals cannot be reconciled from the returned content. The current full declined inventory remains a bounded evidence gap; this report does not invent missing entries or reasons. Known primary scope decisions and all confirmed EIPs are still covered.

## Migration priorities and user expectations

1. **Application developers:** review fixed call gas, transfer/send stipends, gasleft arithmetic, presigned deployments, ERC-4337 accounting, event/log indices and proof verifiers. Test real workflows on Platåberget and then Sepolia after its fork. Higher outer gas limits cannot repair every immutable contract assumption.
2. **Wallets, RPCs and infrastructure:** update estimates and transaction admission for both gas dimensions and combined floors; support new headers/logs and avoid hardcoded maximum-gas assumptions. Review traces and counters separately from user-paid gas.
3. **Validators/builders:** update EL, beacon node, validator client and signer integrations; inspect Gloas proposer settings and builder duties, including gas preferences. Sepolia releases are not a mainnet activation instruction. Maintain fresh trusted checkpoints under the shorter weak-subjectivity assumptions.
4. **Rollup operators:** distinguish L1 publishing/settlement effects from your EVM fork. Audit SELFDESTRUCT burning and proving/accounting compatibility before adopting these semantics. Communicate actual fee and withdrawal changes after measurement.

The [repricing dashboard](https://ethereum.github.io/repricing-impact/) replays historical transactions individually against canonical pre-transaction state. It tests original limits and a 10× ceiling. “Fixable” means rescued in that replay, not necessarily practical under protocol limits; “potentially broken” means not rescued at the tested ceiling, not proof of inevitable future production failure. Its unknown category is a diagnostic coverage gap. The extracted dashboard did not return loaded aggregate counts, so no affected-contract percentage is quoted. The [EF guide](https://blog.ethereum.org/2026/08/24/glamsterdam-repricing-testing) says the large majority are unaffected and recommends address-level checks and testing; that is qualified guidance, not a guarantee for any particular contract.

Ordinary ETH holders do not need to exchange or “upgrade” their ETH. The most plausible visible changes are application-dependent: better ETH deposit detection, new smart-wallet deployments, different gas estimates and staking queue behavior. Lower fees, more throughput and easier sync are expected possibilities whose scale remains uncertain. Faster slots, faster finality, universal MEV protection and fixed percentage fee reductions are not established Glamsterdam outcomes.

## Provider ledger and research limits

Exactly **Octen, Exa, Perplexity Search and authenticated X** supplied research. All four completed useful reads; availability is confirmed by returned results, not configuration. Codex performed analysis and writing. No native web reader/search, Exa Agent/Connect, Perplexity Ask/Reason/Research, X scraping, or browser substitute was used. Search ranking/extraction may internally use provider models; no generated narrative answers were used as evidence. Meeting-summary snippets with malformed fork names were treated as leads and excluded from substantive support.

| Provider/interface | Distinct contribution and controls | Completed evidence and limits |
|---|---|---|
| Octen `mcp__codex_apps__octen_broad_search` | Initial multi-angle discovery: one intent-preserving question, max_queries 8, count 5/angle, highlights 1200 tokens, X domains excluded; no date filter | Returned eight provider-generated subqueries and official upgrade/roadmap leads. Secondary numerical hype was not adopted. Initial 502-character attempt failed validation; corrected under-500 question was the only executed Broad Search. |
| Octen `mcp__codex_apps__octen_search` | Targeted exclusion/scope gap, primary-domain filter, 6 results; no repeat Broad Search | Useful EF leads but many irrelevant results; semantic Exa follow-up pursued the gap. |
| Octen `mcp__codex_apps__octen_extract` | Full-body primary specs, meta-EIP, deployment/test records, release notes and original discussions; query unset; cache-age requested 300 seconds | Successful batch reads supplied scope and mechanisms. Requesting cache age 1 failed workspace minimum 300 validation. A later two-URL request for consensus spec/Sepolia config failed with “Transport closed”; not used as evidence. A guessed EIP-8400 URL and Forkcast eips.json path returned 404. One unnecessary repeat meta-EIP read occurred; no substantive claim depends on repetition. |
| Exa `mcp__exa__web_search_exa` | Regular semantic discovery and independent cross-check of official fork scope, technical specs, headliner tradeoffs and excluded inventory; rich ideal-source descriptions, 8/6/5 results | Found EIP-7773, EF announcement, devnet records, stakeholder originals and historical records. No Advanced Search, Agent or Connect. No date/domain API filter; intent requested primary sources and excluded X content. |
| Exa `mcp__exa__web_fetch_exa` | Full specification reads and EIP-7723 process context; known URLs; character limits chosen for content size | Retrieved consensus/execution specs and historical meta with complete DFI inventory. EIP-8045/8061 web pages returned only headings, so Octen raw-source retrieval completed those. Forkcast tree and JSON paths were unavailable; its collapsed page returned little content. Fetch of main/master eips.ts located an import but no usable current JSON. |
| Perplexity `mcp__perplexity__perplexity_search` | Missing/recent primary updates: Fast Search for latest September schedule and exclusion leads; Web Search for ambiguous 7610/8253 late-scope question; 5–6 results, 1200–1500 tokens/page, primary-domain filters | Fast discovered devnet-11 and repricing guidance; Web exposed removal/late-cleanup discussion, then primary bodies were retrieved with permitted readers. No recency filter: explicit dates were in queries. URL/index dates sometimes conflicted with body dates. No generated answer mode. |
| Authenticated X, xurl CLI | OAuth2 status checked, then raw GET `/2/tweets/search/all`; author expansion, created_at, conversation/references, Article field; note_tweet in later reads | Successful archive results and Article plain_text. Broad query: Glamsterdam excluding retweets, Jan 1→Sep 30 00:00 UTC, max 50. Researcher query: Glamsterdam/ePBS/BALs with named accounts, same window, max 60, 34 returned. Author/maintainer/app query: same window, max 50, 36 returned. Three conversation IDs: Jul 1→Sep 30 00:00 UTC, max 50, 36 returned. Continuation tokens existed and were not exhausted; this is selected discussion coverage, not an exhaustive archive or full September 30 UTC coverage. |

The executed Octen Broad Search question was: “As of 30 September 2026, what practical changes will Ethereum Glamsterdam bring to developers and users? Find primary Ethereum records for official name, stage, timing, agreed consensus/execution EIPs versus candidates/deferred items, specs, client implementation/tests, security and migration tradeoffs, measured versus expected performance, mainnet/rollup effects and developer concerns. Distinguish proposal, inclusion, testing and activation.” Octen generated the angles; Codex did not presplit them.

X account filters covered Tim Beiko, Ansgar Dietrichs, Parithosh Jayanthi, Nixo, Vitalik Buterin, Barnabé Monnot, and selected EIP authors/client/application accounts, including @chfast, @potuz_eth, @ethrex_client, @forereth, @katiabanina, @LidoFinance and @Optimism. Not every filter produced a relevant result. Some requested handle spellings may not match current accounts; no absence conclusion is drawn. Thread searches covered `2094722263379526084`, `2076275203886223611`, and `2077758038820172268`; pagination limits mean complete-thread coverage is not guaranteed. Public authenticated visibility does not expose private/deleted/unavailable posts.

**Remaining uncertainties:** mainnet/Hoodi activation dates; final release completeness across every client; outcomes of adversarial, reorg and ecosystem testing; final composed specification details where older prose/constants remain; exact current declined inventory; representative performance and fee outcomes; and rollup-specific adoption/migrations. This is an evidence-backed September 30 snapshot, not a forecast or an independent client audit. Supporting source bodies and relevant excerpts were inspected, but benchmark runs, chain replays and client tests were not reproduced by Codex.