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.
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.
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.
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.
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.
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.
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.
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.
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 Didn’t Get Updated For L1 Calldata Price Increase
EIP-7702 Precompile Delegation Behavior Divergence
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 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.
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 Sc
... please visit link below to view full proposal
https://snapshot.org/#/arbitrumfoundation.eth/proposal/0x33754da4006d0ef38666ec5d5e85fd0966a891a594ab9dc21f23beedea2d330b