ArbOS Elara is live. Here is what actually changed.

One upgrade, two different audiences

ArbOS Elara went live after approval through Arbitrum governance. Its changes are split between dedicated blockchains built with the Arbitrum Platform and Arbitrum One itself. Treating them as one feature list hides the product strategy behind the upgrade.

Dedicated chains are being given more operational control. Arbitrum One is receiving narrower network-management and developer-capacity improvements. That separation reflects the different jobs each network is expected to perform.

Dedicated chains gain configurable policy and fee tools

Elara introduces protocol-level compliance filtering that a chain owner can apply at the sequencer and state-transition layers before transactions execute. The system also produces records of filtered transactions for internal review and audit workflows.

The upgrade adds customizable priority-fee support. Dedicated-chain operators can now design ordering and fee markets in which transaction tips influence ordering. This capability is especially relevant to trading and application-specific chains, although the existence of the feature does not mean every chain will use the same policy.

A new alternative data-availability API allows operators to integrate external DA providers without maintaining a custom Nitro fork. The practical benefit is lower long-term maintenance overhead for teams that need a different data-availability design.

Arbitrum One gets bounded fee management

Arbitrum One now uses a BaseFeeManager contract. It gives Offchain Labs limited authority to adjust the minimum L2 base fee inside a governance-approved range of 0.01 to 0.10 gwei.

The authority is time-limited to two years, changes require public notification, and ArbitrumDAO retains the ability to remove the delegation. The mechanism does not automatically raise fees; it creates a faster but bounded response path when network conditions change.

Stylus receives a practical capacity increase

The Stylus contract-code limit increases from 24KB to 96KB. That reduces the need to split larger Rust-based applications across multiple contracts and makes it easier to use established libraries without aggressive code-size workarounds.

The change applies to Stylus contracts, not Solidity’s EVM contract-size rules. Elara also removes support for the WebAssembly multi-value extension, so affected developers need to review compatibility notes before activating or reactivating contracts.

What Elara signals

Elara makes the Arbitrum Platform more opinionated about serving regulated finance and application-specific execution. Compliance controls and configurable ordering are features many public-chain users would resist at the base layer, but they can be requirements for a dedicated chain with a defined operator and market.

The trade-off is clearer product segmentation. Arbitrum One remains the shared permissionless liquidity layer, while dedicated chains gain more control. Whether that produces useful specialization or fragmented markets will depend on bridges, interoperability and where liquidity ultimately concentrates.