FusakaFusaka Upgrade
LiveMajor improvements to Ethereum's scalability and user experience, including PeerDAS for enhanced data availability.
PeerDAS enables nodes to specialize in storing data subsets, increasing capacity for Layer 2 networks.
Fusaka Proposals
SWAPN, DUPN and EXCHANGE instructions
This adds three new EVM instructions (DUPN, SWAPN, and EXCHANGE) that allow smart contracts to access and manipulate stack items beyond the current 16-item limit, reaching up to 256 items deep. Currently, the EVM stack can hold 1024 items but only the top 16 are easily accessible. These new instructions help compilers write more efficient code for complex functions with many variables by providing better stack management capabilities. The feature only works with the new EOF bytecode format, not legacy contracts.
EOF - EVM Object Format v1
This introduces EVM Object Format (EOF), a new standardized container for smart contract bytecode that gets validated once when deployed rather than every time it runs. EOF separates code from data, making contracts more structured and analyzable. It enables future EVM improvements like better jump instructions, multibyte opcodes, and function representations. The format is extensible and versioned, allowing gradual introduction of new features. Only new contracts can use EOF - existing contracts remain unchanged. This is the foundation that makes other EOF-related improvements possible.
EOF - Code Validation
This adds strict validation rules for EOF smart contracts when they're deployed. It rejects contracts with invalid bytecode, such as incomplete PUSH instructions or undefined opcodes. It also removes deprecated instructions like CALLCODE and SELFDESTRUCT from EOF contracts. This validation only happens once at deployment time and only affects new EOF contracts - existing legacy contracts remain unchanged. The goal is to make bytecode more predictable and easier to reason about, while ensuring all EVM implementations handle code the same way.
EOF - Static relative jumps
This introduces three new jump instructions (RJUMP, RJUMPI, and RJUMPV) for EOF contracts that use relative addressing instead of absolute addressing. These instructions are more gas-efficient than traditional JUMP/JUMPI instructions, don't require JUMPDEST markers, and make code analysis easier. RJUMP does unconditional jumps, RJUMPI does conditional jumps, and RJUMPV provides jump tables for switch-case scenarios. The relative addressing means code can be moved around without breaking, and the static nature allows for better optimization and validation at deployment time.
EOF - Functions
This introduces proper function support to EOF contracts by allowing multiple code sections, each representing a separate function. It adds two new instructions: CALLF to call functions and RETF to return from them. Functions have defined input/output parameters and their own isolated stack, improving code organization and analysis. Dynamic jumps (JUMP/JUMPI) are completely removed in favor of static function calls, making contracts more predictable and easier to optimize. A return stack tracks function call history, and JUMPDEST becomes a simple NOP instruction since jump analysis is no longer needed.
EOF - Stack Validation
This adds comprehensive stack validation to EOF contracts at deployment time, ensuring that stack underflow and overflow cannot happen during execution. By analyzing all possible code paths and tracking stack heights, it eliminates the need for most runtime stack checks, making execution faster and more predictable. Only CALLF and JUMPF instructions need runtime stack overflow checks. The validation also prevents deployment of unreachable code and ensures proper function termination. This creates guarantees that enable better compiler optimizations and ahead-of-time compilation while maintaining linear validation complexity.
PAY opcode
The PAY opcode simply transfers ETH without executing code at recipient, making it more efficient, secure and compatible with account abstraction.
EOF - JUMPF and non-returning functions
This introduces the JUMPF instruction for EOF contracts, enabling tail call optimization by jumping to code sections without adding return stack frames. It also introduces non-returning functions - sections that never return control to their caller. This is particularly efficient for error handling helpers that end with REVERT, allowing compilers to generate more optimal code with reduced gas costs and smaller bytecode size. Functions can jump to other functions with fewer outputs, and non-returning functions don't need to clean up extra stack items before terminating.
Revamped CALL instructions
This introduces three new call instructions (EXTCALL, EXTDELEGATECALL, EXTSTATICCALL) for EOF contracts that remove gas observability and simplify call semantics. Unlike legacy CALL instructions, these don't allow specifying gas limits - they use the 63/64th rule automatically. They return extensible status codes (0=success, 1=revert, 2=failure) instead of boolean values, remove output buffer complexity in favor of RETURNDATACOPY, and add RETURNDATALOAD for efficient return data access. This makes contracts more resilient to future gas repricing and eliminates many gas-related attack vectors while simplifying the calling mechanism.
EOF - Data section access instructions
This introduces four new instructions for EOF contracts to access their data section: DATALOAD (loads 32-byte word), DATALOADN (optimized version with compile-time offset), DATASIZE (returns data section size), and DATACOPY (copies data to memory). These replace the deprecated CODECOPY instruction for data access in EOF contracts, enabling proper separation between code and data. The instructions follow the same pattern as existing data access instructions like those for calldata and returndata, with zero-padding for out-of-bounds access and validation to ensure safe operation.
EOF Contract Creation
This introduces new contract creation instructions for EOF contracts: EOFCREATE and RETURNCODE, which replace the legacy CREATE/CREATE2 instructions. Since EOF removes code observability (the ability to inspect and manipulate code), the old creation methods don't work. EOFCREATE creates contracts using pre-validated subcontainers within the factory contract, maintaining security while enabling factory patterns. RETURNCODE allows the initialization code to specify which subcontainer becomes the deployed contract and append additional data. This preserves the factory contract use case while maintaining EOF's code non-observability guarantees.
EVM-ify the identity precompile
This removes the identity precompile (at address 0x04) and replaces it with actual EVM code that does the same thing - simply copying input data to output data. The identity precompile was originally needed because there was no direct way to copy memory, but since the MCOPY opcode was introduced, this precompile is no longer necessary. Removing it reduces maintenance burden and complexity for Ethereum clients, including ZK-EVMs. This serves as a template for potentially removing other underused precompiles in the future, like certain hash functions.
Remove bloom filters
Bloom filters were supposed to provide log filters for applications but they do not work as originally intended. Under this EIP, the field is not entirely removed but needs to be empty. Applications should seek alternative and decentralized solution to fetching relevant logs.
Forward compatible consensus data structures
This EIP stabilizes Merkle tree indices for all consensus data, preventing coincidental verifier breakage when fields are added, removed, or list capacities change during Ethereum upgrades.
EVM Object Format (EOFv1) Meta
This introduces a new container format for EVM bytecode that enables code versioning, removes complex jump analysis, and paves the way for new execution environments like RISC-V and EVM64 within the same contract. This EIP was Declined for Inclusion from Fusaka on [April 28th](https://blog.ethereum.org/2025/04/29/checkpoint-2#eof) due to a lack of consensus on implementation details and the resulting potential slowdown of shipping PeerDAS. It has been re-proposed as a headlining feature in Glamsterdam with multiple variants to address community concerns.
EOF - Creation transaction
This enables deploying EOF contracts using regular creation transactions (transactions with empty 'to' field). Since legacy CREATE and CREATE2 instructions cannot deploy EOF code, creation transactions are the only way to get the first EOF contracts on-chain. The transaction data contains an EOF initcontainer followed by calldata for constructor arguments. This approach allows existing deployment tooling to work without modification - developers can deploy EOF contracts the same way they deploy legacy contracts, just by concatenating constructor arguments with the initcontainer. The execution ends with a RETURNCODE instruction that specifies which subcontainer becomes the deployed contract.
Enshrined Proposer-Builder Separation
Proposes the decoupling of the consensus block from the execution payload, both in broadcast and validation. This feature enables L1 scaling by significantly changing the time required to both broadcast and executing the payload together with all the blob data, from the current ~2 seconds to aproximately ~9 seconds. It allows for a maximum portion of the slot to be spent in propagation large data.
EXTCODETYPE instruction
This adds an EXTCODETYPE instruction to EOF contracts to distinguish between different account types. EOF removes code introspection capabilities like EXTCODESIZE, but this creates problems for ERC-721 and ERC-1155 tokens that need to know whether a recipient is an EOA (externally owned account) or a contract to implement safe transfers correctly. EXTCODETYPE returns 0 for no code (EOA), 1 for legacy contracts, and 2 for EOF contracts. This enables proper implementation of token standards in EOF while also helping proxy contracts verify that their upgrade targets are safe to call with EXTDELEGATECALL.
Increase MIN_BASE_FEE_PER_BLOB_GAS
This increases the minimum blob base fee from 1 wei to 2^25 wei (about 33 million times higher) to speed up blob price discovery. Currently, when blob demand exceeds supply, it takes too long for prices to climb from the extremely low minimum to actual market rates. The new minimum corresponds to about 1 cent at current ETH prices, similar to the cost of a simple transaction when gas fees are low. The change also resets excess blob gas to zero to prevent a sudden price spike when the upgrade activates. This helps blob-based rollups reach appropriate pricing faster during high-demand periods.
Add Controlled Gas Limit Increase Strategy
This proposes automatic, controlled gas limit increases over time instead of relying on manual adjustments by validators. Currently, gas limits change unpredictably based on individual validator decisions, which can cause network performance issues. The EIP offers three strategies: linear (fixed increase per block), stepwise (increases in steps), and exponential (doubling over intervals). Each includes safeguards like deactivation blocks to prevent indefinite growth. This provides predictable network scaling while giving the ecosystem time to adapt to larger block sizes, and validators retain the ability to halt increases if problems arise.
GAS2ETH opcode
EIP-7791 creates native fee mechanism for decentralized application by introducing a new GAS2ETH opcode that allows smart contracts to convert gas directly into ETH and send it to a specified address. It provides a new monetization mechanism for smart contract authors and public goods projects that scales with network usage. Instead of complex fee structures or token schemes, developers can charge gas (which users already understand) and receive proportional compensation during high network activity periods. The opcode takes a target address and gas amount, deducts the gas from the transaction, calculates the ETH value using the current gas price, and transfers that ETH to the specified address.
Conditional Transactions
Adds support for conditional transaction that is only valid at a chosen spot in a block, improving support for encrypted mempools.
SETDELEGATE instruction
Adds a new instruction for upgradeable, lightweight contract clones via EIP-7702 delegation. This is similar to upgradable proxy contracts but enabled natively on protocol level, therfore cutting gas and complexity.
Separate Metadata Section for EOF
This adds a dedicated metadata section to EOF contracts that is completely separate from executable code and data. Currently, compilers include metadata (like compiler versions, IPFS hashes of source files) by mixing it with contract data, which creates problems for source code verification and causes different bytecode when metadata changes. The new metadata section solves these issues by being unreachable by contract execution, unchanging after deployment, and clearly separated from functional code. This makes source code verification much easier and ensures that contracts with identical logic but different metadata will have the same executable bytecode.
SLOTNUM opcode
Let contracts directly read the current slot number cheaply, removing timestamp math and reducing breakage if Ethereum's slot duration changes later.
EOF - TXCREATE and InitcodeTransaction type
This introduces a new way to deploy EOF contracts by adding a TXCREATE instruction and a special InitcodeTransaction type. The problem it solves is that EOF removes the traditional CREATE and CREATE2 instructions used to deploy contracts. With this EIP, both regular users (EOAs) and smart contracts can deploy EOF contracts by including the contract code directly in transaction data and using TXCREATE to deploy it. This works alongside the existing EOFCREATE instruction, giving developers all the contract creation capabilities they had before EOF. The TXCREATE instruction can also deploy legacy contracts, making it a universal bootstrapping mechanism for getting EOF contracts onto the blockchain.
EOF - EXTCODEADDRESS instruction
This adds a new EXTCODEADDRESS instruction to EOF contracts that helps them work with EIP-7702 delegation accounts without breaking EOF's no-code-introspection rule. The problem it solves is that EOF removes the ability to read raw contract code, but contracts still need to know when an account is delegating execution to another address. This instruction takes an address and returns the actual address that will execute the code - for regular accounts it returns the same address, but for delegated accounts it returns the address they're delegating to. This enables important use cases like managed proxy contracts ensuring they don't delegate to unsafe addresses, sponsorship contracts verifying delegation hasn't changed during a transaction, and security-conscious contracts that only accept specific delegation targets.
Emit log on revert
This automatically makes error messages from failed transactions easily accessible by emitting them as logs. Currently, when a transaction fails (reverts), the error message explaining why it failed is hard to get - you need to request expensive transaction tracing to access it. This creates overhead for users who want to understand why their transaction failed and for nodes that have to replay entire transactions just to extract small error messages. This EIP solves the problem by automatically emitting a log containing the revert message whenever the REVERT opcode is called. This makes error messages accessible through standard RPC calls without any tracing, helping wallets, block explorers, and other tools display helpful error messages to users. It's completely backward compatible and doesn't require any new opcodes or RPC methods.
Uncouple execution payload from beacon block
This addresses a fundamental scalability bottleneck by separating transaction data from consensus data in Ethereum blocks. Currently, beacon blocks contain all transaction data embedded within them, but as Ethereum aims to increase block sizes (potentially by 10x), this creates serious networking and processing problems. Larger transaction payloads cause higher latencies for block transmission, increased bandwidth requirements, and longer block processing times that hurt validator performance. This EIP solves these issues by replacing the full transaction data in beacon blocks with just a header, while transmitting the actual transaction data separately. This allows the consensus layer to process blocks quickly while handling much larger transaction payloads independently. Additional benefits include reduced storage requirements for beacon nodes, more efficient proposer-builder separation, and laying groundwork for future innovations like ZK-proof-based execution validation where transaction data could be handled similarly to blobs with data availability sampling.
Remove Initcode Size Limit
This removes the 49,152-byte limit on initialization code (initcode) that was introduced by EIP-3860. The problem this solves is that the current limit makes it unnecessarily difficult to deploy large, complex smart contracts that need to create multiple sub-contracts in a single transaction. For example, if you want to deploy a sophisticated DeFi protocol that consists of several interconnected contracts, you might hit the initcode limit even though each final contract stays under the 24KB deployed code limit (EIP-170). This forces developers to split deployments across multiple transactions, which is more expensive, less efficient, and breaks the clean abstractions that high-level programming languages try to provide. By removing this artificial limit, the EIP allows for more flexible deployment patterns while still maintaining security through existing gas costs that scale with initcode size. The per-block gas limit already naturally restricts initcode to reasonable sizes (around 16MB at current gas limits), making the 49KB cap redundant. This change is fully backward compatible and only removes restrictions without changing how contracts work.
Meter Contract Code Size And Increase Limit
Increases the contract code size limit from 24KB to 256KB and introduces gas metering for larger contracts. This will enable developers to deploy larger files and applications in a single contract instead of more complex multi contract architecture.
Pragmatic stack manipulation tools
This adds practical stack manipulation tools to the EVM without requiring the complex EOF format. It extends the existing SWAP and DUP instructions to reach deeper stack positions (up to 24 positions), adds dynamic SWAPN and DUPN instructions for variable depth access, and introduces an EXCHANGE instruction that can swap any two arbitrary stack positions. These tools help compilers generate more efficient code when dealing with complex functions that have many local variables, reducing gas costs and bytecode size. Unlike previous attempts that required new code formats, this proposal works with existing legacy contracts by requiring specific PUSH instructions before the dynamic operations, making it a pragmatic solution that provides better stack access without breaking backward compatibility.
Pureth Meta
This enables Ethereum nodes to provide cryptographic proofs with their responses, eliminating the need to trust RPC providers. Users can verify that data from any source is authentic without running their own full node.
Genesis File Format
Standardizes genesis file structure to streamline compatibility across Ethereum clients, aiding smoother network launches.
PeerDAS - Peer Data Availability Sampling
PeerDAS enables Ethereum nodes to specialize in storing different pieces of data while still verifying everything is available. This foundational change dramatically increases data capacity for Layer 2 networks while maintaining security.
eth/69 - history expiry and simpler receipts
A change to EL networking that changes how receipts are handled and removes old data from node synchronization, saving approximately 530GB of bandwidth during sync.
Set upper bounds for MODEXP
This introduces a 8192-bit (1024 byte) limit on each input to the MODEXP cryptographic precompile. MODEXP has been a source of consensus bugs due to unbounded inputs. By setting practical limits that cover all real-world use cases (like RSA verification), this reduces the testing surface area and paves the way for future replacement with more efficient EVM code.
Transaction Gas Limit Cap
This introduces a 16,777,216 gas (2^24) cap for individual transactions, preventing any single transaction from consuming most of a block. The goal is to ensure fairer access to block space and improve network stability.
ModExp Gas Cost Increase
This increases the gas cost of the ModExp cryptographic precompile to address underpriced operations. It raises the minimum cost from 200 to 500 gas and doubles costs for large inputs over 32 bytes.
Blob Parameter Only Hardforks
This creates a new lightweight process to adjust blob storage parameters. Instead of waiting for a major upgrade, Ethereum can make smaller, more frequent adjustments to blob capacity to accommodate changing demand from Layer 2s.
eth_config JSON-RPC Method
Adds an eth_config API on Ethereum nodes so tools can read how clients are configured for current and upcoming forks, helping operators verify settings.
Deterministic proposer lookahead
This makes Ethereum's block proposer schedule completely predictable ahead of time. Currently, validators can't know who will propose blocks in the next epoch until it starts, which creates uncertainty for MEV mitigation and preconfirmation protocols. This change pre-calculates and stores the proposer schedule for future epochs, making it deterministic and accessible to applications.
Blob base fee bounded by execution cost
This addresses blob fee market problems by introducing a reserve price tied to execution costs. When Layer 2 execution costs dominate blob costs, this prevents the blob fee market from becoming ineffective at 1 wei. See a storybook-style explanation [here](https://notes.ethereum.org/@anderselowsson/AIG)!
RLP Execution Block Size Limit
This adds a maximum size limit of 10MB to Ethereum blocks to prevent network instability and denial-of-service attacks. Currently, blocks can grow very large, which slows down network propagation and increases the risk of temporary forks. This limit ensures blocks stay within a reasonable size that the network can efficiently process and propagate.
Set default gas limit to 60M
This proposes increasing the gas limit from 36M to 60M to scale L1 execution capacity. While this change does not require a hard fork (gas limit is a validator-chosen parameter), it requires extensive testing to ensure network stability at higher computational loads and so inclusion of the EIP in the hard fork ensures that this work is prioritized and ongoing.
Count leading zeros (CLZ) opcode
This adds a new CLZ (Count Leading Zeros) opcode to the EVM that efficiently counts the number of zero bits at the start of a 256-bit number. This is a fundamental mathematical operation used in many algorithms, especially for mathematical computations, data compression, and cryptographic operations. Currently, implementing this operation in Solidity requires complex and expensive code - this opcode makes it much cheaper and faster.
Precompile for secp256r1 Curve Support
This adds support for a widely-used cryptographic curve called secp256r1 (also known as P-256) to Ethereum. Currently, Ethereum only supports the secp256k1 curve for signatures, but many devices and systems use secp256r1. This change allows Ethereum to verify signatures from devices like iPhones, Android phones, hardware wallets, and other systems that use this standard curve, making it easier to integrate with existing infrastructure. Note: This EIP supercedes [RIP-7212](https://github.com/ethereum/RIPs/blob/master/RIPS/rip-7212.md).