Hegotá
ScopingTarget: 2027The network upgrade following Glamsterdam, anchored by FOCIL for consensus-layer censorship resistance and statelessness groundwork.
About Hegotá
Hegotá is Ethereum's next planned hard fork following Glamsterdam. It combines consensus-layer Heze and execution-layer Bogotá. FOCIL (Fork-choice Enforced Inclusion Lists) is locked as the primary consensus headliner to strengthen censorship resistance, while execution-layer candidates focus on state efficiency (Verkle Trees) and advanced account abstraction.
Devnets & Testnets
Devnets and feature testnets (such as focil-devnet-0 for FOCIL EIP-7805 and frames-devnet-0 for Frame Transactions EIP-8141) are developer testbeds for the Hegotá upgrade (Heze consensus + Bogota execution). Discover all specifications and client support matrices on the full devnets directory.
Headliners
The defining features this upgrade is built around.
Fork-choice Enforced Inclusion Lists (FOCIL)
Confirmed CL headliner (ACDC #175): enables validators to enforce transaction inclusion to eliminate builder censorship.
EIP-6800Verkle Trees & Statelessness
Execution-layer candidate: replaces Merkle Patricia Tries to drastically lower node storage requirements.
Core EIPs PFI
41EIPs 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.
Remove storage‑clear refunds and the 20% refund cap
This proposal eliminates the gas refund that users got for clearing storage slots and also removes the rule that limited total refunds to 20% of the gas used. The only remaining refund is the write‑reversal rule, which simply undoes a charge when a value is set back to its original state. By dropping these refunds, the protocol becomes simpler and avoids complex interactions with other gas rules.
Key benefits
- +Simpler gas accounting for clients and nodes
- +Eliminates the need for a separate refund‑cap calculation
- +Reduces cross‑transaction incentive complexity
- +Ensures refunds never exceed charges, making caps unnecessary
Trade-offs & considerations
- –Contracts that relied on storage‑clear refunds will pay more gas
- –Gas estimators must be updated to reflect higher costs for clearing storage
Who this affects
- App & contract developers
- Must adjust gas estimates and may need to redesign contracts that depended on storage‑clear refunds.
- Everyday users
- May see slightly higher transaction fees when clearing storage, but benefit from a more predictable gas model.
- Consensus clients
- Consensus‑layer clients must enforce the new transaction gas settlement without the refund cap.
- Execution clients
- Execution‑layer clients must implement the removal of STORAGE_CLEAR_REFUND and the refund‑cap logic.
- Wallet teams
- Will need to update fee‑calculation logic to match the new refund rules.
- Validators & node operators
- Node operators need to run updated client software that follows the new gas rules.
- Infrastructure & tooling
- Gas‑estimation tools and analytics must be updated to remove the cleared‑storage refund and cap logic.
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.
Ethereum PAY Opcode
This EIP introduces a new opcode, PAY, that allows transferring ether to an address without calling its functions, reducing security risks and gas costs. It solves issues like reentrancy attacks, DoS vectors, and unnecessary code execution. The PAY opcode makes ether transfers cheaper and easier.
Key benefits
- +Reduces reentrancy attack risks
- +Prevents DoS vectors
- +Avoids unnecessary code execution
- +Lowers gas costs for ether transfers
Trade-offs & considerations
- –Requires a hard fork
- –May change address space extension behavior
Who this affects
- App & contract developers
- App developers can use the PAY opcode to send ether without calling contract functions, reducing security risks and gas costs.
- Wallet teams
- Wallet developers may need to update their implementations to support the new PAY opcode.
- Validators & node operators
- Stakers and node operators need to be aware of the hard fork requirement for this EIP.
Roadmap alignment
Scale L1Minor gas efficiency improvements for ETH transfers by having a dedicated function and avoiding unnecessary code execution.
Improve UXImproving fees and security for users, avoiding reentrancy and DoS attack vectors.
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.
Linear Memory Costing
This EIP replaces the quadratic memory model with a linear, page-based model to make memory usage more efficient and predictable. The current quadratic model is outdated and makes it hard to reason about memory allocation. This change will make it easier for smart contract languages to use virtual memory, similar to modern programming languages.
Key benefits
- +More efficient memory usage
- +Easier to reason about memory allocation
- +Enables virtual memory for smart contract languages
Trade-offs & considerations
- –May require changes to existing smart contract implementations
Who this affects
- App & contract developers
- Will benefit from more efficient memory usage and easier memory allocation, enabling more complex smart contracts.
- Infrastructure & tooling
- May need to update implementations to support the new linear memory model.
Roadmap alignment
Scale L1The more efficient memory management in contracts will lower the gas limit and allow for more operations onchain
Improve UXThe gas cost estimation by user wallets can be more straightforward, resulting in less overpaying and avoiding out of gas transaction fails.
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.
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.
Swap three precompiles for regular EVM contracts
When the network upgrades, the RIPEMD‑160, MODEXP and BLAKE2f precompiles will be replaced by ordinary EVM bytecode placed at the same addresses. This keeps existing contracts working but removes the need for special‑case code in each client. The change aims to lower maintenance effort and make it easier for new client implementations, especially zkEVMs. Gas costs will follow normal EVM pricing instead of the current precompile formulas.
Key benefits
- +Eliminates special‑case precompile code in every client.
- +Simplifies adding new client implementations and zkEVM support.
- +Reduces long‑term maintenance and consensus‑bug surface.
- +Preserves backward compatibility – existing contracts keep working.
Trade-offs & considerations
- –Gas usage may increase for large inputs because standard EVM execution is slower than optimized native code.
- –Exact bytecode and gas impact are not yet defined, so developers must wait for details.
- –Contracts that rely on precise precompile gas formulas may need to adjust.
Who this affects
- App & contract developers
- Developers can keep using the same addresses, but should test gas consumption under the new EVM implementation.
- Layer 2 rollups
- Layer‑2 solutions that call these precompiles will continue to work, but must account for possible gas cost differences.
- Everyday users
- Users may see slightly different transaction fees for calls to these addresses due to changed gas pricing.
- Execution clients
- Execution‑layer clients no longer need to maintain separate native implementations for these three functions.
- Infrastructure & tooling
- Block explorers, debuggers and analysis tools must treat these addresses as regular contracts rather than precompiles.
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.
Sync beacon blocks without downloading execution payloads
This proposal replaces a field in the block bid with a SHA‑256 accumulator called partial_header_hash. The accumulator lets consensus‑layer clients verify needed data without fetching full execution payloads, so they can sync large block ranges faster and with less bandwidth. Execution‑layer clients also receive the same hash for independent validation.
Key benefits
- +Consensus clients can sync ranges without downloading full execution payloads
- +Bandwidth usage during sync is dramatically reduced
- +CPU load on sync nodes is lowered because no payload validation is needed
- +A single hash commitment simplifies verification across layers
- +Overall sync speed improves and reliance on the execution engine during sync drops
Trade-offs & considerations
- –Both consensus and execution clients must implement the new SHA‑256 accumulator logic
- –Adds a new field to block bodies, increasing protocol complexity
- –Nodes must wait for the execution layer to catch up to verify the accumulator later
- –Risk of divergent accumulator implementations between layers
Who this affects
- Consensus clients
- Consensus‑layer clients gain independent range sync but need to process the new accumulator field
- Execution clients
- Execution‑layer clients add the partial_header_hash to payloads and perform matching validation
- Validators & node operators
- Node operators must upgrade both consensus and execution software to handle the new partial_header_hash and accumulator logic
- Infrastructure & tooling
- Sync tools and monitoring infrastructure must be updated to understand and verify the new hash commitment
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 let shared senders run independent transaction streams
This proposal replaces the single nonce used by frame transactions with a set of nonce keys plus a shared sequence number. Each non‑zero key gets its own counter, so different users can share the same sender address without stepping on each other's pending transactions. It keeps the existing limit of one pending frame transaction per sender while giving privacy‑focused apps a way to avoid a bottleneck.
Key benefits
- +Multiple users can share one sender without blocking each other
- +Privacy protocols can use a single address without linking actions
- +Single‑use keys (e.g., nullifiers) get an atomic spent‑once guarantee
- +Concurrent pending frame transactions become possible
Trade-offs & considerations
- –Adds new transaction fields and validation logic, requiring client updates
- –Limits the number of nonce keys per transaction to 16
- –First use of a key incurs an extra 20 k gas cost
- –Requires a special empty NONCE_MANAGER address to exist on each network
Who this affects
- App & contract developers
- Developers of privacy protocols and relayer services can design flows that share a sender while keeping each user’s actions independent.
- Everyday users
- Users of privacy or shared‑sender applications can transact faster because their actions no longer wait on unrelated nonces.
- Consensus clients
- Consensus‑layer clients must incorporate the keyed‑nonce rules into block proposal and verification logic.
- Execution clients
- Execution‑layer clients need to recognize the NONCE_MANAGER address and enforce its empty‑code requirement.
- Wallet teams
- Wallet software must encode and decode the new nonce_keys and nonce_seq fields and track key usage.
- Validators & node operators
- Validators and other consensus participants must apply the new nonce‑key checks during transaction validation.
- Infrastructure & tooling
- Mempools, block explorers, and other decoders must reject malformed payloads and enforce the non‑overlapping‑key rule.
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.
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 to limit block size
This proposal adds a per‑transaction counter that tracks how many bytes each opcode adds to the Block Access List (BAL). For every byte, 64 gas is added to a transaction’s minimum gas requirement, and the transaction aborts if this floor exceeds its gas limit. The change reduces the maximum data an attacker can pack into a block from about 1.55 MB to roughly 0.9 MB at the same gas limit, while leaving normal transactions unchanged.
Key benefits
- +Caps worst‑case block size, improving node robustness
- +Stops attacks that overload blocks with cheap BAL bytes
- +Normal transaction costs stay the same
- +Creates headroom for higher throughput or safety margin
- +Applies a uniform price to all BAL‑related bytes
Trade-offs & considerations
- –All execution‑layer clients must add new metering logic
- –Transactions that exceed the new floor may now run out of gas
- –Adds a small runtime overhead for counting BAL bytes
Who this affects
- Execution clients
- Execution‑layer clients must implement the BAL byte counter and floor check, raising the validation cost for each transaction.
- Validators & node operators
- Validators need to run updated clients that enforce the new floor, ensuring blocks cannot exceed the tighter size limit.
SETCODEFROM: adopt code from another contract
The proposal adds a new EVM opcode that lets a contract replace its own code with the code of an already‑deployed contract. It lets factories and upgrade logic reuse existing bytecode without paying the full deployment cost, and provides a way to migrate accounts away from ECDSA‑based transaction authority.
Key benefits
- +Reduces gas spent when many contracts share identical runtime code
- +Enables cheap upgrades by adopting a shared implementation
- +Provides a built‑in migration path for accounts that want to drop ECDSA authority
- +Avoids redeploying the same bytecode multiple times
Trade-offs & considerations
- –Cannot be used in static contexts or during contract creation – it will halt
- –Only works if the source account has non‑empty, regular code and is not a precompile
- –The new code is visible only to later calls, not the current execution frame
Who this affects
- App & contract developers
- Can build cheaper factory contracts and simpler upgrade mechanisms using the opcode.
- Layer 2 rollups
- Rollups and other L2s need to implement the opcode to stay compatible with L1 semantics.
- Consensus clients
- Consensus-layer clients must enforce the validity rules for source accounts.
- Execution clients
- Execution-layer clients must add support for the opcode and its gas calculation.
- Wallet teams
- Gain a native way to switch an account to custom wallet code, disabling ECDSA transaction origination.
- Validators & node operators
- Validators and other nodes must process the state change correctly, including revert semantics.
- Infrastructure & tooling
- Analyzers, gas estimators, and debuggers must recognize the new opcode and its gas cost.
Trustless Log and Transaction Indexing
The proposal stores compact hash trees of log data in a special system contract for each block, then merges them into larger tables that cover many blocks. This creates a cheap, verifiable index that lets anyone prove a log entry without trusting a remote provider. It keeps log‑related gas costs low while giving a useful way to look up past events.
Key benefits
- +Much cheaper to update than the state tree, keeping log‑related gas low.
- +Provides trustless proofs for log queries, so users don’t need to trust third‑party indexers.
- +Enables efficient cross‑chain message passing using log indexes.
- +Allows logs to serve as a lightweight form of state, helping reduce overall state bloat.
- +Supports future ZKP batching to further lower on‑chain verification costs.
Trade-offs & considerations
- –Adds storage overhead in the system contract for each block’s index root.
- –Requires new logic to generate, merge, and manage multiple index tables.
- –Proofs for log queries are larger than simple state witnesses, increasing data size.
Who this affects
- App & contract developers
- Can query logs cheaply and even treat them as a low‑cost state, enabling new contract designs and cross‑chain features.
- Layer 2 rollups
- Can use log index proofs to receive messages from other chains that implement the same indexing scheme.
- Everyday users
- Can obtain verifiable log data without relying on trusted providers, improving security and trust.
- Execution clients
- System contract address and storage layout must be added to client implementations.
- Validators & node operators
- Block processing cost stays low, but nodes must store additional index roots, modestly increasing storage.
- Infrastructure & tooling
- Will need to support building and serving the index tables and proof generation.
Shift checkpoint to the last block before each epoch
This change makes the checkpoint that validators vote on point to the final block of the previous epoch instead of the first block of the new epoch. By fixing the target before the epoch starts, validators get more time to see the block and fewer votes are lost, and finality reporting becomes clearer.
Key benefits
- +Validators lose fewer target‑vote rewards in the first slot of each epoch
- +More propagation time reduces missed votes and improves finality reliability
- +Finality semantics match whole epochs, making explorer reports accurate
- +No changes needed to the execution layer
Trade-offs & considerations
- –Consensus clients must implement new functions and a fork activation epoch
- –Existing tooling that assumes the old checkpoint root may need updates
- –If an epoch ends with empty slots, the checkpoint may point to an earlier block
Who this affects
- Consensus clients
- Consensus clients need to add get_checkpoint_slot/root and adjust related logic
- Validators & node operators
- Validators gain more reliable target rewards and clearer finality expectations
- Infrastructure & tooling
- Block explorers and monitoring tools will report epoch finality more accurately
Tapered Issuance Burn
This EIP introduces a tapered issuance burn, where validators are charged a deduction for their duties, and the deducted ETH is burned. The burn fraction increases as the staking ratio rises, reducing net staking yield. This aims to remove the yield floor and let the staking market settle at a sustainable level. The change is phased in over 18 months to minimize disruption.
Key benefits
- +Reduces yield floor, allowing market to settle at sustainable level
- +Decreases incentive for excessive stake growth
- +Improves Ethereum's security and resistance to capture
- +Protects ETH's role as money
Trade-offs & considerations
- –Reduces staking yields over time
- –May lead to stake concentration and moral hazard
Who this affects
- Execution clients
- Ethereum layer 1 clients may need to implement changes to support the tapered issuance burn mechanism.
- Validators & node operators
- Stakers will see their yields decrease over time as the burn fraction increases. This may lead to a decrease in stake growth and a more stable staking market.
CPSB Recalibration for New Gas Limit
Normalized state gas limit
Core EIPs SFI
2EIPs 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.
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.
Other EIPs
3Networking, Meta, Informational, and ERC standards associated with this upgrade.
eth/XX - announce transactions with nonce
eth/vhash - Blob-Aware Mempool
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.
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-27EIP-8141addedSFI
- 2026-08-27EIP-8141removedCFI
- 2026-08-25EIP-8368addedPFI
- 2026-08-21EIP-8094addedPFI
- 2026-08-21EIP-8077addedPFI
- 2026-08-21EIP-8268removedPFI
- 2026-08-21EIP-8372addedPFI
- 2026-08-21EIP-8363addedPFI
- 2026-08-20EIP-5920addedPFI
- 2026-08-20EIP-7923addedPFI
- 2026-08-20EIP-3298addedPFI
- 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
Email updates for Hegotá
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.