---
eip: 7903
title: Remove Initcode Size Limit
description: Removes the initcode size limit introduced in EIP-3860
author: Charles Cooper (@charles-cooper)
discussions-to: https://ethereum-magicians.org/t/remove-initcode-size-limit/23066
status: Stagnant
type: Standards Track
category: Core
created: 2025-03-05
requires: 170, 3860
---

## Abstract

This EIP proposes the removal of the `initcode` size limit of 49152 bytes introduced in [EIP-3860](./eip-3860). The restriction complicates deploying multiple contracts addressing the [EIP-170](./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.

## Copyright

Copyright and related rights waived via CC0.