About EIP-7907

Contract size metering introduces a gas-based pricing model that allows developers to deploy larger smart contracts while ensuring network participants pay proportional costs for the additional resources these contracts consume. Currently, Ethereum enforces a hard 24KB limit on contract code size—a restriction that forces developers into workarounds that increase complexity and costs.

EIP-7907 changes this paradigm by:

• Doubling the hard limit from 24KB to 48KB for deployed contracts
• Adding gas metering that charges 4 gas per 32-byte word for code exceeding the original 24KB threshold
• Implementing warm/cold code states similar to storage access patterns introduced in EIP-2929
• Doubling the initialization code limit from 48KB to 96KB to maintain the established 2:1 ratio

The system works by tracking whether contract code has been loaded during transaction execution. When you call a contract larger than 24KB for the first time in a transaction, you pay additional gas proportional to the excess size. Subsequent calls to the same contract within that transaction avoid this cost because the code is already "warm."

How contract size metering works in practice

Consider three scenarios that demonstrate the practical impact of this change:

Scenario 1: Current 20KB Contract A developer deploys a decentralized exchange contract that's 20KB in size. Under both the current system and EIP-7907, calling this contract costs the standard gas amounts with no additional fees. The result is identical behavior for existing contracts.

Scenario 2: New 35KB Contract A developer wants to deploy a comprehensive DeFi protocol that would naturally fit in 35KB but currently requires splitting across multiple contracts. Under the current system, this deployment fails entirely. With EIP-7907, the deployment succeeds, and calling this contract incurs an additional cost of ceil32(35KB - 24KB) * 4 / 32 = 1,376 gas for the first call in each transaction.

Scenario 3: Complex Multi-Contract System A developer currently deploys a system across four 20KB contracts connected by proxy patterns. Users pay gas for multiple external calls between contracts. With EIP-7907, the same functionality could be deployed as a single 45KB contract, where users pay ceil32(45KB - 24KB) * 4 / 32 = 2,624 gas for the first call, but avoid the overhead of multiple external calls and proxy complexity.

Benefits of expanded contract limits

Simplified development experience

The primary advantage is architectural simplicity. Developers can focus on building functionality rather than engineering around size constraints. This means fewer proxy contracts, reduced delegatecall complexity, and elimination of artificial contract splitting. For example, a comprehensive token contract with built-in staking, governance, and liquidity features can now exist as a single, auditable unit rather than a complex system of interconnected contracts.

Reduced gas costs for complex operations

While larger contracts pay additional loading costs, they often reduce overall gas consumption by eliminating expensive external calls. A cross-contract function call costs at least 2,600 gas for account access plus the execution cost. By consolidating related functionality, developers can replace multiple external calls with internal function calls, which cost significantly less.

Enhanced security and auditability

Single-contract systems are easier to audit and reason about than multi-contract architectures. When related functionality exists in one contract, auditors can more easily trace execution paths and identify potential vulnerabilities. This reduces the attack surface that complex proxy patterns can introduce.

Future-proof architecture

The gas metering system automatically scales with network capacity. If Ethereum's gas limits increase, larger contracts become more economical to deploy and use. This creates a sustainable path for supporting increasingly sophisticated smart contract applications without requiring additional protocol changes.

Technical implementation

The implementation introduces a new warm/cold state specifically for contract code, separate from the existing account warming mechanism. When a transaction accesses a contract for the first time, the system:

1. Checks if the account is warm (previously accessed balance, storage, or included in access lists)
2. Determines if the code is warm (previously loaded during this transaction)
3. Calculates excess code costs using the formula: ceil32(max(0, code_size - 24KB)) * 4 / 32

The gas schedule becomes:

• Cold account and code: Add 2,600 + 2,100 + excess code costs
• Warm account, cold code: Add 100 + 2,100 + excess code costs
• Warm account and code: Add 100 (standard warm access cost)

The system also updates specific opcodes to reflect these costs:

• CALL, STATICCALL, DELEGATECALL, CALLCODE: Apply full metering when loading code
• EXTCODECOPY: Includes metering since full code loading is required for block witnesses
• EXTCODESIZE: Adds 2,100 gas for cold code access to prevent DOS attacks through codesize queries

Implementation considerations

Block size and network impact

Including larger contracts affects block propagation and storage requirements. Analysis shows that worst-case scenarios remain manageable. A block filled with maximum-sized contracts would create approximately 1.5MB of additional data, which falls within acceptable parameters for current network infrastructure. The devp2p protocol supports up to 10MB packets, providing substantial headroom.

Validation performance

The gas pricing reflects real computational costs. Benchmarks show that JUMPDEST analysis—the primary computational overhead for large contracts—scales linearly with code size. The 4 gas per word cost accounts for additional disk I/O, preprocessing overhead, and increased Merkle proof sizes that large contracts impose on the network.

Client implementation requirements

Clients must implement efficient code size determination without loading entire contracts during gas calculation. The specification recommends maintaining a separate table keyed by code hash to store code sizes, enabling accurate gas charging before physical code loading occurs.

Future implications

Enabling higher gas limits

More efficient contract architecture could support future gas limit increases. When contracts can consolidate functionality more effectively, the same gas budget supports more complex operations, potentially enabling higher throughput without compromising network security.

