Hello cupofjoseph!
As the core development team behind Arbitrum technology and Prysm, an L1 Ethereum consensus client software, we’d like to comment on this proposal from a technical perspective.
Arbitrum was built to scale Ethereum. As such, we will strive to help maintain and evolve the Arbitrum tech stack consistent with L1 Ethereum’s roadmap. This includes ensuring compatibility with all of L1 Ethereum’s hard forks and associated EIPs - all of which are collectively agreed upon for formal adoption by the L1 Ethereum Core Development Teams. To that end, much like ArbOS 20 Atlas for Dencun and ArbOS 40 Callisto for Pectra, we expect a future ArbOS upgrade for Fusaka to be proposed to the ArbitrumDAO and developed for mainnet deployment on Arbitrum One and Nova.
Unfortunately, at the time of writing, EIP-7907 has formally been *dropped* from Fusaka’s scope during ACDE #216 on July 17, 2025 and so we currently do not expect EIP-7907, in its current form, to be included in the next ArbOS release. This decision was made due to concerns from a few of the Ethereum Core Development teams for this particular EIP, specifically around how the transaction gas limit could be a limiting factor for the higher contract code size limit. As noted in the All Core Developers Testing (ACDT) #44 call on Monday July 14 2025, most of the Ethereum Core Development teams agree that more testing and benchmarking is desired.
We generally agree with the rationale you and the authors of EIP-7907 have written about for increasing the contract code size limit, and we would certainly be supportive of a change to raise the contract code size limit for Arbitrum chains. For Arbitrum developers and builders, especially those utilizing Stylus, the 24KB contract size limit inherited from L1 Ethereum restricts many use cases that require large contracts. An example of one such use case is Fully Homomorphic Encryption (FHE) operations, often implemented using Rust libraries that end up taking a large amount of storage space, leaving little room for the rest of the smart contract’s logic and functionality. We recognize this as a pain point and agree that a solution to increase the contract code size limit would be beneficial to these builders, regardless of the exact implementation (i.e. whether it be EIP-7907 or some modified version).
To that end, and given that EIP-7907 is no longer part of Fusaka, our team has begun thinking through alternative ways to alleviate the pain points encountered by developers at the current 24KB contract size limit. Specifically, we would like to think about approaches that do not interfere with Arbitrum’s ability to adopt EIP-7907 in the future, should this EIP be part of Glamsterdam in 2026.
Further discussions, feedback and others’ thinking are welcome on how to best address this pain point that you have highlighted for Arbitrum builders.
Thank you!
Offchain Labs