Hegotá
ScopingTarget: 2027Early-stage upgrade following Glamsterdam; headliner selection in progress.
About Hegotá
Hegotá is in early planning. The headliner proposal window is opening, with fork-choice enforced inclusion lists (FOCIL) among the leading candidates. Check back for updates as the upgrade planning process progresses.
Combines "Heze" (consensus layer, named after a star) and "Bogotá" (execution layer, named after a Devcon location).
Headliner
The defining feature this upgrade is built around.
Proposed for Inclusion
37EIPs proposed for this upgrade that are still under initial review by client teams.
Deprecate CALLCODE
This proposal removes the CALLCODE instruction from Ethereum, as it was never used and puts a burden on implementations. It was replaced by DELEGATECALL in 2016. The change makes CALLCODE always return failure, allowing contracts to potentially recover. This change helps light clients and those syncing from a later point in time.
Key benefits
- +Removes unused instruction
- +Reduces burden on EVM implementations
- +Helps light clients
- +Assists clients syncing from a later point
Trade-offs & considerations
- –Breaking change that may break contracts
- –Potential impact on contracts using CALLCODE
Who this affects
- App & contract developers
- May need to update contracts to avoid using CALLCODE, but expected impact is minimal.
- Consensus clients
- May see improvement when syncing from a later point in time due to reduced instruction set.
- Execution clients
- Helps light clients by reducing the burden of unused instructions.
- Infrastructure & tooling
- EVM implementations will have a reduced burden due to the removal of the unused CALLCODE instruction.
Deactivate SELFDESTRUCT
This EIP changes the SELFDESTRUCT opcode to SENDALL, which only sends all Ether in an account to the caller, without removing code or storage. This change is necessary for future Ethereum upgrades, like Verkle trees. It affects how contracts handle funds and storage.
Key benefits
- +Simplifies account management
- +Supports future Ethereum upgrades
- +Reduces state changes
Trade-offs & considerations
- –Breaks certain contract use cases
- –Affects contract upgradability
Who this affects
- App & contract developers
- App devs need to update contracts using SELFDESTRUCT for fund retrieval or upgradability. Some use cases, like burning non-ETH tokens, will no longer work.
Alias ORIGIN to SENDER
This EIP proposes to change the Ethereum Virtual Machine (EVM) so that the ORIGIN opcode returns the same value as the SENDER opcode. This change aims to improve security and facilitate account abstraction. It addresses security concerns associated with the use of ORIGIN and helps to harmonize the treatment of externally owned accounts and smart contracts.
Key benefits
- +Improves security by eliminating vulnerabilities
- +Facilitates account abstraction
- +Simplifies the EVM model
- +Reduces tech debt
Trade-offs & considerations
- –Not fully backwards compatible
- –May affect contracts relying on ORIGIN
Who this affects
- App & contract developers
- App developers may need to review and update their smart contracts to ensure they function correctly under the new definition.
- Execution clients
- Ethereum layer 1 clients must implement the change to the EVM.
Replace Identity Precompile
This proposal removes the identity precompile and replaces it with a short piece of EVM code that does the same thing. The goal is to reduce the number of precompiles, which can lower maintenance costs and risks. This change should not affect how Ethereum works for users. It's a first step in simplifying Ethereum's precompiles.
Key benefits
- +Reduces maintenance costs
- +Lowers risk of consensus bugs
- +Simplifies Ethereum client implementations
Trade-offs & considerations
- –Slightly different gas costs
Who this affects
- App & contract developers
- May need to adjust for slightly different gas costs, but overall functionality remains the same.
- Consensus clients
- Need to implement the change to remove the precompile and add the new EVM code.
- Execution clients
- Need to implement the change to remove the precompile and add the new EVM code.
- Infrastructure & tooling
- May need to update to account for the removal of the precompile and the new EVM code.
Remove Bloom Filters
This proposal removes bloom filters from Ethereum blocks and transaction receipts. Bloom filters were meant to help apps quickly find relevant data, but they're too slow and most apps use other methods instead. This change simplifies the protocol and encourages decentralized solutions. It's a step towards a more efficient Ethereum.
Key benefits
- +Simplifies Ethereum protocol
- +Encourages decentralized solutions
- +Removes inefficient feature
Trade-offs & considerations
- –Breaks apps relying on bloom filters
- –No immediate gas cost reduction
Who this affects
- App & contract developers
- Apps that rely on bloom filters will stop working and need to adapt to new methods for querying data.
- Execution clients
- Light clients, which were supposed to benefit from bloom filters, will need alternative methods for efficient data querying.
- Validators & node operators
- Nodes will no longer need to handle bloom filters, simplifying their operations.
Update BLOCKHASH Opcodes
This EIP updates the BLOCKHASH opcode to read from system contract storage, allowing for stateless execution and reducing the need for clients to store block hashes. This change enables more efficient and scalable Ethereum operations. The update also introduces new gas costs for BLOCKHASH operations, making them more reflective of the actual storage costs.
Key benefits
- +Enables stateless execution
- +Reduces client storage needs
- +Improves scalability
Trade-offs & considerations
- –Increases gas costs for BLOCKHASH operations
- –May break use-cases relying on previous gas costs
Who this affects
- App & contract developers
- May need to update gas cost estimates and handling for BLOCKHASH operations
- Consensus clients
- Need to implement new BLOCKHASH logic and storage access
- Execution clients
- Need to implement new BLOCKHASH logic and storage access
Roadmap alignment
Scale L1Aligns BLOCKHASH with normal state-access machinery, simplifying witness construction for stateless execution and proving systems.
Anti-correlation penalties
This EIP aims to improve Ethereum's decentralization by adjusting penalties for validators. It rewards validators that operate independently and penalizes those with correlated behavior. This change encourages diversification and fault-tolerance in the network. The goal is to make the network more resilient and censorship-resistant.
Key benefits
- +Improves network decentralization
- +Encourages validator diversification
- +Enhances fault-tolerance
- +Increases censorship resistance
Trade-offs & considerations
- –Introduces backwards incompatibility
- –May be vulnerable to certain attacks
Who this affects
- Validators & node operators
- Validators may face adjusted penalties based on their behavior, incentivizing them to operate independently. This could lead to changes in their operational strategies and potentially affect their profitability.
Ethereum Block Format Change
This EIP changes how Ethereum blocks are formatted, using a new method called Simple Serialize (SSZ). This change helps make the network more efficient and consistent. It allows for better checks and proofs, and reduces the amount of data that needs to be exchanged. The change is part of a larger effort to improve the Ethereum network.
Key benefits
- +Faster and more efficient data exchange
- +Improved consistency checks
- +Better support for proofs
- +Reduced data size by ~50%
Trade-offs & considerations
- –Requires changes to existing infrastructure
- –May introduce compatibility issues
Who this affects
- App & contract developers
- App developers may need to update their applications to work with the new block format.
- Consensus clients
- Consensus Layer clients will need to be updated to work with the new block format.
- Execution clients
- Execution Layer clients will need to be updated to work with the new block format.
- Wallet teams
- Wallet developers may need to update their wallets to work with the new block format.
- Infrastructure & tooling
- Tooling and infrastructure providers will need to update their systems to support the new block format.
Roadmap alignment
Scale L1Binary engine API reduces data exchange by ~50% and eliminates format conversion latency, critical as blob counts and block sizes increase.
Improve UXTree-based hashes enable proofs of partial transaction data (e.g., function signatures) without requiring full blocks, simplifying light client and wallet implementations.
SETDELEGATE Instruction
This EIP introduces a new instruction that allows smart contracts to create and update delegation accounts, which can be used like clones but with advantages. It enables upgradeable designs without added costs and reduces gas consumption. The instruction is useful for on-chain applications that involve creating multiple instances of the same code.
Key benefits
- +Reduced gas consumption for contract calls
- +Enables upgradeable designs without added costs
- +Decreases blockchain state usage
- +Faster execution of contract operations
Trade-offs & considerations
- –May require changes to existing contract code
- –Depends on EIP-7702 and its delegation indicators
Who this affects
- App & contract developers
- App developers can use the SETDELEGATE instruction to create upgradeable contracts and reduce gas costs, making their applications more efficient and cost-effective.
- Everyday users
- End users may experience reduced transaction costs and faster contract execution.
- Wallet teams
- Wallet developers can utilize the SETDELEGATE instruction to create smart account instances with improved upgradeability and reduced gas consumption.
- Infrastructure & tooling
- Tooling and infrastructure providers may need to update their systems to support the new SETDELEGATE instruction and its interactions with EIP-7702 delegation indicators.
Roadmap alignment
Improve UXNative delegation provides upgradeability without the need for storage lookups and removes any issue related to code version incompatibilities. Development of contracts using proxies becomes easier and users benefit from additional security.
Code-Controlled EOA Delegation
This EIP allows wallet code to control the delegation lifecycle of an Ethereum account, disabling the original ECDSA key's authority while preserving code-controlled delegate updates. This is an extension of EIP-7702, which bootstraps delegation using the original EOA key. The new opcode, SETSELFDELEGATE, enables wallet code to update the delegate and disable ECDSA authority. This provides more flexibility and security for users who want to manage their accounts through wallet code.
Key benefits
- +Wallet code controls delegation lifecycle
- +Disables residual ECDSA authority
- +Preserves code-controlled delegate updates
- +Improves account security and flexibility
Trade-offs & considerations
- –Irreversible disablement of ECDSA authority
- –Potential for increased complexity in wallet code
Who this affects
- Everyday users
- End users can benefit from improved account security and flexibility, but may need to adapt to new wallet code functionality.
- Execution clients
- Ethereum layer 1 clients must recognize and support the new 0xef0101 delegation prefix and the SETSELFDELEGATE opcode.
- Wallet teams
- Wallet developers need to implement the new SETSELFDELEGATE opcode and update their code to handle ECDSA-disabled delegations.
Delayed State Root
This proposal changes how Ethereum calculates and stores state roots, which are like snapshots of the blockchain's state. By delaying this calculation, it can speed up block production and make the network more efficient. This is especially helpful for 'builders' who create blocks and need to work quickly. The change also helps with parallel processing and reduces bottlenecks.
Key benefits
- +Faster block production
- +Reduced state root computation bottleneck
- +Improved parallel processing
- +Simplified block validation
Trade-offs & considerations
- –Light clients experience one slot of additional latency for state proofs
Who this affects
- App & contract developers
- Application developers might benefit from the improved efficiency and parallel processing, but the impact is likely indirect.
- Execution clients
- Execution layer clients will see changes in how state roots are computed and stored, which could affect their implementation details.
- Validators & node operators
- Validators can attest to block validity without waiting for state root computation, potentially improving their efficiency.
Transaction Assertions
This EIP introduces a new opcode that allows contracts to inspect transaction outcomes on-chain, enabling contract developers to define assertions for state changes. This can protect Ethereum users by restricting smart contract behavior. It helps users reduce risk by allowing wallets and dApps to observe and restrict possible transaction outcomes.
Key benefits
- +Protects Ethereum users from malicious contracts
- +Restricts smart contract behavior
- +Reduces user risk
- +Enables wallets and dApps to observe transaction outcomes
Trade-offs & considerations
- –Introduces new opcode, potentially increasing complexity
- –May increase gas costs
Who this affects
- App & contract developers
- App developers can use the new opcode to define assertions for state changes, restricting smart contract behavior.
- Everyday users
- End users are protected from malicious contracts and can reduce their risk when interacting with Ethereum.
- Wallet teams
- Wallet developers can use the new opcode to observe and restrict possible transaction outcomes, enhancing user security.
EVM Call and Return
This proposal introduces new instructions to the Ethereum Virtual Machine (EVM) to support calls and returns. It aims to improve efficiency and reduce complexity by replacing dynamic jumps with explicit call and return instructions. This change enables better control-flow analysis and compilation, making the EVM more scalable and secure. The new instructions are backwards compatible, ensuring that existing code remains functional.
Key benefits
- +Improves EVM efficiency
- +Reduces complexity in control-flow analysis
- +Enhances scalability and security
- +Enables better compilation and validation
Trade-offs & considerations
- –Introduces new opcodes and instructions
- –May require updates to existing tooling and infrastructure
Who this affects
- App & contract developers
- App developers will benefit from improved efficiency and reduced complexity, making it easier to develop and optimize their applications. They may need to update their code to utilize the new instructions.
- Infrastructure & tooling
- Tooling and infrastructure providers will need to update their systems to support the new instructions and opcodes, but will benefit from improved scalability and security.
Remove old deposit fields
This EIP removes old deposit and Eth1 data fields from Ethereum's BeaconBlockBody and BeaconState structures. These fields are no longer needed after a previous update. Removing them simplifies the system and makes it easier to maintain.
Key benefits
- +Simplified validation
- +Improved maintainability
- +Removes deprecated validation logic
Who this affects
- Consensus clients
- Consensus layer clients will need to handle the updated BeaconBlockBody and BeaconState structures.
- Execution clients
- Execution layer clients may need to adapt to the removal of legacy deposit fields.
- Validators & node operators
- Stakers and node operators will need to update their software to work with the new BeaconBlockBody and BeaconState structures.
Optional Execution Proofs
This EIP allows beacon nodes to verify the validity of execution payloads without running an execution layer client, reducing hardware and bandwidth requirements. It introduces optional execution proofs that can be sent over the consensus layer's peer-to-peer network. This change is backwards compatible and does not require a hardfork. It enables safer testing of execution proofs without making them consensus critical.
Key benefits
- +Reduces hardware requirements for attesters
- +Decreases bandwidth needs for verification
- +Verifying a block no longer depends on gas limit
Trade-offs & considerations
- –Protocol upgrades cannot rely on these improvements
Who this affects
- Consensus clients
- Consensus layer clients can benefit from reduced hardware and bandwidth requirements for verifying beacon blocks.
- Validators & node operators
- Validators can enable new modes: zkEVM proof generating and stateless validation, reducing their verification costs and requirements.
Roadmap alignment
Scale L1Stateless, sublinear payload verification decouples a node's validation cost from the gas limit and state size, eventually supporting a higher-throughput L1 without raising validator hardware requirements.
Batch Priority Fees
This EIP changes how priority fees are processed, crediting them at the end of each block instead of after each transaction. This improves parallel execution of transactions and reduces accounting complexities. It aims to optimize the processing of priority fees from EIP-1559 fee market transactions.
Key benefits
- +Improves parallel execution of transactions
- +Reduces accounting complexities
- +Simplifies mempool management
- +Enables more accurate ETH balance logs
Trade-offs & considerations
- –Fee recipients can only spend priority fees in the next block
- –May require updates to block builder infrastructure
Who this affects
- App & contract developers
- No direct impact, but may benefit from improved parallel execution and simplified accounting.
- Infrastructure & tooling
- May require updates to block builder infrastructure and change liquidity requirements for MEV use cases.
Simplify Receipt Data
This EIP changes how Ethereum stores transaction data, making it easier to verify and access. It replaces cumulative gas used with individual transaction gas used, and changes log indexing. This simplification improves efficiency and parallelism.
Key benefits
- +Easier verification of transaction gas used
- +Improved parallelism for transactions
- +Simplified log indexing
Trade-offs & considerations
- –Applications need to adapt to new data semantics
Who this affects
- App & contract developers
- Need to adapt to new on-chain data semantics and updated log indexing
- Execution clients
- RPC clients will see changes in logIndex field and gasUsed values
Unified Transaction Fees
This proposal simplifies and unifies the fees for different parts of a transaction on the Ethereum network. It charges a flat rate of 64 gas for every user-controlled byte in a transaction, which helps to prevent extremely large blocks that could slow down the network. This change aims to make the network more efficient and scalable.
Key benefits
- +Simplifies transaction fees
- +Prevents extremely large blocks
- +Improves network scalability
- +Reduces risk of network congestion
Trade-offs & considerations
- –May increase costs for some transactions
- –Could affect transaction sizes and complexity
Who this affects
- App & contract developers
- May need to adjust their transaction handling and fee calculations to accommodate the new unified fee structure.
- Wallet teams
- Will need to update their software to correctly calculate and display the new transaction fees to users.
- Validators & node operators
- May experience changes in network traffic and block sizes, potentially affecting their operations and revenue.
Block Access List Sidecars
This EIP moves the block access list out of the main execution payload to reduce latency and improve performance. By doing so, it allows for faster validation and better handling of large data. This change helps improve the overall efficiency of the Ethereum network.
Key benefits
- +Faster propagation and validation
- +Improved performance for large data
- +Better handling of block access lists
- +Increased headroom for gas limit increases
Trade-offs & considerations
- –Introduces additional complexity with sidecar mechanism
Who this affects
- App & contract developers
- Application developers may benefit from improved network performance and reduced latency.
- Consensus clients
- Consensus layer clients treat the block access list as opaque bytes and do not need to RLP-decode it, simplifying their processing.
- Execution clients
- Execution layer clients can prefetch state and precompute the post-state root before the payload arrives, improving their performance.
- Validators & node operators
- Stakers and node operators may need to adapt to the new sidecar mechanism and ensure proper handling of block access lists.
Custom Sweep Threshold
This EIP lets validators set a custom balance threshold for sweeping rewards to their withdrawal address, giving them more control over their staking rewards. The current default threshold may not suit all validators, so this change provides more flexibility. Validators can now optimize their reward management according to their individual strategies and preferences. This feature is optional and doesn't change the default registration or withdrawal process.
Key benefits
- +More control over staking rewards
- +Flexibility for validators to manage rewards
- +Optional feature for custom sweep thresholds
- +Reduces need for manual partial withdrawals
Trade-offs & considerations
- –May add complexity for some validators
- –Requires updates to staking protocols and node operators
Who this affects
- App & contract developers
- Staking protocols and node operators may need to update their systems to support custom sweep thresholds.
- Validators & node operators
- Validators can set custom sweep thresholds, giving them more control over their staking rewards. This feature is optional and doesn't change the default registration or withdrawal process.
Restricted ecRecover
This EIP changes how Ethereum's ecRecover function works to improve security. It restricts the function's ability to recover addresses if the account has non-empty code that doesn't match a specific format. This helps prevent old private keys from being used after an account has been migrated to a new, more secure authorization method.
Key benefits
- +Improves security for accounts that have migrated to post-quantum authorization
- +Prevents old private keys from being used after migration
- +Enhances protection against quantum-capable attackers
Trade-offs & considerations
- –May break deployed contracts that rely on the old ecRecover behavior
- –Introduces additional gas costs for state access
Who this affects
- App & contract developers
- App developers may need to update their contracts to handle the new ecRecover behavior, especially if they rely on it for signature-based authorization.
- Wallet teams
- Wallet developers should be aware of the changes to ecRecover and ensure their wallets can handle the new behavior, particularly when dealing with accounts that have migrated to post-quantum authorization.
- Infrastructure & tooling
- Tooling and infrastructure providers may need to update their systems to account for the changes in gas costs and ecRecover behavior.
Reserve Extension Opcode
This EIP sets aside a special code, called an opcode, that won't be used on the main Ethereum network but can be used on other Ethereum-based networks to create new features. This allows for innovation and experimentation on these other networks without causing problems on the main network. The goal is to make it easier for new ideas to be tested and potentially adopted by the main network later.
Key benefits
- +Enables innovation on non-mainnet Ethereum networks
- +Allows for experimentation without affecting mainnet
- +Potentially strengthens the entire Ethereum ecosystem
Trade-offs & considerations
- –May lead to incompatibilities if not coordinated properly
Who this affects
- App & contract developers
- May benefit from new features and innovations on non-mainnet networks, potentially leading to better applications.
- Layer 2 rollups
- Can utilize the reserved opcode to specialize and experiment, expanding their capabilities.
- Execution clients
- Might need optional updates to their presentation layer to handle the new opcode, but no consensus-related changes are required.
- Infrastructure & tooling
- May need to adapt to handle the new opcode, potentially requiring updates to their systems.
EVM Control Flow
This EIP provides background information on control flow in the Ethereum Virtual Machine (EVM). It discusses the history of control flow in computing and its impact on Ethereum's scaling roadmap. The goal is to inform discussions around proposals for static control flow and related topics. This EIP serves as a foundation for understanding control flow in the EVM.
Key benefits
- +Improves understanding of EVM control flow
- +Informs discussions on static control flow proposals
- +Supports Ethereum's scaling roadmap
Who this affects
- App & contract developers
- App developers may benefit from a better understanding of EVM control flow, which can inform their development decisions and optimize their applications.
- Infrastructure & tooling
- Tooling and infrastructure providers may need to adapt to changes in EVM control flow, potentially requiring updates to their systems and processes.
Private ETH Transfers
This EIP introduces private ETH and ERC-20 transfers via a shielded-pool system contract. It provides a shared privacy layer for Ethereum, allowing for private transactions without revealing sender, recipient, or amount. This is useful for activities like payroll, treasury management, and donations that require privacy. The EIP enables a common pool for ETH and compatible ERC-20 tokens, making it easier for applications to build on top of it.
Key benefits
- +Enables private ETH and ERC-20 transactions
- +Provides a shared privacy layer for Ethereum
- +Useful for activities requiring privacy like payroll and donations
- +Allows applications to build on a common pool
Trade-offs & considerations
- –Requires a hard-fork to implement changes to the pool
- –Dependent on complementary infrastructure for end-to-end transaction privacy
Who this affects
- App & contract developers
- Application developers can build on top of the shared privacy layer, creating new use cases and experiences for private transactions.
- Everyday users
- End users can benefit from private transactions, but may need to use compatible wallets and applications to take advantage of this feature.
- Wallet teams
- Wallet developers need to integrate with the shielded-pool system contract and provide support for private transactions.
Roadmap alignment
Improve UXCreates a shared private-transfer base that wallets and applications can build on instead of bootstrapping isolated app-specific pools. Users can keep address- or ENS-based recipient discovery, while note ownership inside the pool is represented by hidden owner identifiers resolved by wallets or companion standards.
Last Written Block
This proposal adds a 'last written block' field to Ethereum accounts and storage slots, tracking when each piece of state was last changed. This helps clients optimize storage and identify recently used data. The field is updated when state is changed, but not when it's read. This change enables better storage tiering and client-level optimizations.
Key benefits
- +Helps clients optimize storage
- +Enables better storage tiering
- +Improves client-level optimizations
- +Provides a consensus-verified signal for recently mutated data
Trade-offs & considerations
- –Introduces additional data storage requirements
- –May require updates to existing client implementations
Who this affects
- Consensus clients
- Consensus layer clients may need to adapt to the changed data format, but the impact is expected to be minimal.
- Execution clients
- Ethereum layer 1 clients will need to update their implementations to support the new 'last written block' field and utilize it for optimizations.
- Infrastructure & tooling
- Tooling and infrastructure providers may need to update their systems to handle the new field and provide support for clients utilizing it.
EVMification
Withdrawal Credentials Preregistration
This EIP introduces a mechanism for validator key holders to preregister withdrawal credentials before making a deposit, addressing a known vulnerability in delegated staking. This allows for more secure staking and protects against front-running attacks. The mechanism is optional and does not affect deposits without a preregistration.
Key benefits
- +Prevents front-running attacks in delegated staking
- +Provides on-chain guarantee for withdrawal credentials
- +Simplifies security for staking protocols and services
Trade-offs & considerations
- –Introduces additional complexity to the staking process
- –Requires additional storage and processing on the consensus layer
Who this affects
- App & contract developers
- May need to integrate preregistration mechanism into their staking applications and services.
- Consensus clients
- Must store and enforce preregistrations in the beacon state, and process them at deposit time.
- Execution clients
- Must support the new preregistration request type and handle the associated system contract interactions.
- Validators & node operators
- Can use the preregistration mechanism to secure their withdrawal credentials and prevent front-running attacks.
Independent CL/EL Sync
Batch Attestations
This proposal allows multiple validators to publish a single, combined attestation instead of individual ones, reducing network traffic. This change helps improve consensus throughput and paves the way for faster finality. It also enables a new way to enhance attester privacy. The goal is to achieve these benefits without requiring significant changes to the existing protocol.
Key benefits
- +Reduced network traffic
- +Improved consensus throughput
- +Faster finality
- +Enhanced attester privacy
Trade-offs & considerations
- –Potential for increased complexity in implementation
Who this affects
- Execution clients
- Ethereum layer 1 clients need to implement the new batch attestation format and handle the associated changes in gossip protocol and aggregation logic.
- Validators & node operators
- Stakers and node operators may see reduced network traffic and improved efficiency. They can also offer batching services to enhance attester privacy.
Keyed Nonces for Frame Transactions
Fix zero-nonce accounts
This EIP fixes a problem where some accounts on the Ethereum network have zero nonce and non-empty storage, which can cause issues with contract creation. It does this by bumping the nonce of these accounts to 1 at the start of a designated fork block. This prevents future contract creation from colliding with their storage. The goal is to remove a potential source of errors and make the network more reliable.
Key benefits
- +Prevents contract creation collisions
- +Removes potential source of errors
- +Makes the network more reliable
- +Avoids extra runtime storage checks
Trade-offs & considerations
- –One-time consensus mutation required
- –Only fixes existing accounts, not a general solution
Who this affects
- App & contract developers
- May need to update their contract creation logic to account for the changed nonce values.
- Consensus clients
- Need to implement the state transition to update the nonce values of the targeted accounts.
- Execution clients
- Need to implement the state transition to update the nonce values of the targeted accounts.
Storage Roots in Block Access Lists
Recent Roots for Frame Transactions
This EIP allows frame transactions to reference recent roots without reading mutable storage, helping with validation for privacy applications. It enables transactions to declare recent root references, which are then checked before validation. This improves the efficiency and security of certain types of transactions.
Key benefits
- +Improved efficiency for privacy applications
- +Enhanced security through reduced mutable storage access
- +Simplified validation for certain transactions
Trade-offs & considerations
- –Increased complexity for implementation and management
Who this affects
- App & contract developers
- App developers, especially those working on privacy applications, will benefit from this EIP as it simplifies and secures their validation processes.
- Execution clients
- Execution layer clients will need to implement the logic for handling recent root references, which could impact their development and maintenance efforts.
- Wallet teams
- Wallet developers may need to adapt their applications to work with the new recent root reference system, potentially simplifying user interactions for certain types of transactions.
Block Access List Byte Floor
SETCODEFROM Code Reuse Instruction
Trustless log and transaction index
Align Checkpoint with Epoch Boundary Block
Considered for Inclusion
1EIPs that client teams are positive towards. Implementation may begin, but inclusion is not yet guaranteed.
Frame Transaction
This EIP introduces a new type of transaction that allows for more flexibility and security in how transactions are validated and executed. It enables features like native key rotation, batch call processing, and alternative fee payment schemes. This can lead to improved user experience and security. The new transaction type is designed to be more abstract and flexible, allowing for custom definitions of validation and gas payment.
Key benefits
- +Native key rotation for improved security
- +Batch call processing for smarter accounts
- +Alternative fee payment schemes
- +Improved user experience
- +Post-quantum secure systems support
Trade-offs & considerations
- –Increased complexity in transaction processing
- –Potential for higher gas costs due to additional frames
Who this affects
- App & contract developers
- App developers can leverage the new transaction type to create more complex and secure smart contracts, with features like custom validation and gas payment schemes.
- Everyday users
- End users may experience improved security and flexibility in their transactions, with features like native key rotation and batch call processing.
- Wallet teams
- Wallet developers will need to update their software to support the new transaction type and its features, such as frame processing and alternative fee payment schemes.
Roadmap alignment
Improve UXEnables native account abstraction with flexible wallets supporting social recovery, multi-sig, spending limits, and gas sponsorship without intermediaries.
Scheduled for Inclusion
1EIPs that client teams have agreed to implement for the upgrade devnets. These are very likely to ship in the final upgrade.
FOCIL: Censorship Resistance
FOCIL is a mechanism to prevent censorship on the Ethereum network by ensuring that certain transactions are included in blocks. It does this by having a group of validators create lists of transactions that must be included. This helps to prevent a small group of powerful entities from controlling what transactions are allowed on the network. FOCIL aims to improve Ethereum's censorship resistance properties.
Key benefits
- +Prevents censorship by powerful entities
- +Ensures timely transaction inclusion
- +Improves network's censorship resistance properties
Trade-offs & considerations
- –Increased complexity for validators and builders
- –Potential for equivocation attacks
Who this affects
- Consensus clients
- Consensus layer clients will need to handle the new fork-choice rules and validation logic introduced by FOCIL.
- Execution clients
- Execution layer clients will need to update their execution payloads to include transactions from inclusion lists.
- Validators & node operators
- Stakers and nodes will need to implement and follow the FOCIL protocol, which may require updates to their software and workflows. They will also be responsible for creating and verifying inclusion lists.
Roadmap alignment
Scale L1Ethereum currently relies on local block builders to preserve censorship resistance. However, depending on local block builders comes at a cost to performance and incentives, which may conflict with scaling throughput. FOCIL is crucial in L1 scaling because it helps decouple local block building from censorship resistance.
Improve UXProvides strong guarantees against transaction censorship and ensures fair access to block space for all users regardless of transaction content.
Scale blobsA more censorship-resistant L1 provides better foundation for Layer 2 settlement guarantees, and allows to shorten the exit time window for optimistic rollups.
EIP Composition Timeline
Track EIP inclusion stages for Hegotá
Recent changes
Every time an EIP entered, left, or moved stages in this upgrade.
- 2026-08-07EIP-8333addedPFI
- 2026-08-06EIP-8243addedPFI
- 2026-08-04EIP-8200addedPFI
- 2026-08-04EIP-7666addedPFI
- 2026-08-04EIP-7819addedPFI
- 2026-08-04EIP-20addedPFI
- 2026-07-30EIP-7668addedPFI
- 2026-07-30EIP-7906addedPFI
- 2026-07-30EIP-8116addedPFI
- 2026-07-30EIP-7807addedPFI
- 2026-07-30EIP-8115addedPFI
- 2026-07-26EIP-8015addedPFI
- 2026-07-20EIP-8268addedPFI
- 2026-07-20EIP-2488addedPFI
- 2026-07-20EIP-7645addedPFI
- 2026-07-19EIP-8272addedPFI
- 2026-07-17EIP-8304addedPFI
- 2026-07-16EIP-7862addedPFI
- 2026-07-16EIP-8298addedPFI
- 2026-06-26EIP-8279addedPFI
- 2026-06-17EIP-8250addedPFI
- 2026-06-17EIP-8146addedPFI
- 2026-06-17EIP-7623removedPFI
- 2026-06-09EIP-7851addedPFI
- 2026-06-09EIP-8237addedPFI
Email updates for Hegotá
Follow inclusion and bucket changes for this upgrade.
Email me when EIPs are added, removed, or moved between upgrade buckets.