EIP-7903 Stagnant EL

Remove Initcode Size Limit

Authors:

Canonical data: /latest/eips/7903.json

Removes the initcode size limit introduced in EIP-3860

Timeline

Glamsterdam

Charles Cooper

Declined · Jan 15, 2026 · ACDE #228

Jan 15, 2026 · ACDE #228

Proposed

Fusaka

Declined

EIP Created Mar 5, 2025

Key Benefits

● Smoother deployment of big projects, no more extra tooling needed.
● Developer experience is much more straightforward and follows industry standarts.

Trade-offs & Considerations

No trade-offs documented yet.

Stakeholder Impact

End Users

Not a direct impact on regular usage. But users who investage how was the contract setup and verifying what they interact it will have it more straightforward.

Application Developers

Developers will hugely benefit from this change, especially when deploying big set of contracts with complex initialization. No workarounds and less complexity, only straight forward setup even for complex projects.

Wallet Developers

No direct impact on wallet devs. If wallets have onchain infrastracture, their developers might benefit from easier deployments.

Tooling / Infrastructure

Explorers need to be able to display the bigger initcode.

Layer 2s

EVM-equivalent need to implement the change to follow the execution layer specification.

Stakers & Node Operators

Node operators shouldn't notice a direct change because the bigger initcode still fits in the same block size. Over the time, stored initcode will take bigger part of the disk space.

CL Client Developers

No consensus changes expected for CL; only standard fork coordination.

EL Client Developers

EL clients implementation is simple, only removes or changes the hardcoded size limit.

North Star Goal Alignment

● Improve UX: Contract developers deploying big projects will have much easier life and users can also verify contracts they interact with more easily.

Abstract

This EIP proposes the removal of the initcode size limit of 49152 bytes introduced in EIP-3860. The restriction complicates deploying multiple contracts addressing the EIP-170 limit (24576 bytes) within a single transaction, while the existing gas metering for initcode, already ensures fair initcode costing, including for JUMPDEST analysis.

Motivation

The EIP-3860 initcode size limit imposes an unnecessary constraint on deployment patterns, particularly for creation transactions creating large logical contracts composed of multiple physical sub-contracts in a single transaction. A key argument for retaining EIP-170's 24KB runtime code limit is that high-level languages (HLLs) should abstract it away. However, the EIP-3860 limit prevents HLLs from cleanly abstracting this, as deploying large logical contracts exceeding 49152 bytes of initcode requires splitting into multiple transactions, undermining the abstraction.

Removing the cap simplifies smart contract deployment and enables HLLs to cleanly abstract large contracts, without compromising network security or cost attribution.

Specification

Revert the initcode size limit introduced in EIP-3860. Specifically:

Remove the 49152-byte cap on initcode size during contract creation.
Retain existing gas costs for initcode execution, including the 2 gas per byte for JUMPDEST analysis, as defined in EIP-3860.

No changes to deployed contract size limits (EIP-170) or gas schedules beyond removing the size restriction are proposed.

Rationale

This proposal is driven by the need to restore flexibility in contract deployment patterns, such as factory contracts creating multiple sub-contracts in one transaction. The design decision to remove the 49152-byte cap leverages the pre-existing gas metering system, which scales linearly with initcode size (i.e., 2 gas per byte), ensuring fair cost attribution without artificial limits.

A key justification for EIP-170's 24576-byte limit is that high-level languages (HLLs) should abstract it away. However, EIP-3860's initcode cap undermines this by forcing multi-transaction deployments for large contracts, breaking the abstraction HLLs aim to provide. Removing the cap aligns with this philosophy by enabling single-transaction deployments.

Alternative designs, such as increasing the cap (e.g., to 98304 bytes), were considered but rejected as arbitrary; gas metering already mitigates resource concerns. The per-block gas limit already naturally restricts initcode (at the current gas limit of 35 million, initcode is restricted to ~16mb). Furthermore, initcode has additional implied costs - it must have already been paid for via calldata or memory expansion, limiting it even more.

Backwards Compatibility

This change is fully backwards compatible. Existing contracts and transactions remain unaffected, as the proposal only lifts a restriction without altering execution semantics or gas costs.

Test Cases

Security Considerations

No new security risks are introduced. The current gas schedule already mitigates denial-of-service concerns by charging per-byte for initcode. Benchmarks were performed, and ns/byte remained consistent across a range of different bytecodes, ranging from 128 bytes to 15MB.