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
23EIPs proposed for this upgrade that are still under initial review by client teams.
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.
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.
Code-Controlled EOA Delegation
Delayed State Root
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.
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.
Unified Transaction Content Floor
Block Access List Sidecars
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.
ECDSA Authority Deactivation Aware ecRecover
Reserve `EXTENSION (0xae)` opcode
Foundations of EVM Control Flow
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.
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
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.
Recent Roots for Frame Transactions
Block Access List Byte Floor
SETCODEFROM Code Reuse Instruction
Trustless log and transaction index
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-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-7623removedPFI
- 2026-06-17EIP-8146addedPFI
- 2026-06-09EIP-8131addedPFI
- 2026-06-09EIP-7851addedPFI
- 2026-06-09EIP-7979addedPFI
- 2026-06-09EIP-7623addedPFI
- 2026-06-09EIP-8151addedPFI
- 2026-06-09EIP-8163addedPFI
- 2026-06-09EIP-8173addedPFI
- 2026-06-09EIP-8182addedPFI
- 2026-06-09EIP-8237addedPFI
- 2026-06-04EIP-8148addedPFI
- 2026-05-25EIP-7709addedPFI
- 2026-05-25EIP-8025addedPFI
- 2026-05-25EIP-8253addedPFI
- 2026-05-22EIP-8188addedPFI
- 2026-05-22EIP-4758addedPFI
- 2026-04-30EIP-8141addedCFI
- 2026-04-30EIP-7716addedPFI
Email updates for Hegotá
Follow inclusion and bucket changes for this upgrade.
Email me when EIPs are added, removed, or moved between upgrade buckets.