Skip to main content

ArbOS 50 Dia

This page summarize what changes with ArbOS 50 Dia, and what you should do to ensure a seamless upgrade.

This page is intended for all Arbitrum (Orbit) chains and validator node operators.

Warning

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

ACTION REQUIRED

Before Ethereum Parent chain Sepolia and mainnet upgrade to Fusaka, (1) Nitro node operators need to make sure they connect to a parent chain Ethereum Beacon Chain node that has historical blob data, and (2) must upgrade to Nitro v3.8.0-rc.7 or higher, for the Nitro node software to function properly. Read more about the required actions.

The minimum Nitro version that supports ArbOS 50 "Dia" is Nitro v3.9.0, which is available on Docker Hub with the image tag Need to update - offchainlabs/nitro-node:v3.8.0-rc.5-6c74ee2-validator. This release of Nitro is a mandatory upgrade for Arbitrum One and Nova validators. For Arbitrum One and Nova, the ArbOS 50 "Dia" upgrade will require a governance vote to activate.

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.

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 Need to update - offchainlabs/nitro-node:v3.8.0-rc.5-6c74ee2-validator.

    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.0 or higher

    If your chain isn't ready to activate BoLD, use nitro-contracts v2.1.3 instead; v3.0.0 or higher can't be used without activating BoLD.

  • WASM module root: Need to update - 0xb90895a56a59c0267c2004a0e103ad725bd98d5a05c3262806ab4ccb3f997558

High-level description of ArbOS 50 changes

ArbOS 50 Dia is an upgrade to enable Arbitrum's support for the parent chain Ethereum's Fusaka upgrade 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:

EIPDescription
EIP-7951: Precompile for secp256r1 curve supportThis 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 capThis 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 receiptsThis 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) opcodeThis 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 ModExpThis 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 increaseThis 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 methodThis 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 operationsAs 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.

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 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, see the native mint and burn enablement guide.

Warning

If you want to enable native token mint and burn for your chain, use nitro-contracts v3.1.1 instead.

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:

EIPDescription
EIP-7594, EIP-7918, and EIP-7892Arbitrum chains don't have blob data markets (though they do support posting blob data to a non-Arbitrum parent chain)
EIP-7917Arbitrum chains don't have a beacon chain and therefore don't have a peer-to-peer layer like Ethereum does
EIP-7934This 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-7907This 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-7935Arbitrum 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.

Raise the gas target & implement improvements to the pricing algorithm

TODO

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.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.

This link is broken, it's a placeholder for the upcoming Nitro v3.9.0 release