Last updated: March 25, 2026

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.

• An optional feature that allows chain operators to collect priority fees from transactions. Historically, users have been able to specify a priority fee, but Arbitrum chains are not configured to accept them. This proposed change would introduce the ability for chains to enable tip collection and use priority fees to influence transaction ordering and inclusion. This feature will not be enabled on Arbitrum One or Nova as part of this proposal and would require a separate governance action to activate.

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.

Specification & rationales of proposed changes

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.

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
ResourceKindStorageAccessRead	Represents read access to the global state	* Account lookups (CALL, EXTCODESIZE, BALANCE) * Storage slot reads * Witness generation for reads (e.g. Verkle/stateless mode) * Verkle proof traversal * Target address resolution (DELEGATECALL, STATICCALL)
ResourceKindStorageAccessWrite	Represents storage access operations write operations to non-zero slots	* Storage slot writes (nonzero → nonzero and nonzero → zero) * Access list updates (EIP-2929/2930)
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 calcula

... please visit link below to view full proposal

https://snapshot.org/#/arbitrumfoundation.eth/proposal/0x04d6219c392f3f6187779f609d6cad21e3b3d6091809355ad12ba6bb39b55834