[CONSTITUTIONAL] AIP: ArbOS Version 50 Dia

Proposals
1

Type: Constitutional AIP

UPDATED: October 24, 2025

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.

  • ARM / 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 here.

    • 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 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:

  1. An AIP outlining the proposed upgrade and specification is proposed to the ArbitrumDAO forum for discussion (this post);

  2. A temperature check vote is held on Snapshot;

  3. 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);

  4. A new version of Nitro and nitro-contracts, if necessary, are released that support ArbOS 50 Dia;

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

  6. Should the Snapshot vote pass, ArbOS 50 Dia will be deployed to both private devnets & Arbitrum Sepolia for testing;

  7. A formal AIP is proposed to Tally for an on-chain vote;

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

6 Likes
2

and if by the time of that onchain vote, we will still have enough active delegates voting, to be able to achieve the 4.5% constitutional quorum threshold that is required to have this proposal passed.

so please, the whole team at @offchainlabs, I beg you to delegate your vesting ARB tokens to active Arbitrum delegates that actually care and vote on proposals in this DAO.

you can find the most active ones and delegate to them, here: Delegates of Arbitrum DAO

1 Like
3

Hi, I have some questions:

  1. Question about this change EIP-7825: Transaction gas limit (32M gas for Arbitrum, as opposed to 16M on Ethereum)
    Unlike Ethereum, this proposes to make the transaction size equal to the block size, which makes this EIP completely pointless. Why use it then?
  2. Question on Dynamic Pricing / Multi-dimensional Gas Pricing
    I understand that now this parameter will only read information and will not affect the cost of transactions, but I see a certain attack vector here - namely setting the target to 0 - in this case, the price of all transactions will be very high and will greatly disrupt the operation of the entire chain.
    In this regard, I have a proposal - to introduce a limit on the minimum value - based on the results of testing and actual use
  3. It is strange that the possibility of using ARB as gas is implemented in any Orbit-chain, but not in Arbitrum itself. Why is it implemented in this way, without L2?
2 Likes
4

Hi, we have answered your questions below:

  1. There are two main goals for implementing this EIP, 1) Generally there’s a goal of minimizing the diff from Ethereum in order to reduce the complexity and risk of maintaining the software so there’s a bias towards implementing EIPs and 2) This change opens up the possibility of increasing the block gas limit of Arbitrum One in the future while maintaining the existing transaction gas limit.
  2. As mentioned in the proposal, the change here “simply adds the ability to measure and record per-resource usage, with actual pricing changes will be proposed in a later version once constraints are configured, benchmarked, and tested.” Benchmarking and testing are activities we intend to perform and use to set the minimum gas target. We want to emphasize again that the full implementation and activation of constraint-based pricing will be a separate ArbOS proposal in the future.
    We agree that setting a gas target of 0 would indeed lead to some undesirable consequences. However, in this release, there is no interface for a chain owner to configure or set these parameters and as such, no chance anyone using ArbOS 50 could accidentally set it to 0 or any other value.
  3. Arbitrum One was deployed with ETH as a gas token. This allows for the greatest alignment with Ethereum’s user and developer experience, as well as more efficient gas pricing and payment of parent chain settlement costs.
    Orbit chains and Arbitrum One use the same code base but can adopt different features. In this case, Arbitrum One is able to continue using ETH as a gas token, while Orbit chains that deploy can elect to use other custom gas tokens.
2 Likes
5

The ArbOS 50 proposal has progressed to Snapshot. Delegates can review and cast their vote at the following link: Snapshot Link

1 Like
6

isn’t that… too soon? with almost no discussion about it?

7

We need to be honest here – no one besides you and me has shown any interest in this topic over the past 10 days. I’ve asked my questions and received constructive answers.

I think we might be rushing a bit, since these changes are only scheduled to go live on mainnet in November – there’s still room for adjustments and revisions based on the outcomes of testing

1 Like
8

gm, I voted in favor on Snapshot since all the proposed changes seem reasonable to me.

The ability to mint/burn gas tokens was a market request, even if it carries important implications for the trust minimization of the L2 and with it it might bring some controversy/questions.

As I mentioned during the governance call, with the growing number of customizable elements in an Orbit chain (DA layer, gas token, ..), it would be handyl if OCL published an overview mapping the trust assumptions tied to each design choice. That would be a huge help for both builders and users.

Thanks!

1 Like
9

We are voting for this proposal.
As an Ethereum L2, we believe it is essential that Arbitrum keeps its protocol closely aligned with Ethereum’s roadmap and upgrades. ArbOS 50 Dia addresses the majority of the necessary changes required for the upcoming Fusaka hard fork, and we see this as a critical step to maintain strong compatibility with Ethereum at the protocol level.

The detailed evaluation of technical risks will take place after the upgrade is developed and audited. For now, we do not see such potential risks as a decisive concern during the discussion phase.

We also welcome the new features introduced, particularly Native Mint/Burn and the groundwork for multi-gas tracking. Native Mint/Burn represents an important advancement for optimizing the cross-chain user experience, while the multi-gas instrumentation is a meaningful preparation for a more adaptive and stable fee model in the future.

