Type: Constitutional AIP
This AIP proposes the activation of ArbOS 51: Dia on Arbitrum One and Arbitrum Nova as well as increases to the gas target and min L2 base fee, along with changes to the L2 pricing algorithm. This on-chain vote proposes to bundle together the following two temperature check votes:
The combination of ArbOS 51 and the gas-target/pricing updates will ship as a single integrated release, designated ArbOS 51, which supersedes the originally planned standalone activation of ArbOS 50.
Since the ArbitrumDAO has already signaled support for the adoption of the above two AIPs in their respective temperature check votes, this on-chain vote will bundle both of these AIPs for activation on Arbitrum One and Arbitrum Nova with the ArbOS 51 release. Please visit the forum posts for each of the AIPs to learn more.
The ArbOS 51 release builds upon ArbOS 40 Callisto and will be shipped as a new mandatory Nitro release and new versions of the rollup contracts for Arbitrum One and Arbitrum Nova, should the ArbitrumDAO vote to pass this proposal. This proposal increments the ArbOS version number to 5x instead of 4x due to technical details that allow for better Orbit chain customizability, as explained here.
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.
ArbOS 51 Dia enables full Fusaka compatibility while introducing native Arbitrum improvements. Visit the original Forum Post to read more details about the proposed changes. Key components include of this ArbOS 51 release include:
The below list of Fusaka-related EIPs are not proposed to be included or supported in ArbOS 51 Dia. Visit the original Forum Post to read more details about these EIPs and our decision not to propose them for inclusion in ArbOS 51:
As part of our strategy for scaling Arbitrum technology, this proposal includes the AIP to improve the pricing algorithm for Arbitrum One and Nova to reduce the severity, frequency, and duration of high L2 gas prices during periods of elevated demand on the network. Concretely, the proposed changes are to:
The rationale for this change, alongside details on the specifications and supporting data, can be found here in the original AIP.
All of the above changes are implemented in a release of Arbitrum Nitro and will be shipped via two separate upgrades: a Nitro node version upgrade and an update with the on-chain rollup contracts on Arbitrum One and Arbitrum Nova. Should this proposal pass, the payload will be executed on-chain and will include the relevant on-chain contract changes, updating the WASM module root, and scheduling of the ArbOS upgrade. The proposed payload changes assume that the Nitro node software for all node operators and validators for Arbitrum One and Arbitrum Nova are updated to a version that supports ArbOS 51.
Audit reports
An independent, third-party audit by Trail of Bits has been completed and the results from the audit can be found below:
Proposal payload activation details and dates
Note that should this vote pass, the proposal payload here will trigger the activation of ArbOS 51 at epoch timestamp 17:00:00 UTC on Thursday, January 8, 2026, which is the last step in the implementation process for Constitutional AIPs, as outlined here. This specific date was chosen so that large, complex upgrades (like ArbOS upgrades) can be done so when members from the Arbitrum Foundation, Offchain Labs, and ArbitrumDAO Security Council, are available to assist if necessary.
Verifying the ArbOS 51 code difference
Type: Constitutional AIP
This AIP proposes the activation of ArbOS 51: Dia on Arbitrum One and Arbitrum Nova as well as increases to the gas target and min L2 base fee, along with changes to the L2 pricing algorithm. This on-chain vote proposes to bundle together the following two temperature check votes:
The combination of ArbOS 51 and the gas-target/pricing updates will ship as a single integrated release, designated ArbOS 51, which supersedes the originally planned standalone activation of ArbOS 50.
Since the ArbitrumDAO has already signaled support for the adoption of the above two AIPs in their respective temperature check votes, this on-chain vote will bundle both of these AIPs for activation on Arbitrum One and Arbitrum Nova with the ArbOS 51 release. Please visit the forum posts for each of the AIPs to learn more.
The ArbOS 51 release builds upon ArbOS 40 Callisto and will be shipped as a new mandatory Nitro release and new versions of the rollup contracts for Arbitrum One and Arbitrum Nova, should the ArbitrumDAO vote to pass this proposal. This proposal increments the ArbOS version number to 5x instead of 4x due to technical details that allow for better Orbit chain customizability, as explained here.
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.
ArbOS 51 Dia enables full Fusaka compatibility while introducing native Arbitrum improvements. Visit the original Forum Post to read more details about the proposed changes. Key components include of this ArbOS 51 release include:
The below list of Fusaka-related EIPs are not proposed to be included or supported in ArbOS 51 Dia. Visit the original Forum Post to read more details about these EIPs and our decision not to propose them for inclusion in ArbOS 51:
As part of our strategy for scaling Arbitrum technology, this proposal includes the AIP to improve the pricing algorithm for Arbitrum One and Nova to reduce the severity, frequency, and duration of high L2 gas prices during periods of elevated demand on the network. Concretely, the proposed changes are to:
The rationale for this change, alongside details on the specifications and supporting data, can be found here in the original AIP.
All of the above changes are implemented in a release of Arbitrum Nitro and will be shipped via two separate upgrades: a Nitro node version upgrade and an update with the on-chain rollup contracts on Arbitrum One and Arbitrum Nova. Should this proposal pass, the payload will be executed on-chain and will include the relevant on-chain contract changes, updating the WASM module root, and scheduling of the ArbOS upgrade. The proposed payload changes assume that the Nitro node software for all node operators and validators for Arbitrum One and Arbitrum Nova are updated to a version that supports ArbOS 51.
Audit reports
An independent, third-party audit by Trail of Bits has been completed and the results from the audit can be found below:
Proposal payload activation details and dates
Note that should this vote pass, the proposal payload here will trigger the activation of ArbOS 51 at epoch timestamp 17:00:00 UTC on Thursday, January 8, 2026, which is the last step in the implementation process for Constitutional AIPs, as outlined here. This specific date was chosen so that large, complex upgrades (like ArbOS upgrades) can be done so when members from the Arbitrum Foundation, Offchain Labs, and ArbitrumDAO Security Council, are available to assist if necessary.
Verifying the ArbOS 51 code difference
The Event Horizon Community voted FOR on this Proposal (ehARB-143): EventHorizon.vote/vote/arbitrum/ehARB-143
this keeps Arbitrum aligned with Ethereum, as it should be.
For. Activating ArbOS 51 enhances efficiency, incorporates crucial gas pricing updates, and aligns with promoting positive social outcomes within the Arbitrum ecosystem and technological facilitation.
https://forum.arbitrum.foundation/t/aip-raise-the-gas-target-min-l2-base-fee-implement-improvements-to-the-pricing-algorithm/30182/32
The Event Horizon Community voted FOR on this Proposal (ehARB-143): EventHorizon.vote/vote/arbitrum/ehARB-143
this keeps Arbitrum aligned with Ethereum, as it should be.
For. Activating ArbOS 51 enhances efficiency, incorporates crucial gas pricing updates, and aligns with promoting positive social outcomes within the Arbitrum ecosystem and technological facilitation.
https://forum.arbitrum.foundation/t/aip-raise-the-gas-target-min-l2-base-fee-implement-improvements-to-the-pricing-algorithm/30182/32
https://forum.arbitrum.foundation/t/blockful-delegate-communication-thread/29901/2?u=blockful
https://forum.arbitrum.foundation/t/constitutional-aip-arbos-version-50-dia/29835/33
https://forum.arbitrum.foundation/t/lampros-dao-delegate-communication-thread/26642/56?u=euphoria
https://forum.arbitrum.foundation/t/tekr0x-eth-delegate-communication-thread/24804/25?u=tekr0x.eth
https://forum.arbitrum.foundation/t/curia-delegate-communication-thread/23600/47
https://forum.arbitrum.foundation/t/constitutional-aip-arbos-version-50-dia/29835/15
https://forum.arbitrum.foundation/t/constitutional-aip-arbos-version-50-dia/29835/14?u=bob-rossi
The Event Horizon Community voted on this proposal (ehARB-128): EventHorizon.vote/vote/arbitrum/ehARB-128
The Event Horizon Community voted FOR on this proposal (ehARB-128): EventHorizon.vote/vote/arbitrum/ehARB-128
For. Adopting Fusaka ensures Arbitrum continues to leverage distributed tech, positive-sum collaboration with Ethereum, and drives adoption with up-to-date tech.
https://forum.arbitrum.foundation/t/constitutional-aip-arbos-version-50-dia/29835/13
https://forum.arbitrum.foundation/t/blockful-delegate-communication-thread/29901/2?u=blockful
https://forum.arbitrum.foundation/t/constitutional-aip-arbos-version-50-dia/29835/11?u=euphoria
https://forum.arbitrum.foundation/t/constitutional-aip-arbos-version-50-dia/29835/10
https://forum.arbitrum.foundation/t/tekr0x-eth-delegate-communication-thread/24804/21
there hasn't been enough discussion on this proposal... it's way too soon to bring it to a vote.
https://forum.arbitrum.foundation/t/blockful-delegate-communication-thread/29901/2?u=blockful
https://forum.arbitrum.foundation/t/constitutional-aip-arbos-version-50-dia/29835/33
https://forum.arbitrum.foundation/t/lampros-dao-delegate-communication-thread/26642/56?u=euphoria
https://forum.arbitrum.foundation/t/tekr0x-eth-delegate-communication-thread/24804/25?u=tekr0x.eth
https://forum.arbitrum.foundation/t/curia-delegate-communication-thread/23600/47
https://forum.arbitrum.foundation/t/constitutional-aip-arbos-version-50-dia/29835/15
https://forum.arbitrum.foundation/t/constitutional-aip-arbos-version-50-dia/29835/14?u=bob-rossi
The Event Horizon Community voted on this proposal (ehARB-128): EventHorizon.vote/vote/arbitrum/ehARB-128
The Event Horizon Community voted FOR on this proposal (ehARB-128): EventHorizon.vote/vote/arbitrum/ehARB-128
For. Adopting Fusaka ensures Arbitrum continues to leverage distributed tech, positive-sum collaboration with Ethereum, and drives adoption with up-to-date tech.
https://forum.arbitrum.foundation/t/constitutional-aip-arbos-version-50-dia/29835/13
https://forum.arbitrum.foundation/t/blockful-delegate-communication-thread/29901/2?u=blockful
https://forum.arbitrum.foundation/t/constitutional-aip-arbos-version-50-dia/29835/11?u=euphoria
https://forum.arbitrum.foundation/t/constitutional-aip-arbos-version-50-dia/29835/10
https://forum.arbitrum.foundation/t/tekr0x-eth-delegate-communication-thread/24804/21
there hasn't been enough discussion on this proposal... it's way too soon to bring it to a vote.
I voted FOR this proposal because it improves Arbitrum and keeps it aligned with Ethereum.
I voted FOR this proposal because it improves Arbitrum and keeps it aligned with Ethereum.
Thanks for raising this. Offchain Labs has independently validated the payload to ensure it matches the intent and scope described in the two Snapshot approvals. For transparency, the payload-generation steps, simulation outputs, and code-diff verification instructions are publicly documented here:
• Payload generation + simulation results: https://github.com/ArbitrumFoundation/governance/pull/366
Thanks for raising this. Offchain Labs has independently validated the payload to ensure it matches the intent and scope described in the two Snapshot approvals. For transparency, the payload-generation steps, simulation outputs, and code-diff verification instructions are publicly documented here:
• Payload generation + simulation results: https://github.com/ArbitrumFoundation/governance/pull/366
• ArbOS 51 code-difference verification guide: https://arbitrum.notion.site/Verifying-the-ArbOS-51-Code-Difference-2a501a3f59f8804cb0a0f9a460020a9d.
We encourage all delegates to perform their own verification.
We have added a new fix to accompany ArbOS50 Version Dia. This forum post has been updated.
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.
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
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.
Support and implementation for the following EIPs are not planned to be part of ArbOS 50 Dia:
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:
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.
This looks like a big step forward. I like how ArbOS 50 Dia lines up with Ethereum’s Fusaka upgrade while also adding things that directly improve how Arbitrum runs.
The gas limit cap and the efficiency tweaks make a lot of sense, and enabling EIP-2537 feels long overdue.
The Native Mint/Burn feature is also a smart move for Orbit chains. Excited to see how this upgrade smooths things out for both devs and users.
Noting a scope change: ArbOS 50 now introduces an “Effective Block Gas Limit,” defined as MaxBlockGasLimit + MaxTxGasLimit. This update has been incorporated into the post above.
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.txt0x8aba3a51bf280d38b4612a329c11f753cc2b2db2d6a5638ca83b07b485c6fbc8
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.
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.
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.
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.
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.
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.
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.
Thanks for raising this. Offchain Labs has independently validated the payload to ensure it matches the intent and scope described in the two Snapshot approvals. For transparency, the payload-generation steps, simulation outputs, and code-diff verification instructions are publicly documented here:
• Payload generation + simulation results: https://github.com/ArbitrumFoundation/governance/pull/366
Thanks for raising this. Offchain Labs has independently validated the payload to ensure it matches the intent and scope described in the two Snapshot approvals. For transparency, the payload-generation steps, simulation outputs, and code-diff verification instructions are publicly documented here:
• Payload generation + simulation results: https://github.com/ArbitrumFoundation/governance/pull/366
• ArbOS 51 code-difference verification guide: https://arbitrum.notion.site/Verifying-the-ArbOS-51-Code-Difference-2a501a3f59f8804cb0a0f9a460020a9d.
We encourage all delegates to perform their own verification.
We have added a new fix to accompany ArbOS50 Version Dia. This forum post has been updated.
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.
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
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.
Support and implementation for the following EIPs are not planned to be part of ArbOS 50 Dia:
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:
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.
This looks like a big step forward. I like how ArbOS 50 Dia lines up with Ethereum’s Fusaka upgrade while also adding things that directly improve how Arbitrum runs.
The gas limit cap and the efficiency tweaks make a lot of sense, and enabling EIP-2537 feels long overdue.
The Native Mint/Burn feature is also a smart move for Orbit chains. Excited to see how this upgrade smooths things out for both devs and users.
Noting a scope change: ArbOS 50 now introduces an “Effective Block Gas Limit,” defined as MaxBlockGasLimit + MaxTxGasLimit. This update has been incorporated into the post above.
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.txt0x8aba3a51bf280d38b4612a329c11f753cc2b2db2d6a5638ca83b07b485c6fbc8
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.
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.
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.
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.
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.
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.
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.
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
Tentative timelines of this AIP were updated based on L1 Client releases on September 26th, and the the updated tentative timeline for L1 Fusaka upgrades provided in All Core Devs Consensus (ACDC) Call #165 held on September 18th, 2025.
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
Tentative timelines of this AIP were updated based on L1 Client releases on September 26th, and the the updated tentative timeline for L1 Fusaka upgrades provided in All Core Devs Consensus (ACDC) Call #165 held on September 18th, 2025.
The ArbOS 50 proposal has progressed to Snapshot. Delegates can review and cast their vote at the following link: Snapshot Link
Hi, we have answered your questions below:
The ArbOS 50 proposal has progressed to Snapshot. Delegates can review and cast their vote at the following link: Snapshot Link
Hi, we have answered your questions below:
Voting For as this seems like a no-brainer update to optimize Arbitrum and maintain Ethereum alignment.
I voted FOR as this proposal implements necessary data availability improvements at the protocol level, strengthening Arbitrum’s core infrastructure in line with the DAO’s constitutional process.
Thank you for the proposal.
Since @offchainlabs validated the payload, I am going to vote. Aligned with all the other ArbOS proposals my vote is going to be FOR. I do not have something important to add here, so I am keeping it short to avoid noise creation.
Thank you!
And just to note that, any vote from delegates that haven't validated the payload themselves, is a bit irresponsible. Since I can't validate it myself, I'll wait for L2BEAT's assessment before casting my vote.
voting For on the current onchain vote because this keeps Arbitrum aligned with Ethereum, as it should be.
Voting For as this seems like a no-brainer update to optimize Arbitrum and maintain Ethereum alignment.
I voted FOR as this proposal implements necessary data availability improvements at the protocol level, strengthening Arbitrum’s core infrastructure in line with the DAO’s constitutional process.
Thank you for the proposal.
Since @offchainlabs validated the payload, I am going to vote. Aligned with all the other ArbOS proposals my vote is going to be FOR. I do not have something important to add here, so I am keeping it short to avoid noise creation.
Thank you!
And just to note that, any vote from delegates that haven't validated the payload themselves, is a bit irresponsible. Since I can't validate it myself, I'll wait for L2BEAT's assessment before casting my vote.
voting For on the current onchain vote because this keeps Arbitrum aligned with Ethereum, as it should be.
Verified state changes with governance seatbelt, all looks good and consistent with proposal (and matches shared reports here: https://github.com/ArbitrumFoundation/governance/pull/366 )
Voting For
Voting in favor on tally. This is a maintenance proposal and making sure Arbitrum can work with future Ethereum updates. Even though I'm not technical, I can see why it matters to keep ArbOS in line with Ethereum and trust offchainlabs execution.
did anyone independently validated the payload of this onchain proposal?
specifically, the fact that it only does what both of these two proposals say it should? https://snapshot.box/#/s:arbitrumfoundation.eth/proposal/0x33754da4006d0ef38666ec5d5e85fd0966a891a594ab9dc21f23beedea2d330b https://snapshot.box/#/s:arbitrumfoundation.eth/proposal/0x4a96a91d162975de0d402b83ca8b8a24e808ca357150120fc0d44ae0bf1cc4a5
did anyone independently validated the payload of this onchain proposal?
specifically, the fact that it only does what both of these two proposals say it should? https://snapshot.box/#/s:arbitrumfoundation.eth/proposal/0x33754da4006d0ef38666ec5d5e85fd0966a891a594ab9dc21f23beedea2d330b https://snapshot.box/#/s:arbitrumfoundation.eth/proposal/0x4a96a91d162975de0d402b83ca8b8a24e808ca357150120fc0d44ae0bf1cc4a5
@offchainlabs @krst et all?
voted Against on this past offchain vote because there hasn't been enough discussion on this proposal... it's way too soon to bring it to a vote.
The following reflects the views of GMX’s Governance Committee, and is based on the combined research, evaluation, consensus, and ideation of various committee members.
We value the development progress of ArbOS 50 Dia’s introduction in incorporating Fusaka EIP’s. We approved this proposal, and have no qualms with the most recent changes on activating these changes to both Arbitrum Nova and One.
Voted yes on both tally and snapshot I'm supporting this upgrade because it keeps us aligned with Ethereum while adding some smart optimizations for Arbitrum.
Thanks a lot!!
I got the first answer!
As concerns the second I have read the whole discussion in Ehtereum Magicians and tried to understand the more I could!
I appreciate your direct answer.
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.
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
https://github.com/OffchainLabs/nitro/releases/tag/consensus-v50-alpha.1
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.
We will be validating it next week.
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
Τ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:
I voted FOR on this proposal. It bundles several fixes and keeps Arbitrum in pace with Ethereum mainnet.
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.
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.
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.
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.
A Constraint-Based Pricing Change: STF instrumentation to track multi-gas
Native Token Mint/Burn is proposed to be included in ArbOS 50 Dia for the benefit of Arbitrum Orbit chains
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.
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.
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 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.
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.
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!
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
isn’t that… too soon? with almost no discussion about it?
Verified state changes with governance seatbelt, all looks good and consistent with proposal (and matches shared reports here: https://github.com/ArbitrumFoundation/governance/pull/366 )
Voting For
Voting in favor on tally. This is a maintenance proposal and making sure Arbitrum can work with future Ethereum updates. Even though I'm not technical, I can see why it matters to keep ArbOS in line with Ethereum and trust offchainlabs execution.
did anyone independently validated the payload of this onchain proposal?
specifically, the fact that it only does what both of these two proposals say it should? https://snapshot.box/#/s:arbitrumfoundation.eth/proposal/0x33754da4006d0ef38666ec5d5e85fd0966a891a594ab9dc21f23beedea2d330b https://snapshot.box/#/s:arbitrumfoundation.eth/proposal/0x4a96a91d162975de0d402b83ca8b8a24e808ca357150120fc0d44ae0bf1cc4a5
did anyone independently validated the payload of this onchain proposal?
specifically, the fact that it only does what both of these two proposals say it should? https://snapshot.box/#/s:arbitrumfoundation.eth/proposal/0x33754da4006d0ef38666ec5d5e85fd0966a891a594ab9dc21f23beedea2d330b https://snapshot.box/#/s:arbitrumfoundation.eth/proposal/0x4a96a91d162975de0d402b83ca8b8a24e808ca357150120fc0d44ae0bf1cc4a5
@offchainlabs @krst et all?
voted Against on this past offchain vote because there hasn't been enough discussion on this proposal... it's way too soon to bring it to a vote.
The following reflects the views of GMX’s Governance Committee, and is based on the combined research, evaluation, consensus, and ideation of various committee members.
We value the development progress of ArbOS 50 Dia’s introduction in incorporating Fusaka EIP’s. We approved this proposal, and have no qualms with the most recent changes on activating these changes to both Arbitrum Nova and One.
Voted yes on both tally and snapshot I'm supporting this upgrade because it keeps us aligned with Ethereum while adding some smart optimizations for Arbitrum.
Thanks a lot!!
I got the first answer!
As concerns the second I have read the whole discussion in Ehtereum Magicians and tried to understand the more I could!
I appreciate your direct answer.
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.
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
https://github.com/OffchainLabs/nitro/releases/tag/consensus-v50-alpha.1
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.
We will be validating it next week.
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
Τ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:
I voted FOR on this proposal. It bundles several fixes and keeps Arbitrum in pace with Ethereum mainnet.
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.
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.
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.
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.
A Constraint-Based Pricing Change: STF instrumentation to track multi-gas
Native Token Mint/Burn is proposed to be included in ArbOS 50 Dia for the benefit of Arbitrum Orbit chains
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.
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.
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 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.
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.
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!
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
isn’t that… too soon? with almost no discussion about it?
Τ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.
Hi, I have some questions:
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: https://arbitrum.karmahq.xyz/?period=30d
Τ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.
Hi, I have some questions:
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: https://arbitrum.karmahq.xyz/?period=30d