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
9EIPs proposed for this upgrade that are still under initial review by client teams.
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.
Increase Contract Code Size
This EIP increases the size limit for contract code from 24KB to 64KB and introduces a gas cost for loading large contracts. This change allows for more complex contracts while preventing potential DoS attacks. It aims to improve the developer experience by reducing the need for workarounds and making smart contract development more accessible.
Key benefits
- +Larger contract code size limit
- +Improved developer experience
- +Reduced need for workarounds
- +More accessible smart contract development
Trade-offs & considerations
- –Increased gas costs for large contracts
Who this affects
- App & contract developers
- Developers can create more complex contracts without workarounds, improving readability and reducing gas usage. This change makes smart contract development more accessible to new developers.
Roadmap alignment
Scale L1Enabling larger contracts while keeping the network secure with new gas metering preventing DoS attacks.
Improve UXMajor developer experience improvement - eliminates need for complex architectural patterns, reduces deployment complexity, and enables single-contract solutions.
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.
Block-in-Blobs (BiB)
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.
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.
Disallow new 0x00 validators
CPSB Recalibration for New Gas Limit
Normalized state gas limit
Core EIPs CFI
19EIPs that client teams are positive towards. Implementation may begin, but inclusion is not yet guaranteed.
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.
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.
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.
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.
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.
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.
TCREATE Opcode
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.
Core EIPs DFI
22EIPs that were proposed but declined for this upgrade. They may be reconsidered for future upgrades.
Other EIPs
6Networking, 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.
VOPS Profiles for FOCIL Eligibility
RowDAS - Distributed Blob Reconstruction
Reduce CL Block Retention Window
EIP Composition Timeline
Track EIP inclusion stages for Hegotá
Recent changes
Every time an EIP entered, left, or moved stages in this upgrade.
- 2026-10-08EIP-7907addedPFI
- 2026-10-08EIP-5920addedCFI
- 2026-10-08EIP-4758removedPFI
- 2026-10-08EIP-7666removedPFI
- 2026-10-08EIP-8355addedDFI
- 2026-10-08EIP-8116addedCFI
- 2026-10-08EIP-8360addedCFI
- 2026-10-08EIP-8151removedPFI
- 2026-10-08EIP-8077removedPFI
- 2026-10-08EIP-7709addedCFI
- 2026-10-08EIP-8298addedCFI
- 2026-10-08EIP-8116removedPFI
- 2026-10-08EIP-7666addedDFI
- 2026-10-08EIP-5920removedPFI
- 2026-10-08EIP-7709removedPFI
- 2026-10-08EIP-4758addedCFI
- 2026-10-08EIP-8077addedCFI
- 2026-10-08EIP-8298removedPFI
- 2026-10-08EIP-8151addedCFI
- 2026-10-08EIP-8355removedPFI
- 2026-10-05EIP-8363addedDFI
- 2026-10-05EIP-8379addedDFI
- 2026-10-05EIP-8379removedPFI
- 2026-10-05EIP-8198addedCFI
- 2026-10-05EIP-8333addedDFI
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.