Finally, while it is unfortunate that EIP-7907 has been deferred, especially considering its relevance for advanced use cases such as FHE and Stylus, we remain optimistic about further progress on this front in future upgrades.

10

We are supporting ArbOS 50 Dia because it is a straightforward but critical upgrade that keeps Arbitrum aligned with Ethereum’s Fusaka fork. The package of bug fixes and cryptographic improvements strengthens protocol security, while the new instrumentation for multi-gas tracking prepares the network for more flexible fee models ahead. Overall, we see this upgrade as low-risk, necessary, and positioning Arbitrum for continued growth.

11

The following reflects the views of the Lampros DAO governance team, composed of Chain_L (@Blueweb) and @Euphoria, based on our combined research, analysis, and ideation.

We are voting FOR this proposal in the Snapshot voting.

Firstly, thank you to the @offchainlabs team for putting this together and engaging in the thread. We read the post end-to-end and compared the changes against what builders on One and Nova depend on today.

We agree with the direction. Staying close to Ethereum reduces maintenance risk, and enabling BLS12-381 and CLZ brings real wins for developers. Keeping the pricing work to measurement only is also a prudent choice at this stage.

Since the per-transaction cap equals the block limit, we kindly ask for a short note with recent chain data to back this choice: P95 and P99 gas used per transaction over the last 90 days, any instances where a single transaction filled most of a block, and a brief check that large single transactions do not impact sequencing fairness. If these numbers show headroom, the 32M setting is easy to support; if they suggest pressure, we can discuss a safer margin now rather than later.

Measuring first is the right approach. To help everyone review before any later activation, it would be helpful to expose a minimal telemetry surface for the new counters (compute, storage access, storage growth, history growth), either via JSON-RPC or a Prometheus endpoint, and to share a short outline of the activation playbook when you return: which parameters can change, how changes would roll out, what checks define “go / no-go,” and how a revert would work if needed. This keeps the next step predictable for node operators and the DAO.

We support including it in the codebase while keeping One and Nova unchanged. For completeness, please confirm there is no configuration path that could enable Mint/Burn on One or Nova in this release, and share the audit artifacts for the Dia diff when ready. For Orbit chains that opt in, a short operator checklist and the clean migration path if a bridge provider changes would be useful. A concise “assumptions matrix” that maps token/bridge choices to added trust would also help teams make informed decisions.

These fixes are welcome. A brief regression summary noting the test coverage and any expected effect on batch posting costs or node resource usage would make planning easier for infra teams. If there is no material impact, stating that clearly is helpful.

We understand activation could land after Fusaka due to constitutional timings. That is fine if the audit report, the RC metrics snapshot, and the upgrade notes are public before Tally.

12

I voted FOR on this proposal. It bundles several fixes and keeps Arbitrum in pace with Ethereum mainnet.

13

Τhank you for the proposal.

It is a very technical proposal, so it is difficult for non-technical delegates to thoroughly understand it. As a general idea, I am going to vote FOR on Snapshot as the proposal helps our ecosystem align with the L1 ecosystem (e.g. Ethereum).

Though I have some concerns/questions:

Won’t the simultaneous upgrade of all these components make the testing/verification process more difficult?
Also, regarding with the EIP-7939 are there any metrics about the statement:

Finally, I have the same question with @cp0x :

I know you answered it, but I would appreciate a more detailed explanation, if possible.

1 Like
14

As with other technical updates that have been voted on, I concede my knowledge is limited and put my trust into the teams ability to implement updates like this. Offchainlabs has shown to be technically proficient and the steps to implement include a security audit by a trusted third party. No reason for me not to trust the experts, and I’ll always be in favor of advancing the technology to remain competitive - voting to approve

1 Like
15

The following reflects the views of L2BEAT’s governance team, composed of @krst, @Sinkas, and @Manugotsuka, and it’s based on their combined research, fact-checking, and ideation.

We’re voting FOR the proposal.

As we’ve done with previous technical proposals, we asked L2BEAT’s research team to review the proposed upgrade and ensure that the changes are sensible. Since there were no major issues pointed out by our research team, we’re voting in favor.

One thing that caught our eye while reviewing was that we got a different hash:

docker run --rm --entrypoint cat nitro-node-dev-v50-alpha1 \\
target/machines/latest/module-root.txt

0x8aba3a51bf280d38b4612a329c11f753cc2b2db2d6a5638ca83b07b485c6fbc8

where it should be:

0x28cfd8d81613ce4ebe750e77bfd95d6d95d4f53240488095a11c1ad3a494fa82

But, given this is a pre-release and not the binding onchain executable, it’s not a blocker to our vote. We do commit to reviewing the calldata of the onchain proposal when the time comes to ensure that it aligns with the described changes.

2 Likes
16

EIP-7934 is not included in ArbOS 50. The EIP focuses on block propagation, which is not part of how Arbitrum chains operate; nodes build blocks locally from sequenced messages.

