[Constitutional] AIP: ArbOS 60 Elara

Proposals
1

Abstract

Type: Constitutional AIP

This AIP proposes to upgrade Arbitrum One and Arbitrum Nova to ArbOS 60 Elara. This upgrade includes several innovative Arbitrum features and changes - all of which represent the culmination of months of research and engineering from the Offchain Labs team and is in response to invaluable feedback from the Arbitrum ecosystem of partners, developers, and users. At a high level, the changes being introduced in ArbOS 60 Elara are as follows:

  1. A new gas pricing algorithm, called Dynamic Pricing, to track and charge gas prices across multiple resource dimensions. Included in this proposal are permissions for the sequencer operator to change the gas targets within a range to ensure long term stability. This represents a major step towards implementing what Vitalik Buterin and the Ethereum community call: Multidimensional Gas Pricing.

  2. Increased smart contract code size limit of 96 KB for Stylus smart contracts and accompanying changes to the Stylus Rust SDK to take advantage of this new limit, which is 4x greater than the smart contract size limit for Solidity contracts on the EVM.

  3. A change to allow Offchain Labs, as a service provider to The Arbitrum Foundation on behalf of, and for the benefit of, the ArbitrumDAO, to modify the minimum L2 base fee on Arbitrum One and Nova, between 0.01 gwei and 0.10 gwei (inclusive). This would be enabled via a new BaseFeeManager contract, in a similar way to the ResourceConstraintManager contract (previously proposed here and activated alongside ArbOS 51 Dia).

Additionally, the below features will be included in ArbOS 60 for the convenience of other Arbitrum chains, but are left intentionally disabled on Arbitrum One and Nova:

  • The long awaited API for Arbitrum chains to more cleanly interface and leverage Alternative Data Availability (AltDA) Layers. Arbitrum One and Nova are not expected to leverage this API since these two DAO-owned chains settle to Ethereum.

  • An optional feature for chain owners to restrict on-chain activity from specific, pre-identified addresses. This feature is primarily meant for Arbitrum chains that need to comply with certain regulatory requirements. This feature, however, will not be enabled on Arbitrum One or Nova as part of this proposal.

While the goal of the proposed ArbOS 60 Elara 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. At 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 60 Elara is a proposed upgrade that builds upon ArbOS 51 Dia, which has been previously adopted by the ArbitrumDAO.

These upgrades and delegated rights are proposed by Offchain Labs in its role as an Arbitrum Aligned Entity (AAE), as described in A Vision for the Future of Arbitrum. Offchain Labs serves as an AAE for engineering, product, business development, and technical research.

Rational & Specification

1. Dynamic Pricing (formally: Multidimensional Gas Pricing)

We are proud to introduce Dynamic Pricing, a first-of-its-kind L2 pricing algorithm that helps sustainably increase capacity on Arbitrum chains while retaining the drastically improved price volatility handling introduced in ArbOS 51 Dia. While ArbOS 51 Dia laid the groundwork by instrumenting the node software to track distinct resource dimension vectors, including: storage growth, storage access, calldata, history growth, and computation, this proposed ArbOS 60 Elara release unlocks the ability to price and charge for those resource dimensions based on their individual, real-time demand. Figure 1 below is an example that showcases how gas in a transaction is calculated today compared to how gas would be calculated following this proposed ArbOS 60 Elara upgrade, if adopted. Note that this figure excludes many other types of opcodes and resource dimensions being measured.

Figure 1: An example illustration that highlights the breakdown of a transaction’s underlying components and how gas today is calculated at the opcode level while gas will be calculated based on node resource dimensions in ArbOS 60.
Figure 1: An example illustration that highlights the breakdown of a transaction’s underlying components and how gas today is calculated at the opcode level while gas will be calculated based on node resource dimensions in ArbOS 60.2940×1506 366 KB

In ArbOS 60, the node software introduces distinct ResourceKind categories that will be measured and used to calculate the price of gas, with respect to pre-defined gas targets. Every EVM opcode’s dynamic gas cost is mapped to one or more ResourceKind category, with more details available here. A summary of the ResourceKind categories are can be found in Table 1 below.

Table 1: ResourceKind categories, their description, and rough mapping of associated opcodes

