[Constitutional] AIP: ArbOS 60 Elara

[offchainlabs]

Updated: May 6, 2026

At the time of writing, Offchain Labs, in close collaboration with Entropy Advisors, have not yet concluded our detailed analyses on a new set of multidimensional gas targets to use for Dynamic Pricing. These analyses aim to help determine the relative benefit and impact of these changes on ArbitrumDAO transaction fees, projected user behavior, and raw capacity.

First, as a result and to ensure the activation of the other ArbOS 60 Elara features can proceed without further delay, we are now proposing to leave Dynamic Pricing disabled as part of ArbOS 60 Elara’s activation on Arbitrum One and Arbitrum Nova. Instead, we propose that Dynamic Pricing be enabled at a future date via an offchain temperature check vote when our analyses are completed and provide support that the new gas targets are a net benefit to Arbitrum One and Nova users and builders. Offchain Labs and Entropy Advisors will work together to publish our analyses and conclusions to accompany any future temperature check vote to enable Dynamic Pricing.

Secondly, the special permissions being requested from the ArbitrumDAO for Offchain Labs to adjust, from time to time, the to-be-determined gas targets and adjustment windows has been updated to expire 2 years after the enablement of Dynamic Pricing, rather than the on-chain activation of this ArbOS 60 Elara proposal. This is because the activation of ArbOS 60 Elara is no longer proposed to include the enablement of Dynamic Pricing.

Lastly, we’ve added more technical details to the Dynamic Pricing specification and updated Table 3 to accommodate a larger range of adjustment windows and gas targets, along with an increased number of pricing constraints. This edit allows for the adjustment of to-be-determined gas targets through a wider range of scenarios over time, without subsequent on-chain votes, to help support stability & resiliency of the networks.

---

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. An updated version of Arbitrum’s 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.* Note that this proposal has been updated to specify that Dynamic Pricing will be left disabled as part of ArbOS 60 Elara’s launch.

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 (and optional) API for Arbitrum chains to more cleanly interface and leverage Alternative Data Availability (AltDA) Layers. Arbitrum One and Nova are not proposed to leverage this API since Arbitrum One uses Ethereum for DA and Arbitrum Nova uses an AnyTrust Data Availability Committee (DAC) for DA.

• 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 and its use is gated by an activation timelock of 7 days (i.e. this feature can only be used 7 days after it is enabled by a governance action).

• 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 Arbitrum One and Arbitrum Nova, 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 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

Specification & Rationales of Proposed Changes

1. Dynamic Pricing (formally: Multidimensional Gas Pricing)

Note: as of 6 May, 2026, this proposal has been modified to specify that Dynamic Pricing will be left disabled if ArbOS 60 Elara gets activated because Offchain Labs, in close collaboration with Entropy Advisors, have not yet concluded our detailed analyses on a new set of multidimensional gas targets to use for Dynamic Pricing. These analyses aim to help determine the relative benefits and impact of these changes on ArbitrumDAO transaction fees, projected user behavior, and raw capacity. Instead, we now propose that Dynamic Pricing be enabled at a future date via an offchain temperature check vote when our analyses are completed and provide support that the new gas targets are net beneficial to Arbitrum One and Nova. The special permissions being requested from the ArbitrumDAO to allow Offchain Labs to adjust, from time to time, the to-be-determined gas targets and adjustment windows has been updated to expire 2 years after the enablement of Dynamic Pricing, rather than the on-chain activation of this ArbOS 60 Elara proposal. This is because the activation of ArbOS 60 Elara is no longer proposed to include the enablement of Dynamic Pricing.

We are proud to introduce an improved version of 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]( AIP: Raise the gas target, min L2 base fee, & implement improvements to the pricing algorithm ). 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 the below 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 (to be combined with ResourceKindComputation)	• 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) and L2 calldata size (i.e. ResourceKindL2Calldata), changes to the pricing algorithm for this specific resource dimensions are planned to be proposed in a future ArbOS upgrade.