Simplifying development tools

Development frameworks like Foundry and Hardhat can eliminate size-optimization features focused on staying under the 24KB limit. This allows tooling to focus on functionality and security rather than artificial size constraints.

Foundation for advanced features

Larger contracts enable more sophisticated on-chain applications. Features like comprehensive governance systems, advanced DeFi protocols, and complex gaming logic become feasible as single-contract deployments rather than requiring complex multi-contract architectures.

Potential access list evolution

As block-level access lists (EIP-7928) potentially replace transaction-level access lists, the code warming mechanisms in EIP-7907 could evolve to integrate with block-level optimization, further improving performance for large contract systems.

Conclusion

EIP-7907 represents a fundamental improvement to Ethereum's contract deployment capabilities by intelligently balancing developer needs with network security. By doubling the contract size limit to 48KB and implementing proportional gas metering, this upgrade eliminates artificial constraints that force developers into complex architectural patterns.

The gas metering system ensures that larger contracts pay proportional costs for the additional resources they consume, maintaining network security while enabling more sophisticated applications. According to the technical analysis, the 4 gas per word cost accurately reflects the computational overhead of processing larger contracts, from disk I/O to JUMPDEST analysis.

This enhancement positions Ethereum to support increasingly complex smart contract applications while maintaining the security and decentralization that define the platform. As blockchain applications grow more sophisticated, EIP-7907 provides the foundation for sustainable contract development that scales with developer needs and network capacity.

Frequently asked questions

What is an EIP in Ethereum? EIP stands for Ethereum Improvement Proposal. These are technical documents that describe proposed changes to the Ethereum protocol, including new features, processes, or standards. EIPs serve as the primary mechanism for proposing protocol improvements and collecting community feedback before implementation.

How does EIP-7907 affect existing contracts? Existing contracts under 24KB experience no changes in gas costs or functionality. The additional metering only applies to new contracts exceeding the original 24KB limit, ensuring full backward compatibility.

What happens if I deploy a contract larger than 48KB? Deployment will fail. While the gas metering system could theoretically support contracts of any size, EIP-7907 maintains a hard 48KB limit to prevent unexpected interactions with network infrastructure, particularly the peer-to-peer protocol layer.

Why is the gas cost 4 per word for excess code? The 4 gas per word cost derives from current network economics: the existing cold account access cost (2,600 gas) divided by the maximum current contract size in words (24KB/32 = 768 words) equals approximately 4 gas per word. This ensures proportional pricing based on actual resource consumption.

How does this relate to Layer 2 scaling solutions? EIP-7907 complements Layer 2 scaling by improving the efficiency of the base layer. More efficient contract architecture on Layer 1 benefits Layer 2 systems that inherit security from the main chain, while larger contracts enable more sophisticated applications across both layers.

Why was 2 gas per word selected, and is that the same constant as INITCODE_WORD_COST from EIP-3860?

There appears to be a discrepancy in your question - the article specifies that EIP-7907 uses 4 gas per word for excess code, not 2 gas per word. This 4 gas per word cost is calculated based on current network economics: the existing cold account access cost (2,600 gas) divided by the maximum current contract size in words (768 words for 24KB) equals approximately 4 gas per word. This differs from EIP-3860's INITCODE_WORD_COST, which applies to initialization code validation, while EIP-7907's cost applies to runtime code loading for deployed contracts exceeding the original size limit.

Could devnet testing help for this EIP?

Yes, devnet testing would be valuable for EIP-7907 to validate the gas pricing model under real-world conditions, test client performance with larger contracts, and ensure the warm/cold code state tracking works correctly across different transaction patterns. Testing could also help verify that the block size impacts remain within acceptable parameters and that the integration with existing opcodes functions properly.

What kinds of applications stand to benefit the most—modular contracts, zkApps, account abstraction, rollups?

Comprehensive DeFi protocols combining multiple features (trading, lending, governance) would benefit significantly by avoiding complex proxy patterns. Account abstraction implementations could consolidate wallet logic, signature verification, and policy management in single contracts. Gaming applications requiring complex state management and rule enforcement would benefit from unified contract architecture. zkApps with substantial verification logic could reduce the complexity of splitting proof validation across multiple contracts. Rollups could potentially optimize their settlement contracts by consolidating related functionality.

How does this EIP relate (or not relate) to EIP-7702's delegated execution model?

EIP-7907 and EIP-7702 address different aspects of contract architecture. EIP-7907 focuses on enabling larger monolithic contracts through size limit increases and gas metering, while EIP-7702 enables externally owned accounts to delegate execution to contract code. These proposals are complementary rather than competing - EIP-7702 could benefit from EIP-7907 by allowing delegation to larger, more comprehensive contracts that consolidate multiple account abstraction features in a single deployment.

Is this EIP fully backward compatible? Could any existing tooling or contract deployment processes break under these new rules?

EIP-7907 is fully backward compatible for existing contracts under 24KB, which experience no changes in gas costs or functionality. However, deployment tooling may need updates to handle the new 48KB deployment limit and 96KB initialization code limit. Gas estimation tools will need to account for the new code loading costs when calling contracts exceeding 24KB. Development frameworks like Foundry and Hardhat can actually simplify by removing size-optimization features that were previously necessary to stay under the 24KB limit.