ResourceKind Description Opcodes
ResourceKindComputation Represents pure computational effort, CPU-bound operations that do not mutate global state • Opcode execution
• Memory expansion
• Call gas forwarding (EIP-150)
• Value transfers (unless to empty accounts, then it’s StorageGrowth)
• Contract init code execution (CREATE, CREATE2)
• Hashing
• Bloom filter updates
ResourceKindStorageAccess Represents read access to the global state: • Account lookups (CALL, EXTCODESIZE, BALANCE)
• Storage slot reads
• Storage slot writes (nonzero → nonzero and nonzero → zero)
• Witness generation for reads (e.g. Verkle/stateless mode)
• Access list updates (EIP-2929/2930)
• Verkle proof traversal
• Target address resolution (DELEGATECALL, STATICCALL)
ResourceKindStorageGrowth Includes operations that increase the persistent state size • New account creation
• Storage slot writes (zero → nonzero)
• Contract deployment deposit cost
ResourceKindHistoryGrowth Represents writes to the append-only event log history: Event logs (LOG0–LOG4)
ResourceKindL1Calldata* Represents the cost of posting transaction data to L1 L1 batch posting calldata costs
ResourceKindL2Calldata Represents the cost of L2 calldata processing • L2 transaction calldata
• Precompile argument data
ResourceKindWasmComputation Represents Stylus WASM execution costs • WASM/Stylus program execution
• Stylus contract calls

*Note: while the Arbitrum node software tracks and meters gas costs associated with batch posting to L1 Ethereum (i.e. ResourceKindL1Calldata), changes to the pricing algorithm for this specific resource dimension are not yet complete and will be instead proposed in a future ArbOS upgrade.

Each ResourceKind type will have its own gas targets and adjustment windows. The price of gas for each resource dimension (e.g. storage growth gas, computation gas, etc) is determined by the current demand for that resource dimension on the network, relative to those pre-defined gas targets and measured over their respective adjustment windows. Much like today’s single dimensional gas targets, the gas price is calculated in an EIP-1559-inspired manner and goes up when demand exceeds pre-set targets and goes down (to a minimum) when demand falls below those same targets. For example, if there are a large number of transactions that consume storage-growth gas (e.g. storage writes opcodes), then the price for those transactions will rise if the total storage growth gas consumption exceeds the storage growth gas targets at that moment in time. Meanwhile, the prices for transactions on the network that consume computation gas will not be impacted. To maintain Ethereum API compatibility, the system presents a single gas price to the user. Internally, this price is set to match the highest base fee across all resource dimensions, ensuring the user’s signature covers the cost of every resource used. Following execution, the STF is able to calculate the true resource dimension usage and refunds the user any difference between what the user originally signed their transaction to allow for, and what was actually used.

Figure 2 below serves as a visual aid and example to illustrate the resource dimension breakdown of gas consumption that the node software now tracks (as of ArbOS 51 Dia) and will ultimately use to calculate gas prices (in ArbOS 60 Elara). In the example below, it can be observed that storage-growth operations and computation make up roughly 12% and 43% of all gas consumed in this workload, respectively.

Figure 2: Resource dimension breakdown for gas consumption from 4 weeks on Arbitrum One (mainnet data). The y-axis is gas/s and the x-axis is time.
Figure 2: Resource dimension breakdown for gas consumption from 4 weeks on Arbitrum One (mainnet data). The y-axis is gas/s and the x-axis is time.1920×1080 253 KB

Much like how Arbitrum One and Nova adopted multiple gas targets for a single dimension (introduced in ArbOS 51), this proposal for ArbOS 60 Elara will apply the same approach but for each resource dimension. Below in Table 2 is an example of how the gas targets are proposed to be set for a reference resource dimension W. The system will have multiple gas targets per resource dimension type and accompanying adjustment windows.

Table 2: Sample gas targets for a ResourceKind W (one of many resource dimensions measured and tracked by the node software in ArbOS 60 Elara).

Gas targets for ResourceKind W (Mgas/s) Adjustment windows for ResourceKind W (seconds)
X A
Y B
… …
… …
Z C