17 
The ability to mint/burn gas tokens was a market request, even if it carries important implications for the trust minimization of the L2 and with it it might bring some controversy/questions.

As mentioned in AIP, 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.

As I mentioned during the governance call, with the growing number of customizable elements in an Orbit chain (DA layer, gas token, ..), it would be handyl if OCL published an overview mapping the trust assumptions tied to each design choice. That would be a huge help for both builders and users. Thanks!

This suggestion is a great call out. Offchain Labs is already working on improved documentation for Orbit chain customization choices, and we appreciate any feedback

18

Since the per-transaction cap equals the block limit, we kindly ask for a short note with recent chain data to back this choice: P95 and P99 gas used per transaction over the last 90 days, any instances where a single transaction filled most of a block, and a brief check that large single transactions do not impact sequencing fairness. If these numbers show headroom, the 32M setting is easy to support; if they suggest pressure, we can discuss a safer margin now rather than later.

The current effective single transaction limit is already 32M gas (because that is the block gas limit and we don’t add any additional enforcement on the size of a single transaction). So, introducing the ability to limit a single transaction to that same size, is neutral with regards to sequencer fairness.

Measuring first is the right approach. To help everyone review before any later activation, it would be helpful to expose a minimal telemetry surface for the new counters (compute, storage access, storage growth, history growth), either via JSON-RPC or a Prometheus endpoint, and to share a short outline of the activation playbook when you return: which parameters can change, how changes would roll out, what checks define “go / no-go,” and how a revert would work if needed. This keeps the next step predictable for node operators and the DAO.

We would expect any Constraint-Based Pricing proposal to include in-depth documentation. For ArbOS 50, this change “simply adds the ability to measure and record per-resource usage, with actual pricing changes will be proposed in a later version.”

We support including it in the codebase while keeping One and Nova unchanged. For completeness, please confirm there is no configuration path that could enable Mint/Burn on One or Nova in this release, and share the audit artifacts for the Dia diff when ready. For Orbit chains that opt in, a short operator checklist and the clean migration path if a bridge provider changes would be useful. A concise “assumptions matrix” that maps token/bridge choices to added trust would also help teams make informed decisions.

A configuration path for Mint/Burn exists for Arbitrum One and Nova, as they draw from the same code base. Mint/Burn can only be enabled by the DAO or the Security Council. The DAO enabling the switch would incur a roundtrip governance proposal before starting the 7 day timelock. The Security Council’s use of the switch would initiate a 7 day timelock delay. The switch event is easily detectable and can be turned off at any time without delay by the Security Council.

An operator checklist and instructions for enablement are included in the docs for this feature. This feature is designed to prevent vendor lock-in, as a chain operator can list and delist the permissioned mint/burn contract at their will. The primary migration effort would take place between providers of the native cross-chain token itself, to ensure the token liquidity is migrated, which is out of scope of the chain’s function, but is something teams should be aware of. Teams should be aware of the trust implications of adopting a native cross-chain token and we highlight this in our docs as well.

These fixes are welcome. A brief regression summary noting the test coverage and any expected effect on batch posting costs or node resource usage would make planning easier for infra teams. If there is no material impact, stating that clearly is helpful.

The ArbOS 50 upgrade should not inherently cause changes to batch posting costs or node resource usage. However, to the extent that the BLS12-381 and secp256r1 precompiles are adopted by the market, it is possible that block validation could consume more CPU resources. If this occurs, it will appear as gradual organic CPU usage growth and not as a spike, so operators should be able to adjust resources gradually in response.

We understand activation could land after Fusaka due to constitutional timings. That is fine if the audit report, the RC metrics snapshot, and the upgrade notes are public before Tally.

Absolutely - these will be provided before the Tally proposal to activate ArbOS 50.

19

Won’t the simultaneous upgrade of all these components make the testing/verification process more difficult?

For Fusaka-related upgrades, these are all part of our GETH upstream and hence need to be merged together. The changes are being audited together as part of the same codebase.

Also, regarding with the EIP-7939 are there any metrics about the statement:

Currently, implementing this operation in Solidity requires complex and expensive code - this opcode makes it much cheaper and faster.

This EIP is being included as part of the Ethereum L1 Fusaka upgrade. The discussion and reasoning for this EIP is set forth in the Ethereum Magicians forum here: https://ethereum-magicians.org/t/eip-7939-create-a-new-opcode-for-counting-leading-zeros-clz/10805.

1 Like
20

One thing that caught our eye while reviewing was that we got a different hash:

docker run --rm --entrypoint cat nitro-node-dev-v50-alpha1 \\
target/machines/latest/module-root.txt

0x8aba3a51bf280d38b4612a329c11f753cc2b2db2d6a5638ca83b07b485c6fbc8

where it should be:

0x28cfd8d81613ce4ebe750e77bfd95d6d95d4f53240488095a11c1ad3a494fa82

For the alpha release, the wasm module root from an arm64 build was errantly posted instead of amd64. As part of RCs and the final version, the reproducibility of WASM module roots will be ensured.