Abstract
This AIP proposes to upgrade Arbitrum One and Arbitrum Nova to ArbOS 50 Dia. Dia adds support for relevant Execution Layer (EL) changes from Ethereum’s upcoming Fusaka upgrade (Q4 2025), enabling EIP-2537, a few bug fixes, and a handful of new features, such as a new feature called Native Mint/Burn.
While the goal of the proposed ArbOS 50 Dia upgrade is to eventually be available for adoption by any Arbitrum Chain, this proposal only concerns the Arbitrum One and Arbitrum Nova chains, as these two chains are governed by the ArbitrumDAO. On a high level, an ArbOS upgrade can be interpreted as Arbitrum’s equivalent of a hard fork - more can be read about the subject here.
Please note that ArbOS Version 50 Dia is a proposed upgrade that builds upon ArbOS 40 Callisto, which has been previously adopted by the ArbitrumDAO - this proposal increments the version number to 50 instead of 4x due to technical details that allow for better Orbit chain customizability, as explained here.
Changes that will be included in ArbOS 50 Dia:
EIP-7951: Precompile for secp256r1 Curve Support
This EIP implements the same functionality and interface as RIP-7212, which was activated as part of ArbOS 31 Bianca. The main difference here is to add a point-at-infinity check and to update the comparison step in the signature verification algorithm. Developers should expect the same behavior as the EIP being proposed on Ethereum after Fusaka is activated.
EIP-7825: Transaction Gas Limit Cap
This EIP introduces a gas cap for individual transactions. The goal is to ensure fairer access to block space and improve network stability. For Arbitrum One & Arbitrum Nova we are proposing a 32 million gas limit (L2 execution gas, not including L1 gas) per transaction, which is the same as the current block gas limit. This 32 million gas limit diverges from the EIPs’ proposed limit of 16 million gas per transaction for Ethereum L1. Orbit chains can customize this value according to their chains’ needs.
EIP-7642: eth/69 - history expiry and simpler receipts
This networking upgrade removes deprecated fields used prior to Ethereum’s Proof of Stake (PoS) transition. We are including this EIP as part of GETH upstream. This is a networking change that impacts mainly L1 nodes. As arbitrum nodes do not have a P2P layer, we do not expect this to have any impact on arbitrum node operators.
EIP-7939: Count leading zeros (CLZ) opcode
This EIP adds a new CLZ (Count Leading Zeros) opcode to efficiently count 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.
EIP-7823: Set upper bounds for MODEXP
This EIP 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 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.
EIP-7883: ModExp Gas Cost Increase
This EIP 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 the costs for large inputs over 32 bytes.
EIP-7910: eth_config JSON-RPC Method
This EIP provides a new RPC method that allows the Arbitrum Nitro node to respond with key configuration variables, offering node operators the ability to gain greater confidence that their Nitro nodes are correctly configured and prepared for upcoming forks. In future Nitro releases, we expect to include additional fields specific to Arbitrum chains. This update is at the RPC level and may be enabled later than the ArbOS 50 Dia upgrade.
Enable EIP-2537: Precompile for BLS12-381 curve operations
As disclosed previously, the precompiled contracts for performing various operations over the BLS12-381 elliptic curve, including BLS signature verification, were added but not properly enabled in ArbOS 40 Callisto as originally expected. ArbOS 50 Dia will now enable EIP-2537.
ArbOS Block Limit Change “Effective Block Gas Limit”
Since ArbOS 50 introduces a MaxTxGasLimit, the State Transition Function (STF) will be relaxed in ArbOS 50 to allow the final transaction in a block to use up to the MaxTxGasLimit even if it would cause the block to exceed MaxBlockGasLimit. This means that the “Effective Block Gas Limit” is really MaxBlockGasLimit + MaxTxGasLimit. In previous versions of ArbOS, the sequencer would skip transactions if the transaction request’s GasLimit minus the L1 data posting gas exceeded the gas remaining in the block.
The new algorithm is more efficient because the sequencer doesn’t need to keep searching through the queue of transactions to find one that fits in the remaining block gas, and can continue to add transactions until the unused block gas is 0.
This change does not affect the GasTarget, and therefore does not affect how much overall gas per second the chain will use - only how transactions using that gas could be divided between different blocks.
A few bug fixes
- ArbOS Didn’t Get Updated For L1 Calldata Price Increase
- This change standardizes the calculation of gas units for compressed batch calldata across the codebase by replacing hard-coded values with a method call (tokenGasUnits).
- EIP-7702 Precompile Delegation Behavior Divergence
- Previously, calls to precompiles could execute an INVALID opcode instead of succeeding with no execution. ArbOS 50 Dia will update code to align with EIP-7702 spec to treat precompile code as empty during delegation.
A Constraint-Based Pricing Change: STF instrumentation to track multi-gas
We have instrumented Arbitrum’s State Transition Function (STF) to track gas usage across multiple resource types including computation, storage access, storage growth, and history growth, rather than only a single total based on opcodes. This work lays the foundation for dynamic, constraint-based pricing where gas fees can adjust based on the most constrained resource at the network level. The goal is to create more stable prices, improve responsiveness to spikes, and allow the network to safely increase throughput without overloading node hardware. In this release, none of the constraints are enabled, so there will be no impact on current gas prices. This update simply adds the ability to measure and record per-resource usage, with actual pricing changes coming in a later version once constraints are configured, benchmarked and tested.
To read more about this feature, go here.
Native Token Mint/Burn
Native Token Mint/Burn is a feature that allows Arbitrum chains to use interoperability-enabled token standards (e.g., LayerZero OFTs, xERC20s, native USDC) as native gas tokens on their chains. Currently, Arbitrum chains are designed to “lock and mint” native gas tokens on the chain’s canonical bridge. However, doing so means that these “locked and minted” native gas tokens cannot interact with third-party cross-chain adapter contracts. This new feature lets an Arbitrum chain delegate minting and burning of its native gas token to a trusted bridge provider (e.g., LayerZero OFT).
Native Token Mint/Burn is proposed to be included in ArbOS 50 Dia for the benefit of Arbitrum Orbit chains (reducing the need for forks) and to streamline development and testing into a single codebase. There are no plans to enable this feature on Arbitrum One or Arbitrum Nova, consequently this feature will be explicitly left disabled for Arbitrum One and Arbitrum Nova.
To read more about this feature, go here.
Fusaka EIPs that are not proposed to be in ArbOS 50 Dia
Support and implementation for the following EIPs are not planned to be part of ArbOS 50 Dia:
- EIP-7594, EIP-7918, and EIP-7892, since Arbitrum chains do not have blob data markets (though they do support posting blob data to a non-Arbitrum parent chain)
- EIP-7917, since Arbitrum chains do not have a beacon chain and therefore do not have a peer-to-peer layer like Ethereum does
- EIP-7934, this EIP is to help propagating blocks between nodes. Arbitrum doesn’t do that - it sends messages (which are limited) and each node builds every block by itself
- EIP-7907, since this EIP is no longer Scheduled For Inclusion (SFI) for Fusaka, as agreed upon by client teams during ACDE #216 on July 17, 2025. We are currently exploring alternative ways to increase the contract size limit that do not interfere with the ability for Arbitrum chains to support EIP-7907 in the future. Please see this forum post reply for more details about this.
- EIP-7935, since Arbitrum chains already have a default gas target of 28Mgas/s and we have separate, alternative plans for increasing the gas limit through other means, as mentioned here.
Steps to implement
More detailed information about the specific implementation and versions will be provided closer to the date of the formal on-chain Tally vote. However, this proposal will roughly follow the steps below:
- An AIP outlining the proposed upgrade and specification is proposed to the ArbitrumDAO forum for discussion (this post);
- A temperature check vote is held on Snapshot;
- Engineering work to scope out and implement the relevant changes for ArbOS 50 Dia into the Nitro node software, relevant rollup contracts, and associated upgrade actions (this work has already begun);
- A new version of Nitro and nitro-contracts, if necessary, are released that support ArbOS 50 Dia;
- A security audit of all ArbOS 50 Dia relevant changes is conducted by a third-party (Trail of Bits) and the audit report is published for public consumption;
- Should the Snapshot vote pass, ArbOS 50 Dia will be deployed to both private devnets & Arbitrum Sepolia for testing;
- A formal AIP is proposed to Tally for an on-chain vote;
- If the on-chain vote passes, ArbOS 50 Dia will be activated on Arbitrum One and on Arbitrum Nova following the required waiting periods and phases, as outlined in the ArbitrumDAO Constitution.
Note on Fusaka hard fork timelines:
Similar to the ArbOS 20 Atlas upgrade and the Ethereum Dencun hard fork in March 2024, the activation timestamp for ArbOS 50 Dia will be targeted for roughly the same timestamp as when Ethereum Mainnet hard forks. At the time of writing and as of the latest All Core Devs Consensus (ACDC) Call #165 held on September 18th, 2025, the tentative timestamp of the Ethereum Mainnet fork for Fusaka is targeted for the first week of December 2025. The tentative dates for Ethereum Sepolia and Ethereum Hoodi to upgrade to Fusaka are around mid October and late October, respectively. The exact slot for mainnet Ethereum has not yet been chosen.
Given that the L1 client teams released their Fusaka-supported versions on September 26, 2025 and that the required steps for a Constitutional AIP can take more than 35 days from when it is posted to Tally, there is a likelihood that ArbOS 50 Dia will be activated on Arbitrum One and Arbitrum Nova after Ethereum Mainnet upgrades to Fusaka (if the ArbitrumDAO votes to adopt this proposal). We endeavor to continue making updates to this proposal as timelines become more concrete.