Research and benchmarking exercises are underway to determine the exact gas target values for each resource dimension (e.g. X, Y, and Z) as well as their accompanying adjustment windows (e.g. A, B and C). This approach involves the creation and use of synthetic workloads designed to stress-test the node’s ability to sync through each resource dimension type to measure the highest sustainable sync speed per resource dimension to establish a maximum throughput. These measurements will be done across different hardware configurations and their results will be used to determine the above gas targets, per resource dimension.

Special permissions to gradually adjust gas targets and adjustment windows, over time

Separately, this proposal requests the ArbitrumDAO grant Offchain Labs permission, for 2 years from the mainnet activation of this proposal, to adjust the gas targets and adjustment windows in Table 2, on behalf of, and for the benefit of, the ArbitrumDAO in addition to the right to add up to 10 more gas targets and adjustment windows per ResourceKind dimension. These rights will allow for adjustments over time and help maintain the chain’s stability in a way that security is not negatively impacted as additional capacity is added. The rollout of these changes will be paired with continuous monitoring of how the user behavior, node operators, and the network itself responds to them. Summarized below in Table 3 are the values and ranges that this proposal grants Offchain Labs the right to adjust.

Table 3: Proposed gas targets and adjustment window ranges that can be adjusted over time by Offchain Labs, should the permission be granted by the ArbitrumDAO

Parameter Range
Number of gas targets per ResourceKind dimension 1 to 10, inclusive
Gas targets per ResourceKind dimension 10 Mgas/s to 500 Mgas/s, inclusive
Adjustment windows per ResourceKind dimension 5 seconds to 7 days, inclusive

These privileges will be implemented using the same ResourceConstraintManager that was deployed as part of ArbOS 51 Dia and is currently used to allow Offchain Labs to adjust the single dimensional gas targets and single dimensional adjustment windows. As part of this proposal, we will extend the functionality of the ResourceConstraintManager contract to support multiple ResourceKind dimensions, instead of single-dimensional gas only.

This contract will still contain an access list, as it does today, and we propose that the ArbitrumDAO use this access list to designate Offchain Labs the right to invoke specific functions on the ArbOwner precompile to adjust the above values. Normally, ArbOwner parameter changes and function calls require an ArbitrumDAO vote. Delegating that functionality to this ResourceConstraintManager contract will allow Offchain Labs to adjust these parameters in Table 3, within the proposed bounds, without the need for additional votes - should the ArbitrumDAO pass this proposal.

The changes we make to the ResourceConstraintManager contract will be audited by an independent third party entity (Trail of Bits). A full audit report will be published alongside this proposal when it gets proposed in the eventual on-chain vote.

At this time, Offchain Labs has not concluded the testing required to determine the proposed gas target and adjustment window values for each resource dimension type. When testing is completed, we will share the starting proposed gas targets and adjustment windows (per resource dimension) before advancing this proposal to an on-chain ArbitrumDAO vote.

This request is similar to a previous, successful proposal we submitted and would allow Offchain Labs to quickly react and adjust the capacity of each resource dimension on the network as part of our endeavor to be continually test, monitor, and safely scale Arbitrum One and Nova.

To learn more about Dynamic Pricing, go here.

Rationale

At its core, a blockchain network is a symphony of hardware resources. However, not all transactions are created equal. By implementing our version of what Vitalik Buterin defines as Multidimensional Gas Pricing, we are aligning Arbitrum network costs with the physical reality of node hardware. This shift ensures the L2 pricing algorithm is “resource-aware,” directly reflecting the actual bottlenecks (e.g. CPU, I/O, or disk space) facing nodes at any given moment. Breaking it down more explicitly, implementing multidimensional pricing is beneficial to Arbitrum users and builders because doing so:

  • Helps ensure that gas prices are more “fair” and in-line with what the network can truly process, resulting in overall more capacity on the chain without software or hardware changes.

  • Increases the sensitivity of the chain’s capacity to hardware improvements, making it more straightforward to add capacity to the chain as technology improves over time. In other words, improvements in hardware can directly be translated into additional capacity on the network for that specific hardware. As an example: if solutions for storage components dramatically improve tomorrow, then the gas target for storage operations can be increased on the chain to a similar degree.

  • More clearly defines the relationship between node resources and certain types of workloads as a way to pinpoint bottlenecks that teams can invest in removing. Another added benefit here is that Arbitrum chains can custom-tailor their hardware and software for their specific workloads. For example, a chain owner may choose to use gas prices to incentivize certain behaviors on their network while disincentivizing others.

