Arbitrum deployed ArbOS 61 Elara on Aug. 20 following ArbitrumDAO governance approval, delivering protocol-level capabilities intentionally inert on the main network. The upgrade touches four areas: optional transaction screening, priority-fee collection, an alternative data-availability interface and expanded Stylus contract capacity.
The compliance filter is disabled on Arbitrum One and Nova by design. Chain owners running dedicated Arbitrum chains—called Orbit chains—must explicitly configure and enable each component through their own governance or operational process.
When a chain operator enables filtering, the owner selects an external compliance provider to generate a restricted-address list. Arbitrum's technical documentation names TRM Labs and Chainalysis as examples. The owner then defines rule sets covering transfers, contract calls and other interactions involving those addresses. Restricted addresses are stored as salted hashes rather than plaintext.
Enforcement runs at two layers. At the first layer, the sequencer simulates incoming transactions and drops any that violate configured rules before they reach a block. The second layer addresses the force-inclusion path, Arbitrum's mechanism by which a user can submit a transaction directly through the parent chain's Delayed Inbox and bypass the sequencer entirely. Under Elara, a sentinel can register that transaction's hash with an on-chain guardian, causing the state transition function to forcibly fail the transaction when it is included in a block.
Arbitrum's documentation recommends that any Orbit chain planning to adopt the compliance filter wait at least 30 days after the ArbOS 61 activation on Arbitrum One before turning it on.
Priority-fee support ships disabled. Only the chain owner—typically an operator address or a DAO—can activate collection through the access-controlled `ArbOwner` precompile. Enabling fee collection alone does not change how transactions are ordered. A chain must separately update its sequencer logic to sort transactions using the priority-fee field before tips carry any MEV-like ordering weight. On Arbitrum One specifically, activating priority-fee collection requires a standalone constitutional DAO vote.
The base-fee changes on Arbitrum One are live and active. Elara introduces a `BaseFeeManager` contract that delegates to Offchain Labs the ability to adjust the Layer 2 minimum base fee within a DAO-approved band of 0.01 to 0.10 gwei. That delegation expires two years after mainnet activation. Any adjustment requires public notice posted to the Arbitrum forum, and the DAO retains the right to revoke the delegation at any time.
The alternative data-availability API is targeted at dedicated chains whose operators want to plug in non-Ethereum DA providers without maintaining custom forks of the Nitro client. Arbitrum One is not expected to use it; the main chain settles transaction data directly on Ethereum.
Elara raises the code-size ceiling for Stylus contracts from 24 KB to 96 KB, a fourfold increase. Stylus is Arbitrum's framework for writing smart contracts in languages that compile to WebAssembly—Rust, C and C++ being the primary targets—rather than Solidity or Vy. The larger limit removes a constraint that was blocking more complex Stylus deployments on Arbitrum One.
The upgrade reflects a deliberate separation between what Arbitrum One does and what the Orbit chain ecosystem is permitted to do. Both the compliance filter and the priority-fee mechanism are available to chain operators as infrastructure choices, while the main network preserves its current behavior unless the DAO votes separately to change it. Regulated enterprises building on Orbit chains—financial institutions, payment operators or tokenization platforms subject to sanctions-screening requirements—can deploy compliant environments without requiring any change to the permissionless main chain.