The new pricing algorithm will employ “constraints” to track the usage and calculate a price for each ResourceKind type. Each of these “constraints” are effectively a linear combination of weighted resources that each have their own adjustment window and gas target. These constraints may contain 1 or multiple ResourceKinds.

Below are two examples of constraints one might see enabled on a chain with ArbOS 60 Elara’s Dynamic Pricing upgrade:

Example 1: ResourceKindComputation <= 75 Mgas/s over 1000 seconds

Example 2: ResourceKindStorageGrowth + 0.10*ResourceKindStorageAccessWrite <= 5 Mgas/s over 5000 seconds

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 the gas targets, measured over their respective adjustment windows defined in each constraint. Much like today’s single dimensional gas targets, the gas price is calculated in an EIP-1559-inspired manner and the price goes up when demand exceeds pre-set targets and the price 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.

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 across several resource dimensions represented using a constraint. 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 constraint that may involve 1 or many ResourceKinds (measured and tracked by the node software in ArbOS 60 Elara).

Gas targets for a constraint (Mgas/s)	Adjustment windows for a constraint (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.

As mentioned earlier, Dynamic Pricing is proposed to be included in ArbOS 60 Elara but left disabled at the time of activation on mainnet Arbitrum One and Nova, should this proposal pass. Instead, Offchain Labs and in close collaboration with Entropy Advisors, will seek a temperature check vote to enable this feature at a future date when the analyses on the new gas targets have concluded and if that data supports that the new gas targets will result in a net benefit the ArbitrumDAO-owned chains from a safety, capacity, and fee-revenue perspective. Specifically: the passing of this proposal will be interpreted as an explicit approval from the ArbitrumDAO to allow Offchain Labs to enable Dynamic Pricing at a future date using a temperature check vote. Offchain Labs and Entropy Advisors intend to publish our analyses and conclusions for the DAO’s consideration as part of that temperature check vote.

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 enablement of the Dynamic Pricing feature, 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 100 constraints with accompanying targets and adjustment windows. Each constraint may include multiple ResourceKind dimensions. 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 constraints (that may each include multipleResourceKind dimensions)	1 to 10, inclusive
Gas targets per ResourceKind dimension	1 Mgas/s to 500 Mgas/s, inclusive
Adjustment windows per ResourceKind dimension	1 seconds to 30 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. As a result and to enable the activation of the other ArbOS 60 Elara features without further delay pursuant to this proposal, we are now proposing to leave Dynamic Pricing disabled as part of ArbOS 60 Elara’s activation on Arbitrum One and Arbitrum Nova. Instead, we propose that Dynamic Pricing be enabled at a future date via an offchain temperature check vote when our analyses are completed and provide support that the new gas targets are a net benefit to Arbitrum One and Nova users and builders Offchain Labs and Entropy Advisors will work together to publish our analyses and conclusions to accompany any future temperature check vote to enable Dynamic Pricing.

Additionally, the special permissions being requested from the ArbitrumDAO for Offchain Labs to adjust, from time to time, the to-be-determined gas targets and adjustment windows has been updated to expire 2 years after the enablement of Dynamic Pricing, rather than the on-chain activation of this ArbOS 60 Elara proposal. This is because the activation of ArbOS 60 Elara is no longer proposed to include the enablement of Dynamic Pricing.

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

3. Other features included in ArbOS 60 but not proposed to be enabled on Arbitrum One or Nova

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 Elara 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. Note that enabling this feature requires an ArbitrumDAO approved onchain governance action (for Arbitrum One and Arbitrum Nova) and, subject to that onchain approval, its use is gated behind a 7 day timelock (i.e. it can only be used 7 days following a governance action to enable it). 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.

Priority Fees

ArbOS 60 introduces a way to enable the collection of tips in the form of priority fees on an Arbitrum chain. However, the actual enablement of this feature (i.e. turning it on) on Arbitrum One and Nova is not proposed for this vote or upgrade and will instead require an additional Constitutional DAO vote sometime in the future. Today priority fees are not collected, and the feature to collect tips remains disabled, meaning that if a transaction includes priority fees they won’t be collected. The proposed change simply adds the capability for Arbitrum Chain operators to later enable tip collection and use priority fees as an input to transaction ordering. Any Arbitrum Chain that wants to order transactions based on priority fees would need to both enable tip collection and update the Sequencer’s sorting logic to incorporate the PriorityFee field.

4. WASM Compatibility Changes

This upgrade includes several bug fixes and improvements to Stylus. It also removes support for the WebAssembly multi-value extension, simplifying the execution model. Contracts relying on multi-value WASM will no longer be able to be activated or re-activated.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.

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 forum 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 has been completed 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 sometime in mid-May;

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.

9. [At a future date] Separate but related to this proposal: publication of our analysis and proposed gas targets for Dynamic Pricing, which will accompany an offchain temperature check vote to get permission from the ArbitrumDAO to enable Dynamic Pricing.

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.

[Entropy]

Overall, we are supportive of all three proposed changes by OCL. Thank you to the team for the continued engineering work on the protocol.

In particular, we are in favor of granting Offchain Labs the flexibility to adjust the minimum L2 base fee within the 0.01 to 0.10 gwei range. This is an area we have written about extensively, most recently in our comment on the ArbOS51 proposal and the data since ArbOS 51’s activation on January 5th reinforces why this lever matters. Since being introduced on January 5th, the changes to congestion pricing and gas targets have caused L2 surplus fees to drop to <$1000 on all but extremely volatile days (Jan 31st for example).

In the 60 days prior to ArbOS 51, L2 surplus fees averaged roughly $23.9k per day and accounted for over 60% of transaction fee income, while L2 base fees contributed just $13.8k per day (36.2% of the total). Since ArbOS 51, that composition has inverted and the L2 base fee has effectively become the DAO’s primary stable income source, averaging now roughly $19.7k per day.

Additionally, the core rationale remains the same in that a majority of activity on Arbitrum One is bot activity and that organic users are less price sensitive to slight increases to the minimum base fee. Since it was raised to 0.02 gwei in early January, we have not seen a noticeable change in the percentage of user transactions vs active/likely bot transactions. Roughly 80-90% of daily transactions on Arbitrum One are still bot-driven despite the increase to their costs.

With Dynamic Pricing potentially improving throughput during times of congestion even further, we believe giving OCL the operational flexibility to iterate on this parameter is the best approach for balancing revenue and the user experience on Arbitrum.

Lastly, Entropy is also very supportive of increasing Stylus contract sizes to 96kb. Contract size limits were consistently the primary pain point raised by builders in the Stylus Sprint as the overhead in splitting and managing multiple contracts degraded developer experience and impacted performance benchmarks.

@offchainlabs

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.

[dzack23]

Voting FOR (snapshot):

• Excited to see multidimensional gas pricing getting shipped after much theorizing, and appreciate the thorough details provided.
• Am generally in favor of constrained trust assumptions to modify economic parameters within predefined safe values, like the base fee management introduced here.
• Increasing Stylus contract size limit seems like a change that will benefit developers without introducing any dangerous EVM divergence.

[Zeptimus]

Fully support this upgrade. I’ve heard of builders getting excited about the Stylus contract size increasing to 96KB, it’s going to unlock a lot of potential and we also had a discusiion on the fees before my stance stay the same. Plus, Offchain Labs is absolutely the best team to execute something this complex.

[Griff]

Voting FOR

Upgrading to ArbOS 60 is a no brainer. All the new features are just awesome. Honestly tho, having the whole DAO vote on these heavy tech upgrades is too much overhead. It would be way better to fund a selected group of technical experts to review OCL’s work and then optimistically approve it. Instead of paying delegates to vote on this, let’s use that same budget to pay the tech experts! Any way.. just a thought since Tally is not running the show anymore, it opens us up to more options.

Easy yes for now anyway.

[Arbit1]

@Griff

Honestly tho, having the whole DAO vote on these heavy tech upgrades is too much overhead. It would be way better to fund a selected group of technical experts to review OCL’s work and then optimistically approve it. Instead of paying delegates to vote on this, let’s use that same budget to pay the tech experts!

The DAO has already moved in a direction that concentrates power by lowering/changing the quorum which has effectively increased the influence of the largest delegates while reducing the impact/influence of mid and smaller ones.

That isn’t enough centralization for you though…Your suggestion is to go a step further and introduce a separate group of technical experts to review and “optimistically approve” upgrades. This would effectively eliminate the ability of delegates to vote on those technical proposals. At that point, we need to ask honestly: what role does the DAO (and ARB Token) actually play anymore ?

[maxlomu]

gm, voted FOR.

All changes sound reasonable and exciting. In support of giving more autonomy to OCL to configure parameters within the agreed ranges.

Thank you for your work

[Reverie]

• Reverie is voting FOR this proposal.

• We have previously been supportive of the DAO’s push to implement multidimensional gas pricing as it allows for more granular pricing of data and computation. The second proposed change of increasing the stylus smart contract code limit to 96KB makes a lot of sense as it increases interoperability with the Rust ecosystem and lets rust devs experiment with stylus more easily. Lastly, we also think it makes sense to let Offchain Labs modify min base fee to better deal with spam and fund DAO initiatives

[yoavw]

Voted FOR.

No brainer, a great upgrade. In particular I’ve been a long time advocate of multidimentional gas pricing so I’m excited to see it go live.

[MconnectDAO]

This proposal grants Offchain Labs two open-ended discretionary powers for 2 years: (1) adjusting Dynamic Pricing gas targets across all ResourceKind dimensions within wide ranges (10–500 Mgas/s), and (2) modifying the minimum L2 base fee (0.01–0.10 gwei) both without any per-change on-chain vote, requiring only a forum post notification.

My question: What is the on-chain enforcement mechanism if Offchain Labs makes changes that are technically within the permitted range but economically harmful to the DAO or users?

The ArbitrumDAO Constitution requires that Constitutional AIPs introduce changes with clear checks and balances. A forum post notification is a transparency mechanism not an accountability mechanism. If OCL raises the base fee to 0.10 gwei overnight citing “spam control,” the DAO has no fast-response veto pathway. A Constitutional vote takes 30+ days by design.

I’d also note an important asymmetry: this delegation is being granted via a Constitutional AIP, but the revocation pathway is also Constitutional meaning a 30+ day process for the DAO to respond even to clearly harmful changes. OCL can act instantly; the DAO cannot.

Before this advances to Snapshot, I’d request the proposers clarify:

1. Is there a time-lock or delay between OCL’s decision to change these parameters and their on-chain execution?

2. Does the BaseFeeManager or updated ResourceConstraintManager include any DAO emergency override or Security Council veto capability?

3. Why is a simple multi-sig with a 7-day delay + DAO cancellation window not included here, as was done in STEP 2.0 for treasury actions?

These safeguards are not about distrust of Offchain Labs they are about establishing a replicable governance standard for parameter delegation that future AIPs can follow. Without them, this proposal asks the DAO to grant broad, fast, unchecked economic levers to a single entity, which sets a concerning precedent regardless of how trusted that entity is.

Manoj Kumar Desai | MconnectDAO

[brandonkumar]

Vote: FOR
Technically sound upgrade with appropriately bounded delegation to Offchain Labs. Follows the governance pattern established in ArbOS 51 Dia. No cost to the DAO.

[mihal]

Voting FOR.

The technical upgrades here are straightforward wins. I’ve been following multidimensional gas pricing as a concept since Noam Nisan presentation at Starknet Sessions back in 2023, it’s a long-overdue improvement and I’m glad to see it landing on Arbitrum.

On the base fee delegation: I think Offchain Labs has earned this trust. The authority is meaningfully constrained (0.01–0.10 gwei, forum-notified), and given that we’re talking about global fee rate parameters rather than protocol logic, the risk profile feels appropriate.

MconnectDAO raises valid points about the accountability gap: worth addressing in future proposals, but not a blocker given the nature of what’s being delegated here.

On a separate note, I find myself agreeing with Griff’s suggestion about technical expert review panels for ArbOS-class upgrades. Asking the full delegate body to vote on highly technical protocol changes is a governance mismatch, this feels like a better model to explore for future upgrades.

[Jonezee]

On behalf of GMX, one of the most gas-intensive and revenue-generating dapps on the chain, I just want to highlight: any increase in base gas fees is likely to be felt significantly by our thousands of weekly users.

I sincerely hope the dynamic gas fees and potential 5x base fee increase do not negatively impact our traders.

[PennBlockchain]

Abstract

This post raises a procedural concern that I believe the ArbitrumDAO needs to address: the practice of bundling multiple, substantively distinct proposals into a single AIP. I argue this undermines the quality of our governance and should be discouraged or formally prohibited.

The Problem

A recent example illustrates this clearly: ArbOS 60 Elara bundles three separate governance actions into one vote, a new multidimensional gas pricing algorithm, an increase to the Stylus contract size limit, and a two-year delegation of base fee modification rights to Offchain Labs. Each of these carries meaningfully different risk profiles, stakeholder implications, and tradeoffs.

A delegate who strongly supports the Stylus contract size increase but has reservations about granting Offchain Labs broad, fast-acting discretion over the minimum base fee, as MconnectDAO raised in the thread, has no way to express that nuance. They must vote yes or no on the bundle, effectively being coerced into accepting proposals they might otherwise reject in order to support the ones they do.

Why This Matters

Bundling creates a structural incentive to attach controversial or weaker proposals to popular ones. It dilutes accountability, suppresses dissent on individual components, and makes it harder for the community to form clear, informed opinions. It also muddies the governance record when a bundle passes, it’s unclear which parts the DAO actually endorsed.

What I’m Proposing

I’d like the ArbitrumDAO to adopt a norm and ideally a formal guideline that each AIP must contain a single, coherent governance action. Where a proposer believes multiple changes belong together, they should justify that explicitly and allow the community to challenge the bundling before a Snapshot vote proceeds.

Call to Action

I’d welcome feedback from delegates and the broader community. Has bundling benefited governance in cases I’m not considering? Should this be a soft norm or a constitutional requirement?

[shogun]

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.

The introduction of ArbOS 60 Elara is a good step toward DAO revenue stability. Building the multidimensional gas price mechanism in order to cover the highest computation cost for the storage write opcodes in using the network will indeed impact the most active users. We recognise that this is important for the success of the network, and an algorithm that is “resource-aware” would fulfill workloads under stress of usage activity. We have no objections over the Stylus contract changes and enabling of the priority fee.

GMX publishes a voluminous amount of data in transactions onto the network, including Chainlink oracle updates, rebalancing of pools (on both market and liquidity sides), fee generation, and events relating to trades/swaps.

We have keepers who rely on predictable cost estimation to remain viable, this ensures price and execution availability. While the STF refunds differences of the signed gas allowance and true usage post-execution, there’s still a variance in overcharge refund spread. This is not so straightforward for GMX’s keeper infrastructure where activity is more dense.

Our decision of ABSTAIN, was cognisant of the new gas algorithm and its influence on GMX’s and other derivatives platforms operational costs. The net impact on users is unquantifiable at this stage.

[krst]

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

We voted FOR.

The dynamic pricing model builds on the resource tracking introduced in ArbOS 51 and should help price different types of usage more accurately. The Stylus code size increase is also a nice improvement that makes building easier without obvious downsides. The base fee delegation is limited in scope and seems reasonable, although we would still like to see the initial gas target values and adjustment windows before the final vote to better understand how the system will behave.

One thing that deserves attention to is the inclusion of compliance-based transaction filtering in Nitro. Even if it is not meant to be enabled on Arbitrum One or Nova, making it part of the core stack could create challenges for chains trying to meet certain decentralization standards (like the L2BEAT’s stages framework). We understand why this feature exists, and as long as it stays disabled on Arbitrum One and Nova, we do not see it as a blocker.

[offchainlabs]

Hello Manoj! Thanks for your comment and reply to our forum post and proposal. The Research and Engineering team at Offchain Labs is currently conducting thorough research and analyses to inform the initial gas targets and adjustment windows for Dynamic Pricing that we propose to the Arbitrum DAO, with the goal that users are not harmed while producing a net-benefit for the Arbitrum ecosystem. As a reminder, these privileges are meant to allow Offchain Labs to quickly react and adjust the capacity of each resource dimension on the network as part of our endeavor to continually test, monitor, and safely scale Arbitrum One and Nova. The economic impact of these changes on the DAO and Arbitrum users are most definitely part of the analysis we are currently conducting.

The Arbitrum DAO can remove the delegation of this power to OCL to act via the standard governance process at any time and for any reason. These actions are on-chain and serve as an enforcement mechanism if Offchain Labs makes changes that are technically within the permitted range but economically harmful to the DAO or users.

To answer your questions in order:

1. No such time-lock or delay exists in either the BaseFeeManager or the ResourceConstraintManager contracts.

2. As already mentioned in the original proposal, both the BaseFeeManager and ResourceConstraintManager contain an access list that delegates Offchain Labs the right to make the required calls to change the minimum L2 base fee and relevant parameters for the new gas pricing algorithm. 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.

3. As already mentioned, these privileges are meant to allow Offchain Labs to quickly react and adjust the capacity of each resource dimension on the network as part of our endeavor to continually test, monitor, and safely scale Arbitrum One and Nova. Having a 7-delay plus a cancellation window would artificially delay the length of time between when we believe action is needed and when the changes get executed onchain. This delay could potentially have downsides should circumstances exist that would warrant intervention.

We hope this answers your questions. We’ve attended 2 ArbitrumDAO proposal discussion calls in the last month (hosted by the OpCo) and would have been able to field these questions in that forum. We’d be more than happy to chat to you and your team if you have further questions.

Thanks

Offchain Labs

[offchainlabs]

This forum post has been updated as of today - May 6, 2026.

[offchainlabs]

Hey krst! Great hearing from you - thank you for your comment and question!

Totally understand your perspective on the compliance-based transaction filtering feature. To help mitigate those potential challenges you cite, this feature is gated behind an ArbOwner call, meaning only the chain owner can enable it. Secondly, there is a 7-day enable delay built in so that in the event that the chain owner enables this feature on a live chain, it will take 7 days to take effect. The development of this feature is part of our endeavor to allow for the Arbitrum platform to be customized and adapted to a variety of both common and novel use cases for blockchain technologies and Ethereum scaling solutions!

[Arb_Junior]

Strong support For

@offchainlabs

Dynamic Pricing

I see the proposal arbOS 60 elara dynamic pricing disabled at launch, to be enabled later by a temperature check vote, that’s a cautious approach which makes sense for a change that affects gas cost calculations at the protocol level.

A good reason to enable it: dynamic pricing can make the ecosystem more efficient during congestion, instead of flat rates that spike unpredictably, it adjusts in real time based on demand, smoothing out costs for users and reducing the advantage of bots during high traffic, that benefits real users especially in defi and gaming where predictable fees matter.

My opinion: the proposal is well structured separating the technical upgrade from the policy decision is smart, it lets the network upgrade first then debate the pricing model without holding up progress but the temperature check should be more than a formality, the community needs clear simulations or examples showing how dynamic pricing would behave under stress.