The goal of this feature is to create more stable and accurate prices, reduce fee volatility in response to demand shocks, and increase overall capacity of the network sustainably without overloading node hardware and operators. This effort complements other initiatives we’re undertaking to improve Arbitrum node software to unlock even more capacity - including working with on alternative implementations of Arbitrum.

To read more about our vision for this change, go here.

2. Increased Stylus smart contract code size limit to 96 KB

As mentioned in our reply to another forum post, we are proposing an increase to the Stylus smart contract code size limit to 96 KB, up from 24 KB (a 300% increase). This increase will accompany a new version of the Stylus Rust SDK to make use of this new limit.

This increase is enabled by changing how Stylus contracts are deployed and activated. Specifically, when a contract larger than 24 KB is deployed, the Stylus Rust SDK will split the contract into multiple fragments that are each within the regular 24 KB contract size limit alongside the deployment of a special stylus-collection contract that contains a mapping to each fragment. Upon successful activation, the State Transition Function (STF) within the Arbitrum node software will read all fragments using the stylus-collection contract, append their contents before decompression, and from that point, treat the collection of fragments as one contract.

Rationale

Arbitrum Stylus was launched with the same code size limit as Solidity contracts (24 KB) to maximize interoperability between Solidity and Stylus smart contracts (i.e. they can call into one another) and reduce the technical differences for Solidity developers moving over to try Stylus.

As teams began pushing the boundaries of what’s possible with Stylus, particularly by leveraging Rust libraries through the first-party SDK and the broader Rust ecosystem, the 24KB limit became more constraining for Stylus programs than it typically is for Solidity contracts. This has introduced a lot of friction in the overall developer experience and added unnecessary complexity for teams building larger and scalable applications.

This change is limited to Stylus applications only. Increasing the size limit for Solidity contracts would alter core EVM assumptions and introduce a divergence from Ethereum’s contract size rules, with potential impacts on node performance, developer tooling, and cross-chain compatibility. For those reasons, modifying the Solidity limit is not included part of this proposal and so the proposed scope is intended only to help unblock Stylus development and growth.

3. Changes to how the minimum base fees can be modified & who can modify them

The last part of ArbOS 60 Elara that applies to Arbitrum One and Nova is a proposal to grant Offchain Labs the privilege of modifying the minimum L2 base fee on Arbitrum One and Nova to any value between 0.01 gwei and 0.10 gwei, inclusive. If this proposal passes, this privilege will expire after a 2 year period, as measured from the mainnet activation of this proposal. This approach ensures that subsequent changes to the minimum L2 base fee by Offchain Labs on behalf of the Arbitrum DAO does not need to go through a lengthly Constitutional Vote that normally takes 30+ days. Note that as of January 8, 2026, the minimum L2 base fee on Arbitrum One and Nova was changed to 0.02 gwei as part of the ArbOS 51 Dia upgrade.

Rationale

The minimum L2 base fee is an integral economic aspect of Arbitrum One and Nova. Changes to this value can have a direct impact on the prevalence of spam and transaction fee-based revenue to the Arbitrum DAO, as mentioned in the previous successful AIP to raise the minimum L2 base fee from 0.01 gwei/gas to 0.02 gwei/gas.

With the recent introduction of a new L2 pricing algorithm in ArbOS 51 Dia and yet another upgrade to the L2 pricing algorithm with Dynamic Pricing (this proposal), the cost to transact on Arbitrum One and Nova has fallen and will continue to fall - especially during periods of elevated demand. This is naturally a boon for users and developers but puts a strain on the Arbitrum DAO’s ability to continue investing in growth via incentives, grants, and investments.

