Glamsterdam
TestnetsTarget: 2026The next major upgrade after Fusaka, featuring Enshrined Proposer-Builder Separation (ePBS) and Block-Level Access Lists (BALs).
About Glamsterdam
Ethereum developers are preparing for the next major network upgrade, Glamsterdam. It introduces key changes to both the Execution and Consensus layers on mainnet. Candidate EIPs are being fine-tuned, implemented, and tested on devnets as the scope firms up.
Devnets & Testnets
Devnets and early testnets (such as the Platterburg Testnet scope in glamsterdam-devnet-8) are developer testbeds where upgrade features, client specs, and consensus parameters get battle-tested before public testnet rollouts. Discover all specifications, client support matrices, and live status on the full devnets directory.
Glamsterdam EIPs in Platterburg Testnet scope
EIP List for glamsterdam-devnet-7
EIP List for glamsterdam-devnet-6
EIP List for glamsterdam-devnet-5
Headliners
The defining features this upgrade is built around.
Core EIPs SFI
18EIPs that client teams have agreed to implement for the upgrade devnets. These are very likely to ship in the final upgrade.
Proposer-Builder Separation
This EIP changes how Ethereum blocks are validated by separating the execution and consensus validation. It introduces 'builders' who create execution payloads and allows for trust-free fair exchange between builders and proposers. This improves network propagation, reduces reorg likelihood, and strengthens fork choice.
Key benefits
- +Faster network propagation
- +Reduced reorg likelihood
- +Improved fork choice
- +Trust-free fair exchange between builders and proposers
Trade-offs & considerations
- –Increased complexity with new 'builders' and 'Payload Timeliness Committee'
Who this affects
- Consensus clients
- Consensus layer clients will need to implement the new consensus changes, including the 'builders' and 'Payload Timeliness Committee'.
- Execution clients
- Execution layer clients will need to adapt to the new 'builders' and 'Payload Timeliness Committee' as part of the block validation process.
- Validators & node operators
- Stakers and node operators will see changes in how blocks are validated and propagated, with a new 'Payload Timeliness Committee' and 'builders' involved in the process.
Roadmap alignment
Scale L1Enables for much larger payloads by removing the broadcast and the execution from the hot path of block validation.
Improve UXSecond order effect of lower prices and higher tx throughput. Slight delay in minimal tx iclusion time from 0 to ~2 seconds.
Scale blobsEnables for much larger number of blobs by removing the broadcast and data availability sampling from the hot path of block validation.
Block Access Lists
This EIP introduces Block Access Lists to record accounts and storage locations accessed during block execution. This enables parallel disk reads, transaction validation, and state root computation. It improves Ethereum's performance and scalability. The proposal builds upon existing access list concepts, making them mandatory at the block level.
Key benefits
- +Faster block execution
- +Improved parallelization
- +Enhanced scalability
- +Reduced execution time
Trade-offs & considerations
- –Increased block size limit due to access list data
- –Potential for more complex block validation
Who this affects
- App & contract developers
- App developers may need to adapt their applications to work with the new block access lists, potentially simplifying their development process with improved parallelization.
- Execution clients
- Ethereum layer 1 clients will need to implement the new block access list format, which may require significant updates to their software.
- Validators & node operators
- Stakers and node operators will need to validate and process blocks with the new access lists, which could impact their node performance and resource usage.
- Infrastructure & tooling
- Tooling and infrastructure providers will need to support the new block access list format, which could require updates to their systems and processes.
Roadmap alignment
Scale L1Significantly reduces gas costs for state access through block-level optimization, improving overall network efficiency and throughput.
Improve UXLower gas costs for complex applications and improved predictability for applications with similar state access patterns.
Ethereum Transaction Cost Reform
This EIP changes how Ethereum calculates the cost of transactions. Instead of a fixed cost, it breaks down the cost into smaller parts based on what the transaction actually does. This should make transaction costs more accurate and fair. The goal is to make every transaction's cost reflect its actual work, such as signature recovery, account accesses, and state creation.
Key benefits
- +More accurate transaction costs
- +Fairer pricing for different types of transactions
- +Improved composability for future gas schedule changes
Trade-offs & considerations
- –Increased complexity in calculating transaction costs
Who this affects
- App & contract developers
- App developers may need to adjust their gas pricing strategies and transaction handling logic to account for the new cost structure. This could lead to more efficient use of gas and reduced costs for certain types of transactions.
- Wallet teams
- Wallet developers will need to update their software to correctly calculate and display transaction costs under the new system, ensuring a smooth user experience.
- Infrastructure & tooling
- Tooling and infrastructure providers may need to adapt their systems to accommodate the changed gas cost structure, potentially affecting how they optimize and manage resources.
Forward Compatible Consensus
This EIP updates Ethereum's consensus data structures to be forward compatible, making it easier for smart contracts and off-chain verifiers to work with changing data without needing frequent updates. It achieves this by adopting ProgressiveContainer and ProgressiveList from other EIPs. This change helps maintain the integrity of data and ensures that verifiers can continue to function correctly even when new features are added or old ones are removed.
Key benefits
- +Improved forward compatibility for consensus data
- +Reduced need for frequent updates in smart contracts and verifiers
- +Enhanced data integrity and security
Trade-offs & considerations
- –Potential complexity in implementing ProgressiveContainer and ProgressiveList
- –Need for runtime checks to enforce operational limits
Who this affects
- App & contract developers
- App developers will benefit from reduced maintenance needs for verifier logic in smart contracts, but may need to adapt to new data structures and runtime checks.
- Wallet teams
- Wallet developers, especially those working on hardware wallets or mobile devices, will see improved compatibility and less frequent need for updates to support Ethereum's evolving consensus data.
- Validators & node operators
- Stakers and node operators may experience smoother operation due to the forward-compatible nature of the consensus data structures, reducing the impact of forks on their operations.
Roadmap alignment
Improve UXReduces breaking changes during Ethereum upgrades.
ETH Transfers Emitted as Logs
This proposal makes Ethereum (ETH) transfers emit logs, making it easier to track balance changes. Currently, logs work for tokens but not for ETH. This change will help exchanges and other services support deposits from smart contract wallets more easily. It will also provide a unified way to track all ETH transfers.
Key benefits
- +Easier tracking of ETH balance changes
- +Improved support for smart contract wallets
- +Unified way to track all ETH transfers
Trade-offs & considerations
- –Slightly increased average number of logs
Who this affects
- App & contract developers
- App developers can use the emitted logs to track ETH transfers and provide better support for smart contract wallets.
- Everyday users
- End users will have an easier time tracking their ETH balance changes, especially when using smart contract wallets.
- Execution clients
- Execution layer clients may need to update their implementation to emit the logs for ETH transfers.
- Wallet teams
- Wallet developers can use the logs to improve their wallet's functionality and provide a better user experience.
- Infrastructure & tooling
- Tooling and infrastructure providers can use the logs to provide more accurate and reliable tracking of ETH transfers.
Block Gas Accounting Fix
This EIP changes how Ethereum accounts for gas used in blocks to prevent exploiting gas refunds, ensuring the network remains stable and secure. It stops users from exceeding the block gas limit by using refunds. This helps maintain the balance between computational work and gas limits.
Key benefits
- +Prevents network instability
- +Reduces denial-of-service risks
- +Improves block processing time predictability
Trade-offs & considerations
- –Requires a hard fork
- –Affects block producers' transaction selection
Who this affects
- App & contract developers
- No direct change in user transaction costs, but may need to adjust for new gas accounting rules in their applications.
- Validators & node operators
- Need to adjust transaction selection algorithms to account for the new gas accounting rules.
Roadmap alignment
Scale L1Reduces worst-case block size and variance, improving throughput predictability; does not increase average capacity or lower fees network-wide.
Get Current Slot Number
This EIP proposes a new opcode, SLOTNUM, that returns the current slot number for the block. It aims to provide a more reliable and efficient way to get the slot number on-chain, abstracting away the slot length from applications. This change allows for future adjustments to the slot length without breaking contracts.
Key benefits
- +Easier access to current slot number
- +Abstracts away slot length for applications
- +Allows for future slot length changes
- +Reduces gas costs compared to existing methods
Trade-offs & considerations
- –Introduces a new opcode, potentially increasing complexity
Who this affects
- App & contract developers
- App developers will benefit from easier access to the slot number and reduced gas costs. They will no longer need to hardcode the chain slot length into their contracts.
- Consensus clients
- Consensus layer clients will calculate and provide the slot number to the execution layer.
- Execution clients
- Execution layer clients will need to implement the new opcode and pass the slot number from the consensus layer.
Roadmap alignment
Improve UXEnables more reliable time-based smart contracts and better coordination between consensus and execution layers.
Larger Contracts
This proposal increases the maximum size of contracts on Ethereum, allowing for more complex and feature-rich applications. The current limit can be restrictive, and this change enables more flexibility for developers. It requires a network upgrade to take effect.
Key benefits
- +More complex contracts possible
- +Increased developer flexibility
- +No changes to existing contracts
Trade-offs & considerations
- –Marginally increased risk of denial-of-service attacks
Who this affects
- App & contract developers
- Can create more complex and feature-rich applications, with increased flexibility.
- Validators & node operators
- Must upgrade their nodes to support the new contract size limit.
Higher Calldata Fees
This proposal increases the minimum cost of sending data in Ethereum transactions. It aims to reduce the size of data-heavy transactions and create space for potential gas limit increases. The change should have a minimal impact on most users. It encourages the use of more efficient data storage methods.
Key benefits
- +Reduces worst-case block size by ~37%
- +Creates headroom for potential gas limit increases
- +Encourages migration to more efficient data storage
Trade-offs & considerations
- –May affect 1.5% of all transactions
- –Requires updates to wallet and node software
Who this affects
- App & contract developers
- Should be aware of the change but most will not need to update their applications
- Wallet teams
- Must update gas estimation handling to accommodate new calldata cost rules
- Validators & node operators
- Must update node software to incorporate the new gas calculation formula
Access List Cost Increase
This EIP increases the cost of using access lists in Ethereum transactions to prevent circumventing floor pricing. It adds a data cost to access lists, which will reduce the worst-case block size by about 21%. This change aims to ensure consistent pricing across all transaction data sources.
Key benefits
- +Prevents circumventing floor pricing
- +Reduces worst-case block size by 21%
- +Ensures consistent pricing across data sources
Trade-offs & considerations
- –Backwards incompatible gas repricing required
- –Updates to gas estimation in wallets and nodes needed
Who this affects
- App & contract developers
- Application developers may need to adjust their transaction handling to account for the changed gas costs, but normal usage patterns remain largely unaffected.
- Wallet teams
- Wallet developers need to update gas estimation to account for the new access list data cost.
- Validators & node operators
- Node operators and stakers need to implement the scheduled network upgrade to apply the new gas pricing.
Deterministic Factory Contract
This proposal makes a specific factory contract available on all EVM chains, enabling developers to deploy applications at the same address across multiple chains. This simplifies the development process and improves user experience, especially for multi-chain and cross-chain applications. It also benefits account abstraction by allowing smart contract accounts to be deployed at the same address on different chains.
Key benefits
- +Simplifies development for multi-chain applications
- +Improves user experience for cross-chain interactions
- +Enhances security by reducing address management
- +Supports account abstraction for smart contract accounts
Trade-offs & considerations
- –Requires chains to include a specific factory contract
- –May require irregular state transitions to deploy the contract
Who this affects
- App & contract developers
- Application developers will benefit from simplified development and deployment processes for multi-chain applications, as they can deploy contracts at the same address across different chains.
- Layer 2 rollups
- Layer 2 solutions may need to adapt to include the specified factory contract, ensuring compatibility with the proposed standard.
- Everyday users
- End users will have a better experience when interacting with multi-chain applications, as they won't need to manage multiple addresses for the same application on different chains.
Roadmap alignment
Improve UXComplements the rollup-centric roadmap with a native and reliable mechanism for deployment of multi-chain contracts, including smart contract accounts.
Easier Stack Access
This proposal introduces new instructions to make it easier for Ethereum Virtual Machine (EVM) compilers to access and manage items on the stack, beyond the current 16-item limit. This change aims to simplify code and improve efficiency. It helps compilers implement higher-level constructs like functions and manage local variables more effectively. The new instructions are backward compatible, meaning they won't break existing code.
Key benefits
- +Easier access to deeper stack items
- +Simplifies compiler implementation of functions
- +Improves code efficiency
- +Supports more local variables
Trade-offs & considerations
- –Introduces new opcodes that must be supported
- –Requires updates to assemblers and compilers
Who this affects
- App & contract developers
- App developers will benefit from simpler and more efficient code, especially when implementing complex logic or functions. They will need to update their development tools and workflows to utilize the new instructions.
- Infrastructure & tooling
- Tooling and infrastructure providers will need to update their software to support the new opcodes and ensure compatibility with existing and new contracts.
Roadmap alignment
Improve UXEnables Solidity to easily solve the "stack too deep" error that frequently prevents smart contract developers from working effectively.
State Creation Gas Cost
This proposal increases the cost of creating new state on the Ethereum blockchain to prevent excessive state growth as block gas limits increase. It introduces a standard cost for state creation operations and allows for increased throughput and larger contract deployments. The goal is to prevent state growth from becoming a bottleneck for scaling. This change is necessary to maintain the performance of the Ethereum network.
Key benefits
- +Prevents excessive state growth
- +Allows for increased throughput
- +Enables larger contract deployments
- +Maintains network performance
Trade-offs & considerations
- –Increases gas costs for state creation operations
Who this affects
- App & contract developers
- App developers may need to adjust their gas cost calculations and optimize their contracts for the new state creation costs.
- Execution clients
- Ethereum layer 1 clients may need to update their gas metering and state creation logic to accommodate the new costs and multidimensional metering.
- Validators & node operators
- Stakers and node operators may benefit from the maintained network performance and reduced risk of state growth bottlenecks.
Roadmap alignment
Scale L1By making state creation more expensive, this EIP helps control state growth, which is crucial for scaling Ethereum.
State Access Gas Cost Update
This EIP updates the gas cost of state-access operations to reflect Ethereum's larger state and the consequent slowdown of these operations. It raises the base costs for certain operations to better align them with the current performance. The goal is to ensure that the gas costs accurately reflect the resources required for these operations.
Key benefits
- +More accurate gas costs
- +Better performance alignment
- +Improved resource allocation
Trade-offs & considerations
- –Increased gas costs for certain operations
- –Potential impact on transaction costs
Who this affects
- App & contract developers
- App developers may need to adjust their gas estimates and pricing strategies to account for the updated gas costs. This could impact the overall cost and usability of their applications.
- Wallet teams
- Wallet developers may need to update their gas calculation logic to reflect the new gas costs, ensuring that users are accurately informed about transaction costs.
- Validators & node operators
- Stakers and node operators may experience changes in network congestion and transaction processing times due to the updated gas costs, potentially affecting their revenue and operational efficiency.
Exclude Slashed Validators
This EIP modifies the Ethereum beacon chain to prevent slashed validators from being chosen as block proposers. This change aims to reduce network disruption and increase resilience, especially during mass slashing events. By excluding slashed validators, the network can continue to operate normally with fewer missed slots.
Key benefits
- +Reduces network disruption
- +Increases resilience during mass slashing
- +Fewer missed slots
- +Improves overall network performance
Trade-offs & considerations
- –Introduces a backwards-incompatible change
Who this affects
- Execution clients
- Ethereum layer 1 clients will need to implement the proposed change to ensure compatibility and maintain network stability.
- Validators & node operators
- Stakers and node operators will see improved network performance and reduced disruption, especially during mass slashing events. They will need to update their software to accommodate the backwards-incompatible change.
Faster Validator Exits
This EIP increases the rate at which validators can exit the network, which helps reduce congestion and improve staking liquidity. It also allows for faster consolidation of the validator set, leading to faster finality. The goal is to balance security with the need for more efficient validator set management.
Key benefits
- +Faster validator exits
- +Improved staking liquidity
- +Reduced exit queue congestion
- +Faster consolidation of validator set
Trade-offs & considerations
- –Potential impact on weak subjectivity period
- –Increased churn may affect network security
Who this affects
- Everyday users
- Users may experience improved staking liquidity and faster response to market events.
- Validators & node operators
- Stakers and node operators may see reduced exit queue congestion and faster consolidation of the validator set, which can improve their overall experience and ability to manage their stake.
Remove ETH Burn
This EIP stops Ethereum contracts from burning (permanently destroying) Ether when they self-destruct. It simplifies how contracts work and removes a rarely used feature. This change helps keep the total Ether supply consistent and makes the Ethereum network easier to understand and work with.
Key benefits
- +Simplifies contract self-destruction
- +Removes a rarely used feature
- +Keeps total Ether supply consistent
Trade-offs & considerations
- –Requires a hard fork
- –Affects Optimism-based L2 chains
Who this affects
- App & contract developers
- App developers will see a change in how contracts self-destruct, but most existing functionality remains unchanged.
- Layer 2 rollups
- Optimism-based L2 chains will need a separate migration plan due to their regular use of the burn feature.
- Infrastructure & tooling
- Ethereum infrastructure and tooling may need updates to handle the changed self-destruction behavior.
Ethereum Builder Requests
This proposal introduces two new contracts for Ethereum builders to manage deposits and exits. It aims to simplify the process and reduce coupling between validator and builder flows. By dedicating separate request types for builders, the proposal improves the overall efficiency and security of the network.
Key benefits
- +Dedicated request types for builders
- +Improved security through reduced coupling
- +Simplified deposit and exit processes
- +Bounds denial-of-service surface
Trade-offs & considerations
- –Introduces new contracts, potentially increasing complexity
Who this affects
- Consensus clients
- Consensus layer clients will need to verify the new request types and interact with the dedicated builder contracts, which may require updates to their verification logic.
- Execution clients
- Execution layer clients will need to support the new contracts and request types, ensuring compatibility and seamless integration.
- Validators & node operators
- Stakers and node operators will need to adapt to the new contracts and request types, which may require updates to their systems and processes.
Roadmap alignment
Scale L1A dedicated, rate-capped builder request bus bounds the per-block signature-verification work an attacker can force, removing a consensus-layer denial-of-service surface as block sizes grow.
Core EIPs DFI
38EIPs that were proposed but declined for this upgrade. They may be reconsidered for future upgrades.
Other EIPs
11Networking, Meta, Informational, and ERC standards associated with this upgrade.
EVM Object Format
This EIP introduces a new format for Ethereum Virtual Machine (EVM) objects, which aims to improve the efficiency and security of smart contracts. The EVM Object Format (EOF) includes several changes to how code is executed and validated. These changes are designed to make it easier to write and deploy secure smart contracts.
Key benefits
- +Improved smart contract security
- +More efficient code execution
- +Better support for complex contracts
Trade-offs & considerations
- –Increased complexity for developers
- –Potential for backwards compatibility issues
Who this affects
- App & contract developers
- App developers will need to update their contracts to be compatible with the new EVM Object Format. This may require significant changes to their code and testing procedures.
- Infrastructure & tooling
- Tooling and infrastructure providers will need to update their systems to support the new EVM Object Format, which may require significant development and testing efforts.
Roadmap alignment
Scale L1Enables incremental deployment of more efficient execution environments like RISC-V and EVM64 for computationally intensive tasks while maintaining EVM compatibility. Removes JUMPDEST analysis overhead.
Improve UXProvides better developer tools through improved code analysis, versioning capabilities, and performance improvements for computationally intensive applications.
Max Blobs per Block
This EIP lets block builders limit the number of blobs in a block. This helps builders with low bandwidth include a manageable amount of blobs. It's an execution layer change, aiming to prevent builders from including too many blobs and failing to convince the network of their availability.
Key benefits
- +Builders can manage bandwidth better
- +Prevents including too many blobs
- +Improves block builder reliability
Who this affects
- Execution clients
- Execution layer clients may need to update their block builder configurations to utilize the new `USER_CONFIGURED_MAX_BLOBS_PER_BLOCK` parameter.
- Validators & node operators
- Stakers and nodes, acting as block builders, can configure the maximum blobs per block to suit their bandwidth.
Ethereum Gas Cost Analysis
This EIP analyzes the gas costs of Ethereum operations and finds that no changes are needed. It studied how fast different operations can run on the network and compared that to a target speed. The analysis showed that all operations are already fast enough, so no price increases are required. This means that the network can handle more transactions without needing to raise the gas costs.
Key benefits
- +No gas cost increases needed
- +Network can handle more transactions
- +Operations already meet target speed
- +No changes required for Ethereum gas schedule
Trade-offs & considerations
- –No direct benefits for end users
- –Analysis relies on current network optimizations
Who this affects
- App & contract developers
- Application developers can continue to build on the Ethereum network without worrying about increased gas costs for their operations.
- Execution clients
- Ethereum layer 1 clients are affected as they need to continue optimizing their performance to meet the target throughput.
- Infrastructure & tooling
- Tooling and infrastructure providers can use the analysis to better understand the performance of the Ethereum network and optimize their own systems.
Roadmap alignment
Scale L1Increases the throughput of compute operations by optimizing gas costs to better match actual resource usage.
Ethereum Data Access
This EIP improves Ethereum data access by making it easier to verify without relying on third-party providers. It achieves this by changing data structures for blocks, transactions, and receipts, allowing for efficient correctness and completion proofs. This enhances security, privacy, and reduces costs. It also simplifies the detection of user deposits and other basic flows.
Key benefits
- +Enhanced security
- +Improved privacy
- +Reduced costs
- +Simplified user deposit detection
Trade-offs & considerations
- –Requires changes to data structures
- –Needs production-grade SSZ libraries
Who this affects
- App & contract developers
- App developers will have easier access to verified data, simplifying the development of wallets and dApps.
- Everyday users
- End users will have improved security and privacy, and may experience better performance due to reduced reliance on third-party providers.
- Execution clients
- Execution layer clients will need to implement production-grade SSZ libraries and adapt to new data structures.
- Wallet teams
- Wallet developers will benefit from improved security, privacy, and reduced costs, making it easier to develop and maintain wallets.
- Infrastructure & tooling
- Tooling and infrastructure providers may need to adapt to new data structures and serialization formats.
Roadmap alignment
Scale L1Improves network decentralization by reducing reliance on trusted RPC providers and enabling more efficient light client verification.
Improve UXEliminates trust requirements for data access, enables secure light clients, and dramatically improves decentralization of the application ecosystem.
Ethereum Genesis File Format
This EIP defines a standard structure for Ethereum genesis files to ensure consistency and compatibility across different clients. It aims to reduce ambiguity and incompatibilities by introducing a JSON Schema for validation. The standard aligns with the existing structure used by Geth and other clients. This will simplify the process of setting up and running Ethereum networks.
Key benefits
- +Ensures consistency across clients
- +Reduces ambiguity and incompatibilities
- +Simplifies network setup and management
- +Improves tool compatibility
Who this affects
- App & contract developers
- App developers may need to update their tools to comply with the new standard, but this will ultimately simplify their development process.
- Execution clients
- Ethereum layer 1 clients, such as Geth, will need to ensure their genesis file format aligns with the new standard.
- Infrastructure & tooling
- Tooling infrastructure providers will benefit from the new standard, as it will enable them to create more compatible and efficient tools.
Partial Block Receipts
This EIP allows Ethereum clients to request partial block receipts, helping to prevent sync failures when block sizes exceed the 10MiB message size limit. This change supports higher block gas limits on the mainnet. It modifies the 'eth' p2p protocol to enable partial receipt lists. This helps clients handle large blocks without rejecting messages due to size limits.
Key benefits
- +Prevents sync failures due to large block sizes
- +Supports higher block gas limits on mainnet
- +Enables partial block receipt requests
Trade-offs & considerations
- –Introduces new attack surface with partial receipt lists
- –Requires additional validation for partial receipts
Who this affects
- Consensus clients
- Consensus layer clients may need to adapt to the new protocol version, but the EIP does not change consensus rules, so their core functionality remains unaffected.
- Execution clients
- Ethereum layer 1 clients need to implement the new 'eth/70' protocol version to support partial block receipts and avoid sync failures. They must also apply additional validation for partial receipts to ensure security.
- Infrastructure & tooling
- Tooling and infrastructure providers may need to update their systems to support the new protocol version and handle partial block receipts correctly.
Sparse Blobpool
This proposal introduces a new way to handle large data on the Ethereum network, reducing the amount of data that needs to be downloaded and shared. This change aims to decrease bandwidth consumption and improve network efficiency. The new method, called sparse blobpool, allows nodes to sample data instead of downloading it all, which reduces the load on the network. This change is necessary to support increased data throughput on the network.
Key benefits
- +Reduces bandwidth consumption by ~4x
- +Improves network efficiency
- +Preserves simplicity and resilience
- +Enables smoother bandwidth utilization patterns
Trade-offs & considerations
- –May introduce complexity in devp2p protocol changes
- –Could lead to issues if sampling is not properly aligned
Who this affects
- Consensus clients
- Consensus Layer clients will benefit from the aligned sampling, which preserves their ability to satisfy sampling needs with pre-propagated data.
- Execution clients
- Execution Layer clients will need to implement the new devp2p protocol version, eth/72, to support sparse blobpool.
- Validators & node operators
- Validators will download less data, around 1/8 of the total, reducing their bandwidth consumption.
Cell-Level Data Transfer
This EIP optimizes data transfer in Ethereum by allowing nodes to exchange only the necessary cells within a data column, rather than the entire column. This reduces bandwidth waste and improves efficiency. The optimization is backwards compatible and can be deployed without a hard fork.
Key benefits
- +Reduces bandwidth waste
- +Improves data transfer efficiency
- +Backwards compatible
- +No hard fork required
Trade-offs & considerations
- –Introduces complexity with cell bitmaps and request/provide cells
Who this affects
- Execution clients
- Ethereum layer 1 clients can benefit from improved data transfer efficiency, leading to faster block processing and improved overall network performance.
- Validators & node operators
- Nodes can reduce bandwidth usage and improve data transfer efficiency, leading to cost savings and improved performance.
Block Access List Exchange
This EIP adds a way for Ethereum peers to share Block Access Lists (BALs), which help with parallel processing and state updates. BALs record the parts of the blockchain that are accessed during block execution. This change helps syncing clients work more efficiently. It introduces two new messages for requesting and serving BALs.
Key benefits
- +Enables parallel disk reads
- +Allows parallel transaction execution
- +Supports executionless state updates
Trade-offs & considerations
- –Increases block header size
- –May require additional storage for BALs
Who this affects
- App & contract developers
- May need to update their syncing strategies to leverage Block Access Lists.
- Consensus clients
- Need to update to support the new block header format and eth/71 protocol.
- Execution clients
- Need to update to support the new block header format and eth/71 protocol.
- Wallet teams
- No direct impact, but may benefit from improved syncing efficiency.
- Validators & node operators
- Need to support the new eth/71 protocol version and handle Block Access List messages for efficient syncing.
- Infrastructure & tooling
- May need to support the new eth/71 protocol version and handle Block Access List messages.
Snap/2 Upgrade
This EIP upgrades the snap protocol to version 2, replacing trie node fetching with block access lists (BALs) for state healing during sync. This change enables more efficient state syncing and reduces the number of round trips needed. The upgrade is based on EIP-7928, which introduces block-level access lists. By using BALs, nodes can download and apply state diffs sequentially, making the syncing process more efficient.
Key benefits
- +Faster state syncing
- +Reduced round trips
- +More efficient state healing
- +Improved sync reliability
Trade-offs & considerations
- –Requires EIP-7928 activation
- –Nodes must retain BALs within a defined retention period
Who this affects
- Validators & node operators
- Nodes must implement the new snap/2 protocol and retain block access lists within a defined retention period. This may require updates to their syncing and storage mechanisms.
- Infrastructure & tooling
- Tooling and infrastructure providers may need to update their systems to support the new snap/2 protocol and handle block access lists.
In-Client Gas Limit Schedule
EIP-8261 defines an in-client gas limit schedule to coordinate gas limit target adjustments across Consensus Layer validator clients. As a Meta/Informational proposal, it carries no EVM execution state changes and does not follow the standard Execution Fork Inclusion (SFI/EL) staging pipeline. Recent ACDE consensus selected EIP-8261 to move forward as an optional CL configuration parameter.
Key benefits
- +Provides automated, scheduled gas limit target updates across Consensus Layer validator clients
- +Coordinates gas limit increases without hardfork EVM code modifications or unplanned manual node operator re-configurations
Trade-offs & considerations
- –Requires coordination across consensus client teams and validator node operators to adopt matching config schedules
Who this affects
- validators
- Validator operators can enable the optional CL configuration parameter to follow agreed gas limit schedules.
- app_developers
- Indirect benefit from predictable block gas limit capacity increases over time.
- node_operators
- Informational guidance for node operators; configured via standard CL flags with zero EVM state impact.
EIP Composition Timeline
Track EIP inclusion stages for Glamsterdam
Recent changes
Every time an EIP entered, left, or moved stages in this upgrade.
- 2026-08-20EIP-7610removedSFI
- 2026-08-20EIP-7610addedDFI
- 2026-08-13EIP-8261addedSFI
- 2026-08-05EIP-8254addedDFI
- 2026-08-05EIP-8159removedCFI
- 2026-08-05EIP-8136addedSFI
- 2026-08-05EIP-7997addedSFI
- 2026-08-05EIP-2780removedCFI
- 2026-08-05EIP-7610removedCFI
- 2026-08-05EIP-7688removedCFI
- 2026-08-05EIP-8282removedCFI
- 2026-08-05EIP-8136removedCFI
- 2026-08-05EIP-8189removedCFI
- 2026-08-05EIP-7610addedSFI
- 2026-08-05EIP-8070addedSFI
- 2026-08-05EIP-8159addedSFI
- 2026-08-05EIP-8282addedSFI
- 2026-08-05EIP-8189addedSFI
- 2026-08-05EIP-7997removedCFI
- 2026-08-05EIP-8045removedCFI
- 2026-08-05EIP-8038removedCFI
- 2026-08-05EIP-8061removedCFI
- 2026-08-05EIP-8045addedSFI
- 2026-08-05EIP-8246removedCFI
- 2026-08-05EIP-7975removedCFI
Email updates for Glamsterdam
Follow inclusion and bucket changes for this upgrade.
Email me when EIPs are added, removed, or moved between upgrade buckets.
AI Disclaimer: Some content or metadata on EIPsInsight may be AI-inferred or automatically compiled. If you find any discrepancy, please contact us at dev@avarch.org.