At 1700 hours on 20 August (UTC) Arbitrum One and Nova activated Arbos 61 Elara. This upgrade includes the Stylus contract capacity extension, cost and data availability interface improvements, and protocol functionality for other Arbitrum chain options. The most prone to misinterpretation is “agreement-level compliance control”: Elara did incorporate address-specific limitations into the software, but the formal proposal by ArbitrumDAO made it clear that the functionality remained closed on One and Nova. This upgrade cannot be described as the start of a general freeze or filtering of user transactions on the Arbitrum main network.
ArbOS upgrades can be understood as the hard cross of the Arbitrum protocol. Node operators need to run Nitro versions in support of Elara to continue normal synchronization after activation. Official nodal circulars require one and Nova operators to upgrade to Nitro v3.11.3 in advance; no duplicates are required for nodes already in use. For ordinary users, the upgrading process is usually carried out by the infrastructure provider, but the exchange, the RPC service and the application team still need to monitor the nodal version, transaction execution and cost changes.
What did Elara actually change?
One clear change was to raise the contract code size limit for Stylus to 96KB. Stylus allows developers to write smart contracts on Arbitrum in languages such as Rust. Complex applications may be forced to split contracts because of the volume of the code, making it more difficult to call, deploy and audit; a higher ceiling would provide space for large reservoirs and more complex logic. The adjustment applied only to the Stylus application and did not modify the core EVM size assumptions followed in the Solidity contract to avoid additional deviations in the compatibility of the utensils, nodal performance and the development of tools.
The upgrade also involved a management mechanism for the minimum L2 base fee. The formal proposal allows for the adjustment of the minimum base fees for One and Nova within the default period in order to find a balance between waste prevention transactions, user costs and DAO income. Low base fees reduce user costs, but may increase waste flows and reduce agreement revenue; they can also reduce application activity and capital efficiency. The scope, duration and conditions of governance along the chain are more important than “costs can change” per se, and developers should be guided by the final implementation parameters and governance records.
Elara also contains an optional AltDA interface for other Arbitrum chains, which allows a more seamless access to alternative data availability layers. One and Nova still settle to the Ether Fow under the established structure and do not automatically replace the data availability option because of the interface in the code. Similarly, the optional priority fee collection and address restriction capabilities would not be automatically opened as a result of software upgrades. The protocol software "with a function" is in two different states from a chain "governance decision to enable it".
Compliance control allows owners to restrict chain activity from pre-identified addresses, mainly to dedicated chains with specific regulatory needs. The official proposal repeatedly states that One and Nova will not use it at this time. This distinction relates to user rights and decentrization: if the use status is ignored and only concluded under code capabilities, potential configurations are misreported as policies in effect. Any future commissioning changes should look at the governance proposals, execution transactions and parameters of the specific chain, rather than extrapolation from marketing materials.
What should developers, nodes and users check for?
The nodal operator first needs to confirm the Nitro version and the synchronous height and check whether there is a fork, reorganization or RPC anomaly before and after the activation point. The infrastructure team should prepare roll-back and fail-over programmes and verify that the archiving nodes, indexers, prognostics and cross-chain services do not have compatibility problems with the new version. The same version number does not mean that the deployment configuration is fully consistent and that the mirroring of containers, start-up parameters and reliance on services should be included in the inspection.
Stylus developers can assess whether the 96KB cap can reduce unnecessary splits, but “enabled to be larger” does not mean “should be infinite”. The increase in the volume of the code could increase audit complexity, deployment costs and impact. The team should continue to modularize the design, limit privileges, cover the border tests and confirm that the new constraints are understood by the tool chain on which it relies. Security audits should be aimed at the final deployment of byte codes and not simply revert to the old version.
Applications and users should be concerned with actual costs, timing and service stability. Basic fee management mechanisms provide more flexible adjustment space, but short-term experience depends on chain demand, sequencing behaviour and application of its own fees. Any judgement that the upgrade would necessarily result in a permanent reduction of the fees or an immediate increase in the revenues of the agreement would be premature. Real block data after activation should be observed and cost distribution and activity changes should be assessed.
At the governance level, Elara demonstrated a modular route: The same software version could provide an optional capability for different chains, each of which would be governed to determine which functions would be activated. The advantage is that the dedicated chain meets different business and regulatory needs, and the risk is that it is more difficult for users to judge the actual authority of a chain by “using Arbitrum technology”. In the future, wallets, browsers and data platforms need to show more clearly the chain-level configuration, including whether there are address limits, who can change the rate, how long the privileges expire, and whether the changes are governed by the chain.
The exact conclusion of the upgrade should be that Arbitrum One and Nova had adopted Elara ' s new version of the agreement to acquire the capacity of Stylus and a number of infrastructure improvements; the software also contained optional compliance capabilities for other chains, but One and Nova were not activated. The separation of the three layers of code, configuration and governance is an essential way of understanding the upgrading of the modular block chain, avoiding panic or over-sensitization.
Source: ArbitrumDAO official proposal and Arbitrum Foundation Bulletin, https://forum.arbitrum.foundation/t/constitutual-aip-arbos-61-elara/30601