Skip to main content

ArbOS 50 Dia

Note

ArbOS 50 Dia is still pre-release. This document may change.

This page is intended for all Arbitrum node operators and Arbitrum chain owners chains. This page summarizes the changes brought by ArbOS 50 Dia, and what you should do to ensure a seamless upgrade.

Action Required

Before Ethereum Parent chain Sepolia and Mainnet upgrade to Fusaka: ensure that your Nitro node version is upgraded and consensus layer client is configured as per the Fusaka upgrade notice.

The minimum Nitro version that supports ArbOS 50 "Dia" is Nitro v3.9.0, which is available on Docker Hub with the image tag Noffchainlabs/nitro-node:v3.9.0-cca645a. This release of Nitro is a mandatory upgrade for Arbitrum One and Nova node operators if adopted. For Arbitrum One and Nova, the ArbOS 50 "Dia" upgrade will require a governance vote to activate.

As a refresher, ArbOS upgrades get treated as Arbitrum's equivalent of a hard fork. To learn more, refer to the Arbitrum ArbOS upgrades forum post. Note that ArbOS 50 Dia is an upgrade that builds upon ArbOS 40 Callisto.

Requirements​

  • Having read and understood the ArbOS Software Releases Overview page.
  • Running Nitro v3.9.0 or higher, which is available on Docker Hub with the image tag offchainlabs/nitro-node:v3.9.0-cca645a.
    • Note that it's important to run Nitro v3.9.0 only against trusted databases. If you want to use an untrusted database, you can first remove the wasm directory if it exists (potentially inside the nitro folder). Otherwise, the database may have malicious, unvalidated code that can result in remote code execution. Avoiding unvalidated code is also mitigated by ensuring you run the Arbitrum Nitro node inside Docker.
  • Running nitro-contracts v3.1.X (e.g. nitro-contracts v3.1.1) or higher
  • WASM module root: 0x2c54f6e9e378ba320ed9c713a1d9f067a572b1437e4f1c40b1a915d3066c04f2
  • If the Arbitrum chain posts blobs to a Fusaka-enabled parent chain, ensure that the consensus layer client is configured correctly as per the Fusaka upgrade notice.

High-level description of ArbOS 50 changes​

ArbOS 50 Dia is an upgrade to support the relevant EVM changes that are a part of Ethereum's Fusaka upgrade. Ethereum's mainnet upgrade to Fusaka is tentatively scheduled for December 3, 2025 at epoch 411392. As a result, the majority of the ArbOS-specific changes revolve around implementing the relevant Fusaka EIPs on Arbitrum Chains.

Here's the list of all changes 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 and Arbitrum Nova we're proposing a 32 million gas limit (Child chain execution gas, not including parent chain gas) per transaction, which is the same as the current block gas limit. This 32 million gas limit diverges from the EIP's proposed limit of 16 million gas per transaction for Ethereum parent chain. 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're including this EIP as part of Geth upstream. This is a networking change that impacts mainly parent chain nodes. As Arbitrum nodes don't have a P2P layer, we don't 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 an 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.

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 parent chain 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 doesn't affect the GasTarget, and therefore doesn't 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 parent chain 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.
  • ARM and x86 divergence
    • This change adds a map to store transaction hash along with its gas used to bypass transaction execution for a problematic transaction execution which diverged between ARM and x86 architectures. This was added in to hardcode one transaction that caused the divergence on Arbitrum Sepolia, as disclosed in the security council emergency Action report.
    • The default WASM Stack Depth value in ArbOS is now set to 22,000, preventing new chains from encountering the same divergence issue.

Raising the gas target, increasing the min L2 base fee, & improving the pricing algorithm​

As part of our strategy for scaling Arbitrum technology, the ArbOS 50 release includes a slight change to improve the pricing algorithm for Arbitrum One and Nova. This improvement is aimed at reducing the severity, frequency, and duration of high L2 gas prices during periods of elevated demand on the network. Concretely, the changes are to:

  • Replace the current single gas target and single adjustment window, with a new model that employs multiple (higher) gas targets, measured over multiple adjustment windows.
  • Increase the default minimum L2 base fee from 0.01 gwei per gas to 0.02 gwei per gas.

To read more about this change, see the AIP for raising the gas target & improvements to the pricing algorithm.

A constraint-based pricing change: STF instrumentation to track multi-gas​

We've 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 won't be any 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, see the dynamic pricing explainer.

Native token mint and burn​

Native token mint and 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 can't 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 and burn is 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, see the Native Token Mint/Burn enablement guide.

Warning

If you want to enable Native Token Mint/Burn capabilities for your chain, you must use nitro-contracts v3.1.1 or higher.

Fusaka EIPs that aren't proposed to be in ArbOS 50 Dia​

Support and implementation for the following EIPs aren't planned to be part of ArbOS 50 Dia:

  • EIP-7594, EIP-7918, and EIP-7892, since Arbitrum chains don't have blob data markets (though they do support posting blob data to a non-Arbitrum parent chain)
  • EIP-7917, since Arbitrum chains don't have a beacon chain and therefore don't 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, 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're currently exploring alternative ways to increase the Smart Contract size limit that don't interfere with the ability for Arbitrum chains to support EIP-7907 in the future. 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 in Scaling Arbitrum everywhere.

Special note about ArbOS 50 Dia for chains that haven't yet upgraded to use Arbitrum BoLD​

While ArbOS 50 Dia will be compatible with both nitro-contracts 3.1.X and nitro-contracts 2.1.3, only chains that have Arbitrum BoLD enabled can use nitro-contracts 3.x. This requirement means that if your chain hasn't yet upgraded to use BoLD, only use nitro-contracts 2.1.3 for your ArbOS 50 Dia upgrade.