In our capacity as an Arbitrum Aligned Entity (AAE), as described in A Vision for the Future of Arbitrum, and in close collaboration with other AAEs (like Entropy Advisors) and ecosystem partners, we believe that this privilege will allow us to quickly iterate, model and ultimately strike the right balance between growing organic activity, long-term ArbitrumDAO financial sustainability, managing spam, and preserving capital efficient DeFi markets. In other words, our goal is to find the right equilibrium through iteration that ultimately leads to a static, final minimum L2 base fee without negatively impacting Arbitrum One and Nova’s thriving ecosystem of users, builders, and node operators.

Any change that is made will follow a public notification via forum post to ensure the ArbitrumDAO has 100% transparency into any modifications that are being made, similar to how Offchain Labs informed the Arbitrum DAO on the recent reserve price changes for Timeboost. As always, the ArbitrumDAO retains the right to remove the delegation of this power to OCL to act via the standard governance process at any time.

Base Fee Manager contract

There will be a new contract deployed called the BaseFeeManager that will give Offchain Labs the appropriate permissions to adjust mininumL2BaseFee and L2BaseFee values from 0.01 gwei and 0.10 gwei, inclusive. The BaseFeeManager contract will contain an access list. We propose that the ArbitrumDAO use this access list to designate Offchain Labs the right to adjust the mininumL2BaseFee and L2BaseFee values in accordance with the terms hereof.

This new contract will be audited by an independent third party entity (Trail of Bits). A full audit report will be published alongside this proposal when it gets proposed in the eventual on-chain vote. Implementing this BaseFeeManager contract will allow Offchain Labs to adjust these values, within the proposed bounds set forth herein, without the need for additional votes - should the ArbitrumDAO pass this proposal.

Other features included in ArbOS 60 but not enabled on Arbitrum One

Alternative Data Availability (AltDA) Layer API

In ArbOS 60, a new pluggable interface to the Arbitrum node software will be introduced that enables AltDA Layers (e.g. EigenDA, Celestia, etc) to integrate with an Arbitrum chain without the need to fork the Arbitrum node software. This API, once integrated by a chain owner, will also reduce the technical overhead and complexities associated with maintaining existing forks of Nitro that are being used to run Arbitrum chains on AltDA layers. For more information, refer to the integration guide.

While this interface is not intended or proposed to be used by Arbitrum One or Nova, its inclusion in ArbOS 60 Elara is intended to simplify the codebase and canonicalize this feature in Nitro. This feature is instead intended to be used by Arbitrum chains who integrate with Data Availability (DA) layers that are not Ethereum, other Arbitrum L2s, or an AnyTrust DAC.

Compliance transaction filtering

ArbOS 60 will also include new, optional components that can be enabled in the Sequencer and State Transition Function (STF) to allow for protocol-level transaction filtering for regulatory or compliance purposes, at the discretion of the chain owner. The chain owner may configure an external compliance service (e.g., TRM or Chainalysis) to define address-level policies. Any transaction that originates from, targets, or otherwise involves a restricted address is filtered prior to execution, including transactions submitted via the Delayed Inbox.

While this feature is not intended or proposed to be used by Arbitrum One or Nova, its inclusion in ArbOS 60 Elara is intended to simplify the codebase and canonicalize this feature in the node software. This feature is instead intended to be used by Arbitrum chains who have compliance and regulatory obligations to restrict on-chain activity from sanctioned entities or actors.

Steps to Implement & Timeline

More detailed information about the specific implementation and versions will be provided closer to the date of the formal on-chain vote. However, this proposal will roughly follow the steps below:

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

  2. Engineering work to scope out and implement the relevant changes for ArbOS 60 Elara into the Arbitrum node software, relevant rollup contracts, and associated upgrade actions (this work has already begun);

  3. A security audit of all ArbOS 60 Elara relevant changes is conducted by a third-party (Trail of Bits) and the audit report is published for public consumption;

  4. A temperature check vote is held on Snapshot;

  5. A new version of Nitro and nitro-contracts, if necessary, are released that support ArbOS 60 Elara;

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

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

  8. If the on-chain vote passes, ArbOS 60 Elara will be activated on Arbitrum One and on Arbitrum Nova following the required waiting periods and phases, as outlined in the ArbitrumDAO Constitution.

Overall Cost

This proposal comes at no cost to the ArbitrumDAO as the engineering work and coordination for an audit will be owned by Offchain Labs.