[Constitutional] AIP: ArbOS 61 Elara

[offchainlabs]

UPDATE AS OF JUNE 19, 2026

This proposal has been updated with two important changes. See the June 19, 2026 update section for full details.

---

UPDATE AS OF MAY 6, 2026

At the time of writing, Offchain Labs, in close collaboration with Entropy Advisors, had not yet concluded our detailed analyses on a new set of multidimensional gas targets to use for Dynamic Pricing. As a result, we proposed to leave Dynamic Pricing disabled as part of ArbOS 60 Elara’s activation on Arbitrum One and Arbitrum Nova.

---

Update — June 19, 2026

Offchain Labs would like to make 2 important updates to this proposal, alongside the in-line edits to reflect these updates.

Update 1: Minor version bump from ArbOS 60 to ArbOS 61

During testing of ArbOS 60 on Arbitrum Sepolia, an issue was reported by an ecosystem partner and subsequently confirmed by Offchain Labs: due to two interacting bugs in the gas refund logic, the upgrade caused small, unintended changes to gas refund behavior relating to Dynamic Pricing even with Dynamic Pricing disabled. Unfortunately, the required fixes modify the State Transition Function (STF) and therefore can only be applied via a new ArbOS version. The corrected release is versioned as ArbOS 61. ArbOS 61 is otherwise identical in scope to the ArbOS 60 Elara proposal described below - no features, parameters, or permissions have changed — and all references to ArbOS 60 in this proposal have been updated to read as ArbOS 61. Arbitrum One and Arbitrum Nova were never affected, as ArbOS 60 was not activated on either chain. Arbitrum Sepolia will be upgraded to ArbOS 61 once final release testing is complete. Node operators will be notified beforehand to give adequate time to upgrade their Nitro node software versions.

Update 2: Reaffirming our decision to not activate Dynamic Pricing as part of this proposal

Entropy Advisors has now concluded the analysis on the impacts of Dynamic Pricing (formally: multidimensional gas) on Arbitrum One, referenced in our May 6 update. The findings from the analysis, coupled with the below facts from our own internal assessment of the current implementation, were what ultimately led to our decision to leave Dynamic Pricing disabled and inactive on Arbitrum One and Nova.

See Entropy Advisor’s full analysis here: [Constitutional] AIP: ArbOS 61 Elara - #22 by Entropy

Our own internal assessment of the current implementation concluded that:

• Activating Dynamic Pricing on Arbitrum One and Nova would add additional code complexity to the Nitro node software. While normally this is not a concern in isolation, we hypothesize that Ethereum’s own specification for multidimensional gas (starting with EIP-8037, which is scheduled for the 2026 Glamsterdam hard fork) will result in a bigger Geth diff than we’d like if we enable implementation of multidimensional gas pricing, resulting in a larger long term maintenance burden when compared to adopting what Ethereum eventually pursues. It is our preference to, therefore, invest more time and effort into ensuring that our implementation be updated in such a way that allows Arbitrum chains to reap the many benefits of a multidimensional gas pricing regime, while minimizing the differences between how we implement it and how Ethereum eventually implements it.
• There are non-trivial performance tradeoffs relating to the per-transaction overhead that the new gas accounting logic would impart on chains running at 100ms blocktimes. While today Arbitrum One and Nova do not themselves run at 100ms blocktimes, we have a strong preference to take the time to optimize and invest further in our implementation such that the performance and stability differences between Arbitrum chains running at 100ms vs. 250ms blocktimes are smaller.
• Dynamic Pricing Pricing is only one of many possible and exciting solutions to consider when scaling Arbitrum technology and we believe, especially given the above two points, that there are other solutions that have similar or greater impact with more palpable and less significant tradeoffs. In other words: we believe there are higher return-on-investment solutions we can invest in in the short term instead. We’re very excited to share those with the Arbitrum community when we’re ready to!

All in all, we intend to leave this codepath in the codebase but keep it disabled for Arbitrum One and Nova. This is done so intentionally so that our team has the option to pick this back up in the future should a scenario arise where we believe it makes appropriate sense to re-assess the benefits and tradeoffs. Explicitly: the ArbOS 61 proposal payload will be updated to exclude both: the requisite ArbOwner() call to enable Dynamic Pricing and the access list (implemented via the ResourceConstraintManager smart contract) used grant Offchain Labs the special rights relating to controlling and setting the Dynamic Pricing parameters. In other words: we are no longer requesting the ArbitrumDAO to grant special privileges to Offchain Labs to modify the Dynamic Pricing parameters, because Dynamic Pricing itself is no longer being proposed to get activated as part of this proposal.

We want to extend a sincere thank you to Entropy Advisors, who were exceptional partners throughout this analysis and thought partners on the decision itself.

---

Abstract

This AIP proposes to upgrade Arbitrum One and Arbitrum Nova to ArbOS 61 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 61 Elara are as follows:

1. 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.
2. 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 61 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 accepted 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 61 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 61 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. 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.

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

The last part of ArbOS 61 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. A minor bug fix involving the STF, resulting in a version bump from ArbOS 60 to ArbOS 61

During testing of ArbOS 60 on Arbitrum Sepolia, an issue was reported by an ecosystem partner and subsequently confirmed by Offchain Labs: due to two interacting bugs in the gas refund logic, the upgrade caused small, unintended changes to gas refund behavior relating to Dynamic Pricing even with Dynamic Pricing disabled. Unfortunately, the required fixes modify the State Transition Function (STF) and therefore can only be applied via a new ArbOS version. The corrected release is versioned as ArbOS 61. ArbOS 61 is otherwise identical in scope to the ArbOS 60 Elara proposal described below — no features, parameters, or permissions have changed — and all references to ArbOS 60 in this proposal have been updated to read as ArbOS 61. Arbitrum One and Arbitrum Nova were never affected, as ArbOS 60 was not activated on either chain. Arbitrum Sepolia will be upgraded to ArbOS 61 once final release testing is complete. Node operators will be notified beforehand to give adequate time to upgrade their Nitro node software versions.

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

Alternative Data Availability (AltDA) Layer API

In ArbOS 61, 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 61 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 61 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 61 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.

Priority Fees

ArbOS 61 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 forum for discussion (this post);
2. Engineering work to scope out and implement the relevant changes for ArbOS 61 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 61 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 61 Elara;
6. Should the Snapshot vote pass, ArbOS 61 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 61 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.

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