UPDATE -
This Constitutional AIP is now live on Tally - voting starts on Thursday, August 1st, at 13:46 UTC.
There has been an error in 2 URLs on the text of the Onchain AIP on Tally, and the correct URLs are listed below.
To clarify, the payload and custom upgrade actions in the AIP are still correct - the only errors were in the description of the proposal.
Wrong Addresses:
- Arb1 SetArbOS31VersionAction: SetArbOS31VersionAction | Address 0x7ed9C3A779BE8b742AbFC17a2F15353ecBcE3e00 | Arbitrum One
- Nova SetArbOS31VersionAction: SetArbOS31VersionAction | Address 0x75C5a4532102DDFa44527B382990C384Ec1dD57D | Arbiscan
Correct Addresses:
- Arb1 SetArbOS31VersionAction: SetArbOS31VersionAction | Address 0xaF81C82Ec98f86D0017d78cD66F1026f1A5Cf1Db | Arbitrum One
- Nova SetArbOS31VersionAction: SetArbOS31VersionAction | Address 0x6dD43360d2a69BB9FfFC5349F2511f2A3bCbC2da | Arbiscan
This update has also been highlighted at the very top of the first post. We apologize for this error, and are happy to answer any questions that delegates and the DAO might have.
This AIP proposes the activation of ArbOS 31 on Arbitrum One and Arbitrum Nova. This ArbOS upgrade brings a number of improvements, including:
This AIP combines the following three temperature checks:
A new ArbOS 31 “Bianca” was released between the time of the temperature check votes and submitting this proposal. ArbOS 31 release builds upon ArbOS 30 and includes new optimizations that were discovered during rigorous testing and feedback from Stylus teams. The ArbOS upgrade is shipped as a new Nitro node release alongside new upgrades to the rollup contracts for Arbitrum One and Arbitrum Nova.
Note: ArbOS 31 “Bianca” will be the canonical ArbOS version for the “Bianca” family of releases.
Since the DAO has already signaled support for the adoption of all three changes in all three temperature checks, this proposal will proceed to an on-chain AIP on Tally next.
Stylus is an upgrade to the node software that powers all Arbitrum chains. This upgrade introduces a new WASM-based Virtual Machine (VM) that runs alongside the EVM. This enables developers to write smart contracts in new programming languages, like Rust, that are more efficient than Solidity smart contracts.
Stylus is a first-of-its-kind technology resulting from breakthrough engineering efforts in the Arbitrum ecosystem. Unlike other alternative VMs, the Stylus VM is not a replacement for the EVM & is instead purely additive to the EVM. This means that Stylus contracts and EVM contracts are fully interoperable. The two VMs work together to facilitate state transitions, each playing their part in executing their respective bytecode. Support for more memory efficient and safer languages will unlock a new generation of applications that were previously impossible to build on the EVM.
The Stylus VM and fraud prover were originally developed as a fork of the Nitro codebase before. The Stylus codebase has since been audited (Trail of Bits audit report) and merged back into the Nitro codebase:
Stylus contracts can be written using the Stylus SDK, which employs Solidity-equivalent ABIs and storage patterns to ensure cross-language interoperability. For example, existing Solidity DEXs can list Rust tokens without modification. New SDKs for additional programming languages can be added over time. Current SDK repositories:
If you would like to better understand the lifecycle of a Stylus contract, head over to A Gentle Introduction: Stylus. For teams who are curious to learn more about how Stylus is expected to interact with their project’s existing infrastructure, we encourage folks to check out this Stylus launch ecosystem one-pager.
Note: Support for Stylus contract verification is currently under development by major block explorers. We expect that contract verification will be fully supported before ArbOS 31 Bianca gets activated on Arbitrum One and Arbitrum Nova, pending the DAO’s decision to adopt this proposal.
Passkeys offer a solution that removes the need for a web3 user to personally store a private key for their wallet. Passkeys accomplish this by leveraging WebAuthn, a global standard for passwordless authentication used by Google, Facebook, Microsoft, and all major web browsers. The private key generated when creating a passkey can be encrypted and can only be decrypted using a specialized hardware module called the Secure Enclave. The Secure Enclave ensures a user’s private key can never leave the device, transforming any compatible device into a hardware wallet. Users can authorize transactions with biometric features like Touch ID or Face ID when using passkey-based wallets for key management. These qualities add flexibility and significantly improve UX while maintaining high security.
Adding support for RIP-7212 decreases the costs of verifying the secp256r1 curve on-chain by 99% when compared to current implementations, making them more feasible for everyday use and enabling dApp developers and protocols to offer their users improved UX on Arbitrum One and Arbitrum Nova. Without a precompile, verifying this signature on-chain is extremely expensive. Passkey-based wallets offer a better level of security than a typical EOA and seamless cross-device support. Many wallets, and notably, apps using embedded wallets, have been requesting this feature for over a year.
The specifications of RIP-7212, including test cases, can be found in the RIP repository. If approved, Arbitrum One and Arbitrum Nova will use this specification as the reference for implementation. The Ethereum Magicians Forum discusses design decisions, iterations, and the transformation of the proposal from an EIP (Ethereum Improvement Proposal) to a RIP.
This pre-compile is part of Nitro 3.1.0 and was added to our fork of Go Ethereum in https://github.com/OffchainLabs/go-ethereum/pull/303 and has been upstreamed into Nitro 3.1.0. Nitro 3.1.0 is the minimum supported version of Nitro for ArbOS 31 “Bianca”.
Today, the ArbitrumDAO’s portion of the transaction fees from Arbitrum Nova are sent to the Core Governance L1 Timelock address, which is accessible via the core governance system. This setup is disadvantageous because any time the ArbitrumDAO wishes to spend/move the funds, a roundtrip, constitutional proposal must be passed before the DAO.
This proposal updates the setup such that all Arbitrum Nova transaction fees, that are currently sent to the Core Governance L1 Timelock Address, are instead sent to a system of “fee routers” that automatically send all funds to the ArbitrumDAO treasury. Benefits of this new setup include:
This new, proposed system of “fee routers” results in a fee collection lifecycle as follows:
distributeRewards function call is made on the RewardDistributor contract, sending funds to a ChildtoParentRouter contractrouteFunds, the ChildToParentRouter creates an L2-to-L1 message which sends the contract’s full Ether balance.ParentToChildRouter contract on L1.routeFunds is called on ParentToChildRouter, creating a retryable ticket which transfers its full Ether balance to the DAO Treasury on Arbitrum One.Note that the addresses deployed during the Snapshot vote for the ParentToChildRewardRouter and ChildToParentRewardRouter have been re-deployed at [0x40Cd7D713D7ae463f95cE5d342Ea6E7F5cF7C999](https://nova.arbiscan.io/address/0x40Cd7D713D7ae463f95cE5d342Ea6E7F5cF7C999) and [0x36D0170D92F66e8949eB276C3AC4FEA64f83704d](https://nova.arbiscan.io/address/0x36D0170D92F66e8949eB276C3AC4FEA64f83704d), respectively.
All of the above changes were independently audited. The list below contains all relevant audit reports:
The canonical version of ArbOS 31 “Bianca” this proposal aims to adopt is implemented in the Arbitrum Nitro git commit hash 7d1d84c75db7fd26d27d24ffb75f8b1c93d4f980 and can be viewed in: https://github.com/OffchainLabs/nitro/commit/7d1d84c75db7fd26d27d24ffb75f8b1c93d4f980.
The current full code diff can be viewed via this link: https://github.com/OffchainLabs/nitro/compare/consensus-v20...consensus-v31.
ArbOS 31 “Bianca” will be shipped as part of a future release of Nitro. Node operators may see a small increase in latency for Stylus eth_call queries, if ArbOS 31 is approved for activation on mainnet by the ArbitrumDAO.
The Action smart contracts used to execute the on-chain upgrade can be viewed in https://github.com/ArbitrumFoundation/governance/pull/296.
Action contract deployments for ArbOS 31 and Stylus:
$ cast storage 0x51dEDBD2f190E0696AFbEE5E60bFdE96d86464ec 0xb53127684a568b3173ae13b9f8a6016e243e63b6e8ee1178d6a717850b5d6103 --rpc-url=https://arb1.arbitrum.io/rpc
0x000000000000000000000000db216562328215e010f819b5abe947bad4ca961e (Arb One Proxy Admin)
$ cast storage 0x20586F83bF11a7cee0A550C53B9DC9A5887de1b7 0xb53127684a568b3173ae13b9f8a6016e243e63b6e8ee1178d6a717850b5d6103 --rpc-url=https://nova.arbitrum.io/rpc
0x000000000000000000000000f58ea15b20983116c21b05c876cc8e6cdae5c2b9 (Nova Proxy Admin)
Action contracts, deployments, and Fee Router contracts for the Fee Router AIP:
The Fee Router contracts can be found here: https://github.com/OffchainLabs/fund-distribution-contracts/tree/v1.0.1/src/FeeRouter
Note that during the Snapshot vote, a different set of Fee Router contracts were shared. Due to optimizations that have been made since then, the above v1.0.1 Fee Router contracts will be used for this proposal. A full code diff of the two sets of Fee Router contracts can be viewed here: https://github.com/OffchainLabs/fund-distribution-contracts/compare/61f4f60384e2ecba8250287dfb2778ce30bd82b0...v1.0.1
Upgrade Action Contract: https://github.com/ArbitrumFoundation/governance/blob/8e730975dbf4403a38dc0270fcc0c56bdee80c42/src/gov-action-contracts/AIPs/AIPNovaFeeRoutingAction.sol
Deployments:
Nova ArbChildToParentRewardRouter: https://nova.arbiscan.io/address/0x36D0170D92F66e8949eB276C3AC4FEA64f83704d
To verify the ArbOS code differences, this notion page contains steps to build the WASM module root on that git tag, which produces the WASM module root 0x8b104a2e80ac6165dc58b9048de12f301d70b02a0ab51396c22b4b4b802a16a4, which is what the rollup contract’s wasmModuleRoot() method returns for both Arbitrum One and Arbitrum Nova.
These steps will be included on the onchain AIP on Tally in entirety to ensure consistency with previous ArbOS proposals.
UPDATE -
This Constitutional AIP is now live on Tally - voting starts on Thursday, August 1st, at 13:46 UTC.
There has been an error in 2 URLs on the text of the Onchain AIP on Tally, and the correct URLs are listed below.
To clarify, the payload and custom upgrade actions in the AIP are still correct - the only errors were in the description of the proposal.
Wrong Addresses:
- Arb1 SetArbOS31VersionAction: SetArbOS31VersionAction | Address 0x7ed9C3A779BE8b742AbFC17a2F15353ecBcE3e00 | Arbitrum One
- Nova SetArbOS31VersionAction: SetArbOS31VersionAction | Address 0x75C5a4532102DDFa44527B382990C384Ec1dD57D | Arbiscan
Correct Addresses:
- Arb1 SetArbOS31VersionAction: SetArbOS31VersionAction | Address 0xaF81C82Ec98f86D0017d78cD66F1026f1A5Cf1Db | Arbitrum One
- Nova SetArbOS31VersionAction: SetArbOS31VersionAction | Address 0x6dD43360d2a69BB9FfFC5349F2511f2A3bCbC2da | Arbiscan
This update has also been highlighted at the very top of the first post. We apologize for this error, and are happy to answer any questions that delegates and the DAO might have.
This AIP proposes the activation of ArbOS 31 on Arbitrum One and Arbitrum Nova. This ArbOS upgrade brings a number of improvements, including:
This AIP combines the following three temperature checks:
A new ArbOS 31 “Bianca” was released between the time of the temperature check votes and submitting this proposal. ArbOS 31 release builds upon ArbOS 30 and includes new optimizations that were discovered during rigorous testing and feedback from Stylus teams. The ArbOS upgrade is shipped as a new Nitro node release alongside new upgrades to the rollup contracts for Arbitrum One and Arbitrum Nova.
Note: ArbOS 31 “Bianca” will be the canonical ArbOS version for the “Bianca” family of releases.
Since the DAO has already signaled support for the adoption of all three changes in all three temperature checks, this proposal will proceed to an on-chain AIP on Tally next.
Stylus is an upgrade to the node software that powers all Arbitrum chains. This upgrade introduces a new WASM-based Virtual Machine (VM) that runs alongside the EVM. This enables developers to write smart contracts in new programming languages, like Rust, that are more efficient than Solidity smart contracts.
Stylus is a first-of-its-kind technology resulting from breakthrough engineering efforts in the Arbitrum ecosystem. Unlike other alternative VMs, the Stylus VM is not a replacement for the EVM & is instead purely additive to the EVM. This means that Stylus contracts and EVM contracts are fully interoperable. The two VMs work together to facilitate state transitions, each playing their part in executing their respective bytecode. Support for more memory efficient and safer languages will unlock a new generation of applications that were previously impossible to build on the EVM.
The Stylus VM and fraud prover were originally developed as a fork of the Nitro codebase before. The Stylus codebase has since been audited (Trail of Bits audit report) and merged back into the Nitro codebase:
Stylus contracts can be written using the Stylus SDK, which employs Solidity-equivalent ABIs and storage patterns to ensure cross-language interoperability. For example, existing Solidity DEXs can list Rust tokens without modification. New SDKs for additional programming languages can be added over time. Current SDK repositories:
If you would like to better understand the lifecycle of a Stylus contract, head over to A Gentle Introduction: Stylus. For teams who are curious to learn more about how Stylus is expected to interact with their project’s existing infrastructure, we encourage folks to check out this Stylus launch ecosystem one-pager.
Note: Support for Stylus contract verification is currently under development by major block explorers. We expect that contract verification will be fully supported before ArbOS 31 Bianca gets activated on Arbitrum One and Arbitrum Nova, pending the DAO’s decision to adopt this proposal.
Passkeys offer a solution that removes the need for a web3 user to personally store a private key for their wallet. Passkeys accomplish this by leveraging WebAuthn, a global standard for passwordless authentication used by Google, Facebook, Microsoft, and all major web browsers. The private key generated when creating a passkey can be encrypted and can only be decrypted using a specialized hardware module called the Secure Enclave. The Secure Enclave ensures a user’s private key can never leave the device, transforming any compatible device into a hardware wallet. Users can authorize transactions with biometric features like Touch ID or Face ID when using passkey-based wallets for key management. These qualities add flexibility and significantly improve UX while maintaining high security.
Adding support for RIP-7212 decreases the costs of verifying the secp256r1 curve on-chain by 99% when compared to current implementations, making them more feasible for everyday use and enabling dApp developers and protocols to offer their users improved UX on Arbitrum One and Arbitrum Nova. Without a precompile, verifying this signature on-chain is extremely expensive. Passkey-based wallets offer a better level of security than a typical EOA and seamless cross-device support. Many wallets, and notably, apps using embedded wallets, have been requesting this feature for over a year.
The specifications of RIP-7212, including test cases, can be found in the RIP repository. If approved, Arbitrum One and Arbitrum Nova will use this specification as the reference for implementation. The Ethereum Magicians Forum discusses design decisions, iterations, and the transformation of the proposal from an EIP (Ethereum Improvement Proposal) to a RIP.
This pre-compile is part of Nitro 3.1.0 and was added to our fork of Go Ethereum in https://github.com/OffchainLabs/go-ethereum/pull/303 and has been upstreamed into Nitro 3.1.0. Nitro 3.1.0 is the minimum supported version of Nitro for ArbOS 31 “Bianca”.
Today, the ArbitrumDAO’s portion of the transaction fees from Arbitrum Nova are sent to the Core Governance L1 Timelock address, which is accessible via the core governance system. This setup is disadvantageous because any time the ArbitrumDAO wishes to spend/move the funds, a roundtrip, constitutional proposal must be passed before the DAO.
This proposal updates the setup such that all Arbitrum Nova transaction fees, that are currently sent to the Core Governance L1 Timelock Address, are instead sent to a system of “fee routers” that automatically send all funds to the ArbitrumDAO treasury. Benefits of this new setup include:
This new, proposed system of “fee routers” results in a fee collection lifecycle as follows:
distributeRewards function call is made on the RewardDistributor contract, sending funds to a ChildtoParentRouter contractrouteFunds, the ChildToParentRouter creates an L2-to-L1 message which sends the contract’s full Ether balance.ParentToChildRouter contract on L1.routeFunds is called on ParentToChildRouter, creating a retryable ticket which transfers its full Ether balance to the DAO Treasury on Arbitrum One.Note that the addresses deployed during the Snapshot vote for the ParentToChildRewardRouter and ChildToParentRewardRouter have been re-deployed at [0x40Cd7D713D7ae463f95cE5d342Ea6E7F5cF7C999](https://nova.arbiscan.io/address/0x40Cd7D713D7ae463f95cE5d342Ea6E7F5cF7C999) and [0x36D0170D92F66e8949eB276C3AC4FEA64f83704d](https://nova.arbiscan.io/address/0x36D0170D92F66e8949eB276C3AC4FEA64f83704d), respectively.
All of the above changes were independently audited. The list below contains all relevant audit reports:
The canonical version of ArbOS 31 “Bianca” this proposal aims to adopt is implemented in the Arbitrum Nitro git commit hash 7d1d84c75db7fd26d27d24ffb75f8b1c93d4f980 and can be viewed in: https://github.com/OffchainLabs/nitro/commit/7d1d84c75db7fd26d27d24ffb75f8b1c93d4f980.
The current full code diff can be viewed via this link: https://github.com/OffchainLabs/nitro/compare/consensus-v20...consensus-v31.
ArbOS 31 “Bianca” will be shipped as part of a future release of Nitro. Node operators may see a small increase in latency for Stylus eth_call queries, if ArbOS 31 is approved for activation on mainnet by the ArbitrumDAO.
The Action smart contracts used to execute the on-chain upgrade can be viewed in https://github.com/ArbitrumFoundation/governance/pull/296.
Action contract deployments for ArbOS 31 and Stylus:
$ cast storage 0x51dEDBD2f190E0696AFbEE5E60bFdE96d86464ec 0xb53127684a568b3173ae13b9f8a6016e243e63b6e8ee1178d6a717850b5d6103 --rpc-url=https://arb1.arbitrum.io/rpc
0x000000000000000000000000db216562328215e010f819b5abe947bad4ca961e (Arb One Proxy Admin)
$ cast storage 0x20586F83bF11a7cee0A550C53B9DC9A5887de1b7 0xb53127684a568b3173ae13b9f8a6016e243e63b6e8ee1178d6a717850b5d6103 --rpc-url=https://nova.arbitrum.io/rpc
0x000000000000000000000000f58ea15b20983116c21b05c876cc8e6cdae5c2b9 (Nova Proxy Admin)
Action contracts, deployments, and Fee Router contracts for the Fee Router AIP:
The Fee Router contracts can be found here: https://github.com/OffchainLabs/fund-distribution-contracts/tree/v1.0.1/src/FeeRouter
Note that during the Snapshot vote, a different set of Fee Router contracts were shared. Due to optimizations that have been made since then, the above v1.0.1 Fee Router contracts will be used for this proposal. A full code diff of the two sets of Fee Router contracts can be viewed here: https://github.com/OffchainLabs/fund-distribution-contracts/compare/61f4f60384e2ecba8250287dfb2778ce30bd82b0...v1.0.1
Upgrade Action Contract: https://github.com/ArbitrumFoundation/governance/blob/8e730975dbf4403a38dc0270fcc0c56bdee80c42/src/gov-action-contracts/AIPs/AIPNovaFeeRoutingAction.sol
Deployments:
Nova ArbChildToParentRewardRouter: https://nova.arbiscan.io/address/0x36D0170D92F66e8949eB276C3AC4FEA64f83704d
To verify the ArbOS code differences, this notion page contains steps to build the WASM module root on that git tag, which produces the WASM module root 0x8b104a2e80ac6165dc58b9048de12f301d70b02a0ab51396c22b4b4b802a16a4, which is what the rollup contract’s wasmModuleRoot() method returns for both Arbitrum One and Arbitrum Nova.
These steps will be included on the onchain AIP on Tally in entirety to ensure consistency with previous ArbOS proposals.
The Event Horizon Community Voted to Support this Proposal ehARB-15: EventHorizon.vote/vote/arbitrum/ehARB-15
The Event Horizon Community Voted to Support this Proposal ehARB-15: EventHorizon.vote/vote/arbitrum/ehARB-15
https://forum.arbitrum.foundation/t/aip-arbos-31-bianca-activation-of-arbitrum-stylus-rip-7212-support-nova-fee-router-proposal/25904/18?u=bob-rossi
https://forum.arbitrum.foundation/t/aip-arbos-31-bianca-activation-of-arbitrum-stylus-rip-7212-support-nova-fee-router-proposal/25904/17?u=tane
https://forum.arbitrum.foundation/t/griff-green-delegate-communication-thread/25040/18?u=griff
https://forum.arbitrum.foundation/t/aip-arbos-31-bianca-activation-of-arbitrum-stylus-rip-7212-support-nova-fee-router-proposal/25904/16?u=0x_ultra
Stylus is potentially a major competitive advantage for Arbitrum
https://forum.arbitrum.foundation/t/aip-arbos-31-bianca-activation-of-arbitrum-stylus-rip-7212-support-nova-fee-router-proposal/25904/14?u=ocandocrypto
https://forum.arbitrum.foundation/t/aip-arbos-31-bianca-activation-of-arbitrum-stylus-rip-7212-support-nova-fee-router-proposal/25904/13
The activation of ArbOS 31 brings significant improvements to the Arbitrum ecosystem, supporting new smart contract languages, enhancing security with passkey-based wallets, and streamlining fund management. The DAO's previous support for these changes indicates a smooth transition to on-chain implementation.
We are enthusiastic about the “ArbOS 31 ‘Bianca’” proposal. It represents a significant advancement in enhancing the Arbitrum ecosystem, and we fully support these updates. Looking forward to the positive impact this will bring.
https://forum.arbitrum.foundation/t/aip-arbos-31-bianca-activation-of-arbitrum-stylus-rip-7212-support-nova-fee-router-proposal/25904/10?u=ezr3al
https://forum.arbitrum.foundation/t/aip-arbos-31-bianca-activation-of-arbitrum-stylus-rip-7212-support-nova-fee-router-proposal/25904/7?u=blockworksresearch
https://forum.arbitrum.foundation/t/aip-arbos-31-bianca-activation-of-arbitrum-stylus-rip-7212-support-nova-fee-router-proposal/25904/18?u=bob-rossi
https://forum.arbitrum.foundation/t/aip-arbos-31-bianca-activation-of-arbitrum-stylus-rip-7212-support-nova-fee-router-proposal/25904/17?u=tane
https://forum.arbitrum.foundation/t/griff-green-delegate-communication-thread/25040/18?u=griff
https://forum.arbitrum.foundation/t/aip-arbos-31-bianca-activation-of-arbitrum-stylus-rip-7212-support-nova-fee-router-proposal/25904/16?u=0x_ultra
Stylus is potentially a major competitive advantage for Arbitrum
https://forum.arbitrum.foundation/t/aip-arbos-31-bianca-activation-of-arbitrum-stylus-rip-7212-support-nova-fee-router-proposal/25904/14?u=ocandocrypto
https://forum.arbitrum.foundation/t/aip-arbos-31-bianca-activation-of-arbitrum-stylus-rip-7212-support-nova-fee-router-proposal/25904/13
The activation of ArbOS 31 brings significant improvements to the Arbitrum ecosystem, supporting new smart contract languages, enhancing security with passkey-based wallets, and streamlining fund management. The DAO's previous support for these changes indicates a smooth transition to on-chain implementation.
We are enthusiastic about the “ArbOS 31 ‘Bianca’” proposal. It represents a significant advancement in enhancing the Arbitrum ecosystem, and we fully support these updates. Looking forward to the positive impact this will bring.
https://forum.arbitrum.foundation/t/aip-arbos-31-bianca-activation-of-arbitrum-stylus-rip-7212-support-nova-fee-router-proposal/25904/10?u=ezr3al
https://forum.arbitrum.foundation/t/aip-arbos-31-bianca-activation-of-arbitrum-stylus-rip-7212-support-nova-fee-router-proposal/25904/7?u=blockworksresearch
The Treasure ARC voted For this proposal. The upgrades will benefit users and developers, furthering Arbitrum's goal of being the leading L2 across use cases, increasing security (and ease of security) and granting efficiencies to the fee collection router process.
The Treasure ARC voted For this proposal. The upgrades will benefit users and developers, furthering Arbitrum's goal of being the leading L2 across use cases, increasing security (and ease of security) and granting efficiencies to the fee collection router process.
OpenZeppelin, the Security Member of the ARDC, reviewed the AIP: ArbOS 31 "Bianca" proposal and its execution instructions. If enacted, the proposal execution will activate Stylus, Alternate Signature Verification, and Automatic Treasury Deposits using seven on-chain governance action contracts (GACs) that alter the ecosystem in the ways described in the proposal description.
OpenZeppelin, the Security Member of the ARDC, reviewed the AIP: ArbOS 31 "Bianca" proposal and its execution instructions. If enacted, the proposal execution will activate Stylus, Alternate Signature Verification, and Automatic Treasury Deposits using seven on-chain governance action contracts (GACs) that alter the ecosystem in the ways described in the proposal description.
The new, on-chain contracts match their audited versions with the exception of the contracts in the OffchainLabs/fund-distribution-contracts for fund distribution which were not fully covered by the audit scope and with some files receiving some optimization changes since the final audit commit. We recommend getting a confirmation on whether the latest version of these files were covered in the audit.
You may read our full review here:
https://forum.arbitrum.foundation/t/aip-arbos-31-proposal-review/26000
OpenZeppelin, on behalf of the ARDC, is reviewing the upcoming ArbOS 31 upgrade proposal details. This includes the proposal calldata submitted as PR298, the contents of the forum post above, and verifying that the action contracts in the proposal have been audited.
We are awaiting additional details to be published by the Offchain Labs team that should help us address concerns raised by @cp0x. We'll also confirm the Tally proposal submitted on-chain matches what has been previously claimed.
Gm Arbinauts! :sunny:
The results are in for the https://dhive.io/proposal/700 proposal.
See how the community voted and more Arbitrum stats on our platform:
OpenZeppelin, the Security Member of the ARDC, reviewed the AIP: ArbOS 31 "Bianca" proposal and its execution instructions. If enacted, the proposal execution will activate Stylus, Alternate Signature Verification, and Automatic Treasury Deposits using seven on-chain governance action contracts (GACs) that alter the ecosystem in the ways described in the proposal description.
OpenZeppelin, the Security Member of the ARDC, reviewed the AIP: ArbOS 31 "Bianca" proposal and its execution instructions. If enacted, the proposal execution will activate Stylus, Alternate Signature Verification, and Automatic Treasury Deposits using seven on-chain governance action contracts (GACs) that alter the ecosystem in the ways described in the proposal description.
The new, on-chain contracts match their audited versions with the exception of the contracts in the OffchainLabs/fund-distribution-contracts for fund distribution which were not fully covered by the audit scope and with some files receiving some optimization changes since the final audit commit. We recommend getting a confirmation on whether the latest version of these files were covered in the audit.
You may read our full review here:
https://forum.arbitrum.foundation/t/aip-arbos-31-proposal-review/26000
OpenZeppelin, on behalf of the ARDC, is reviewing the upcoming ArbOS 31 upgrade proposal details. This includes the proposal calldata submitted as PR298, the contents of the forum post above, and verifying that the action contracts in the proposal have been audited.
We are awaiting additional details to be published by the Offchain Labs team that should help us address concerns raised by @cp0x. We'll also confirm the Tally proposal submitted on-chain matches what has been previously claimed.
Gm Arbinauts! :sunny:
The results are in for the https://dhive.io/proposal/700 proposal.
See how the community voted and more Arbitrum stats on our platform:
Thank you for your review @openzeppelin .
The RewardDistributor contract has already been audited and is currently in use already: https://nova.arbiscan.io/address/0x9fCB6F75D99029f28F6F4a1d277bae49c5CAC79f.
Thank you for your review @openzeppelin .
The RewardDistributor contract has already been audited and is currently in use already: https://nova.arbiscan.io/address/0x9fCB6F75D99029f28F6F4a1d277bae49c5CAC79f.
Here is an example of one used in production - its code is the exact same. The ArbOS 31 proposal is NOT proposing the deployment of a new rewardDistributor contract - instead we're just updating the recipients on the existing ones.
This comment has also been posted on the https://forum.arbitrum.foundation/t/aip-arbos-31-proposal-review/26000 thread.
This Constitutional AIP is now live on Tally - voting starts on Thursday, August 1st, at 13:46 UTC.
There has been an error in 2 URLs on the text of the Onchain AIP on Tally, and the correct URLs are listed below.
To clarify, the payload and custom upgrade actions in the AIP are still correct - the only errors were in the description of the proposal.
This Constitutional AIP is now live on Tally - voting starts on Thursday, August 1st, at 13:46 UTC.
There has been an error in 2 URLs on the text of the Onchain AIP on Tally, and the correct URLs are listed below.
To clarify, the payload and custom upgrade actions in the AIP are still correct - the only errors were in the description of the proposal.
Arb1 SetArbOS31VersionAction: SetArbOS31VersionAction | Address 0x7ed9C3A779BE8b742AbFC17a2F15353ecBcE3e00 | Arbitrum One
Nova SetArbOS31VersionAction: SetArbOS31VersionAction | Address 0x75C5a4532102DDFa44527B382990C384Ec1dD57D | Arbiscan
Arb1 SetArbOS31VersionAction: https://arbiscan.io/address/0xaF81C82Ec98f86D0017d78cD66F1026f1A5Cf1Db
Nova SetArbOS31VersionAction: https://nova.arbiscan.io/address/0x6dD43360d2a69BB9FfFC5349F2511f2A3bCbC2da
This update has also been highlighted at the very top of the first post. We apologize for this error, and are happy to answer any questions that delegates and the DAO might have.
Thank you for your review @openzeppelin .
The RewardDistributor contract has already been audited and is currently in use already: https://nova.arbiscan.io/address/0x9fCB6F75D99029f28F6F4a1d277bae49c5CAC79f.
Thank you for your review @openzeppelin .
The RewardDistributor contract has already been audited and is currently in use already: https://nova.arbiscan.io/address/0x9fCB6F75D99029f28F6F4a1d277bae49c5CAC79f.
Here is an example of one used in production - its code is the exact same. The ArbOS 31 proposal is NOT proposing the deployment of a new rewardDistributor contract - instead we're just updating the recipients on the existing ones.
This comment has also been posted on the https://forum.arbitrum.foundation/t/aip-arbos-31-proposal-review/26000 thread.
This Constitutional AIP is now live on Tally - voting starts on Thursday, August 1st, at 13:46 UTC.
There has been an error in 2 URLs on the text of the Onchain AIP on Tally, and the correct URLs are listed below.
To clarify, the payload and custom upgrade actions in the AIP are still correct - the only errors were in the description of the proposal.
This Constitutional AIP is now live on Tally - voting starts on Thursday, August 1st, at 13:46 UTC.
There has been an error in 2 URLs on the text of the Onchain AIP on Tally, and the correct URLs are listed below.
To clarify, the payload and custom upgrade actions in the AIP are still correct - the only errors were in the description of the proposal.
Arb1 SetArbOS31VersionAction: SetArbOS31VersionAction | Address 0x7ed9C3A779BE8b742AbFC17a2F15353ecBcE3e00 | Arbitrum One
Nova SetArbOS31VersionAction: SetArbOS31VersionAction | Address 0x75C5a4532102DDFa44527B382990C384Ec1dD57D | Arbiscan
Arb1 SetArbOS31VersionAction: https://arbiscan.io/address/0xaF81C82Ec98f86D0017d78cD66F1026f1A5Cf1Db
Nova SetArbOS31VersionAction: https://nova.arbiscan.io/address/0x6dD43360d2a69BB9FfFC5349F2511f2A3bCbC2da
This update has also been highlighted at the very top of the first post. We apologize for this error, and are happy to answer any questions that delegates and the DAO might have.
Let us provide a quick summary and insights into this proposal. The AIP consists of three key proposals, each vital to the growth of the Arbitrum ecosystem.
Stylus integration allows developers to use languages like C++ and Rust, while offering a VM compatible with the EVM, enhancing memory efficiency.
RIP-7212 Support boosts security and user experience with Face ID and Touch ID via passkeys, replacing traditional methods. It also reduces secp256r1 curve verification costs by 99%, significantly improving efficiency.
The Nova Fee Router streamlines access to the DAO treasury by directing fees straight to the Arbitrum DAO treasury, bypassing the Core Governance L1 Timelock address, which only the core team can access.
Let us provide a quick summary and insights into this proposal. The AIP consists of three key proposals, each vital to the growth of the Arbitrum ecosystem.
Stylus integration allows developers to use languages like C++ and Rust, while offering a VM compatible with the EVM, enhancing memory efficiency.
RIP-7212 Support boosts security and user experience with Face ID and Touch ID via passkeys, replacing traditional methods. It also reduces secp256r1 curve verification costs by 99%, significantly improving efficiency.
The Nova Fee Router streamlines access to the DAO treasury by directing fees straight to the Arbitrum DAO treasury, bypassing the Core Governance L1 Timelock address, which only the core team can access.
We believe these proposals will benefit users, developers, and the DAO itself. Therefore, as the ITU Blockchain delegation team, we vote in favor of the proposal on Tally.
gm, voted FOR on Tally as I previously supported the single upgrades.
In line with my previous comments at the Snapshot phase of these votes, voting "For" on Tally.
https://forum.arbitrum.foundation/t/aip-nova-fee-router-proposal-arbos-30/23310/8
We vote FOR the proposal on Tally.
We maintain our rationales below for each individual update and support a package of those updates to be deployed as "Bianca". We appreciate the proper audits on each implementation and OpenZeppelin's reviews as a part of ARDC works.
I am voting in favor of this proposal on Tally. My voting rationale is aligned with the reasons that I previously mentioned on Snapshot for the individual components concerning ArbOS 31. You can read them here:
DAOplomats voted FOR this proposal on Tally.
Having supported each of the upgrades during temp check, we maintained our stance for the onchain votes.
At Castle Capital, we’re always enthusiastic about initiatives that push the boundaries of what’s possible in DeFi, and this upgrade proposal is no exception. We believe it holds great promise for enhancing the ecosystem, and we're keen to see its potential benefits unfold.
That said, regarding the technical and security nuances, we believe it's best to lean on the expertise within our DAO community. We trust those with specialized knowledge will provide the necessary analysis to ensure this proposal meets the highest standards of safety and efficacy.
At Castle Capital, we’re always enthusiastic about initiatives that push the boundaries of what’s possible in DeFi, and this upgrade proposal is no exception. We believe it holds great promise for enhancing the ecosystem, and we're keen to see its potential benefits unfold.
That said, regarding the technical and security nuances, we believe it's best to lean on the expertise within our DAO community. We trust those with specialized knowledge will provide the necessary analysis to ensure this proposal meets the highest standards of safety and efficacy.
We will be voting For this upgrade.
I voted FOR this proposal because it’s like giving Arbitrum a superhero upgrade:
Arbitrum Stylus: Now developers can whip up smart contracts in Rust and C++—faster, stronger, and definitely cooler.
New Precompile for secp256r1 Verification: Cuts verification costs by 99%, making passkey-based wallets cheaper, safer, and less of a headache for everyone.
Let us provide a quick summary and insights into this proposal. The AIP consists of three key proposals, each vital to the growth of the Arbitrum ecosystem.
Stylus integration allows developers to use languages like C++ and Rust, while offering a VM compatible with the EVM, enhancing memory efficiency.
RIP-7212 Support boosts security and user experience with Face ID and Touch ID via passkeys, replacing traditional methods. It also reduces secp256r1 curve verification costs by 99%, significantly improving efficiency.
The Nova Fee Router streamlines access to the DAO treasury by directing fees straight to the Arbitrum DAO treasury, bypassing the Core Governance L1 Timelock address, which only the core team can access.
Let us provide a quick summary and insights into this proposal. The AIP consists of three key proposals, each vital to the growth of the Arbitrum ecosystem.
Stylus integration allows developers to use languages like C++ and Rust, while offering a VM compatible with the EVM, enhancing memory efficiency.
RIP-7212 Support boosts security and user experience with Face ID and Touch ID via passkeys, replacing traditional methods. It also reduces secp256r1 curve verification costs by 99%, significantly improving efficiency.
The Nova Fee Router streamlines access to the DAO treasury by directing fees straight to the Arbitrum DAO treasury, bypassing the Core Governance L1 Timelock address, which only the core team can access.
We believe these proposals will benefit users, developers, and the DAO itself. Therefore, as the ITU Blockchain delegation team, we vote in favor of the proposal on Tally.
gm, voted FOR on Tally as I previously supported the single upgrades.
In line with my previous comments at the Snapshot phase of these votes, voting "For" on Tally.
https://forum.arbitrum.foundation/t/aip-nova-fee-router-proposal-arbos-30/23310/8
We vote FOR the proposal on Tally.
We maintain our rationales below for each individual update and support a package of those updates to be deployed as "Bianca". We appreciate the proper audits on each implementation and OpenZeppelin's reviews as a part of ARDC works.
I am voting in favor of this proposal on Tally. My voting rationale is aligned with the reasons that I previously mentioned on Snapshot for the individual components concerning ArbOS 31. You can read them here:
DAOplomats voted FOR this proposal on Tally.
Having supported each of the upgrades during temp check, we maintained our stance for the onchain votes.
At Castle Capital, we’re always enthusiastic about initiatives that push the boundaries of what’s possible in DeFi, and this upgrade proposal is no exception. We believe it holds great promise for enhancing the ecosystem, and we're keen to see its potential benefits unfold.
That said, regarding the technical and security nuances, we believe it's best to lean on the expertise within our DAO community. We trust those with specialized knowledge will provide the necessary analysis to ensure this proposal meets the highest standards of safety and efficacy.
At Castle Capital, we’re always enthusiastic about initiatives that push the boundaries of what’s possible in DeFi, and this upgrade proposal is no exception. We believe it holds great promise for enhancing the ecosystem, and we're keen to see its potential benefits unfold.
That said, regarding the technical and security nuances, we believe it's best to lean on the expertise within our DAO community. We trust those with specialized knowledge will provide the necessary analysis to ensure this proposal meets the highest standards of safety and efficacy.
We will be voting For this upgrade.
I voted FOR this proposal because it’s like giving Arbitrum a superhero upgrade:
Arbitrum Stylus: Now developers can whip up smart contracts in Rust and C++—faster, stronger, and definitely cooler.
New Precompile for secp256r1 Verification: Cuts verification costs by 99%, making passkey-based wallets cheaper, safer, and less of a headache for everyone.
In line with my previous comments at the Snapshot phase of these votes, voting "For" on Tally.
https://forum.arbitrum.foundation/t/aip-nova-fee-router-proposal-arbos-30/23310/8
We vote FOR the proposal on Tally.
We maintain our rationales below for each individual update and support a package of those updates to be deployed as "Bianca". We appreciate the proper audits on each implementation and OpenZeppelin's reviews as a part of ARDC works.
https://forum.arbitrum.foundation/t/aip-nova-fee-router-proposal-arbos-30/23310/25?u=tane
We are particularly excited to see Stylus finally going live!
I am voting in favor of this proposal on Tally. My voting rationale is aligned with the reasons that I previously mentioned on Snapshot for the individual components concerning ArbOS 31. You can read them here:
https://forum.arbitrum.foundation/t/aip-nova-fee-router-proposal-arbos-30/23310/12
I really appreciate the quality of this proposal and the efforts that were made to make it coherent and solid.
I voted FOR this proposal because it’s like giving Arbitrum a superhero upgrade:
Arbitrum Stylus: Now developers can whip up smart contracts in Rust and C++—faster, stronger, and definitely cooler.
New Precompile for secp256r1 Verification: Cuts verification costs by 99%, making passkey-based wallets cheaper, safer, and less of a headache for everyone.
Nova Fee Collection Update: It’s like giving the ArbitrumDAO a direct line to its piggy bank, making fund management smoother and less bureaucratic.
These upgrades aren’t just cool features; they’re going to supercharge Arbitrum’s scalability, security, and governance. Plus, with solid community backing and thorough audits, it’s clear that Arbitrum is leveling up in the best way possible.
I voted FOR this proposal on Tally, as I did for each of the three component temp checks.
https://forum.arbitrum.foundation/t/aip-nova-fee-router-proposal-arbos-30/23310/11?u=frisson
I voted FOR this proposal on Tally, as I did for each of the three component temp checks.
https://forum.arbitrum.foundation/t/aip-nova-fee-router-proposal-arbos-30/23310/11?u=frisson
https://forum.arbitrum.foundation/t/aip-support-rip-7212-for-account-abstraction-wallets-arbos-30/23298/19?u=frisson https://forum.arbitrum.foundation/t/aip-nova-fee-router-proposal-arbos-30/23310/11?u=frisson
I'm pleased with the level of technical rigor behind the onchain proposal. I appreciate the audits of each part, the ability the independently verify changes, and the review from OpenZeppelin as part of the ARDC.
Will post my complete rational later. But voting FOR in this proposal.
The following reflects the views of L2BEAT’s governance team, composed of @krst and @Sinkas, and it’s based on the combined research, fact-checking, and ideation of the two.
Having supported each individual upgrade included in ArbOS 31, we’ll be voting FOR this proposal during the onchain vote.
The following reflects the views of L2BEAT’s governance team, composed of @krst and @Sinkas, and it’s based on the combined research, fact-checking, and ideation of the two.
Having supported each individual upgrade included in ArbOS 31, we’ll be voting FOR this proposal during the onchain vote.
OpenZeppelin, in their capacity as the security member of the ARDC, conducted a review of the proposal’s executable and confirmed that the upgrade will only perform the actions described in the proposal. We also individually checked the contents of the proposal’s executable to confirm that they’ll only do what they describe. Both reviews found no issues, and therefore, we’re comfortable voting in favor.
Voted for this - three important upgrades in a single proposal. Enabling the precompile is a competitive necessity for account abstraction and wallet management in general, and Stylus opens the door to a richer future of possibilities for developers building on Arbitrum.
I voted yes, as Bianca is giving new tools like allowing Rust to be used as a programming language.
Should be this here https://forum.arbitrum.foundation/t/aip-arbos-31-proposal-review/26000/3?u=ezr3al
Blockworks Research will be voting FOR this proposal on Tally when live.
These upgrades are very important for the network moving forward. EIP/RIP-7212 will allow for much better gas optimization for smart wallet accounts using more traditional secp cryptographic curves which enables biometric signatures or other methods for wallet management, and Stylus will enable better and more diverse applications moving forward. This seems like a 'no brainer' for the DAO to support. Polygon, Optimism, and Base have already implemented RIP-7212, and it may be implemented as an EIP going forward so it's best to get ahead of the curve and join the others.
Here is our rationale for onchain voting:
AIP: Activate Stylus and Enable Next-Gen WebAssembly Smart Contracts
Here is our rationale for onchain voting:
AIP: Activate Stylus and Enable Next-Gen WebAssembly Smart Contracts
Stylus significantly improves Arbitrum by supporting Rust, C, and C++, expanding the developer community, enhancing performance, reducing costs, and improving security, all while maintaining EVM compatibility. This fosters innovation without disruption, ensuring Arbitrum’s success. So we will vote FOR this proposal.
AIP: Support RIP-7212 for Account Abstraction Wallets
We will vote in favor of the proposal. There is no reason for us to vote against as this standard will enhance user experience, security, and functionality by integrating account abstraction wallets into ArbOS 3.0, promoting innovation and more sophisticated wallet solutions within the Arbitrum ecosystem.
We decided to vote in favor of this , as This will reduce the DAO’s administrative burden and streamline handling Nova fees. With clear benefits.
We recommend getting a confirmation on whether the latest version of these files were covered in the audit
Before voting for this update, I would like to receive a response to OpenZeppelin's comment
Tell me, were audits conducted for the new contracts I see that 43 files were changed. I understand that most of them are replacements
// SPDX-License-Identifier: UNLICENSED // SPDX-License-Identifier: MIT
But I would like to have an audit report.
In line with my previous comments at the Snapshot phase of these votes, voting "For" on Tally.
https://forum.arbitrum.foundation/t/aip-nova-fee-router-proposal-arbos-30/23310/8
We vote FOR the proposal on Tally.
We maintain our rationales below for each individual update and support a package of those updates to be deployed as "Bianca". We appreciate the proper audits on each implementation and OpenZeppelin's reviews as a part of ARDC works.
https://forum.arbitrum.foundation/t/aip-nova-fee-router-proposal-arbos-30/23310/25?u=tane
We are particularly excited to see Stylus finally going live!
I am voting in favor of this proposal on Tally. My voting rationale is aligned with the reasons that I previously mentioned on Snapshot for the individual components concerning ArbOS 31. You can read them here:
https://forum.arbitrum.foundation/t/aip-nova-fee-router-proposal-arbos-30/23310/12
I really appreciate the quality of this proposal and the efforts that were made to make it coherent and solid.
I voted FOR this proposal because it’s like giving Arbitrum a superhero upgrade:
Arbitrum Stylus: Now developers can whip up smart contracts in Rust and C++—faster, stronger, and definitely cooler.
New Precompile for secp256r1 Verification: Cuts verification costs by 99%, making passkey-based wallets cheaper, safer, and less of a headache for everyone.
Nova Fee Collection Update: It’s like giving the ArbitrumDAO a direct line to its piggy bank, making fund management smoother and less bureaucratic.
These upgrades aren’t just cool features; they’re going to supercharge Arbitrum’s scalability, security, and governance. Plus, with solid community backing and thorough audits, it’s clear that Arbitrum is leveling up in the best way possible.
I voted FOR this proposal on Tally, as I did for each of the three component temp checks.
https://forum.arbitrum.foundation/t/aip-nova-fee-router-proposal-arbos-30/23310/11?u=frisson
I voted FOR this proposal on Tally, as I did for each of the three component temp checks.
https://forum.arbitrum.foundation/t/aip-nova-fee-router-proposal-arbos-30/23310/11?u=frisson
https://forum.arbitrum.foundation/t/aip-support-rip-7212-for-account-abstraction-wallets-arbos-30/23298/19?u=frisson https://forum.arbitrum.foundation/t/aip-nova-fee-router-proposal-arbos-30/23310/11?u=frisson
I'm pleased with the level of technical rigor behind the onchain proposal. I appreciate the audits of each part, the ability the independently verify changes, and the review from OpenZeppelin as part of the ARDC.
Will post my complete rational later. But voting FOR in this proposal.
The following reflects the views of L2BEAT’s governance team, composed of @krst and @Sinkas, and it’s based on the combined research, fact-checking, and ideation of the two.
Having supported each individual upgrade included in ArbOS 31, we’ll be voting FOR this proposal during the onchain vote.
The following reflects the views of L2BEAT’s governance team, composed of @krst and @Sinkas, and it’s based on the combined research, fact-checking, and ideation of the two.
Having supported each individual upgrade included in ArbOS 31, we’ll be voting FOR this proposal during the onchain vote.
OpenZeppelin, in their capacity as the security member of the ARDC, conducted a review of the proposal’s executable and confirmed that the upgrade will only perform the actions described in the proposal. We also individually checked the contents of the proposal’s executable to confirm that they’ll only do what they describe. Both reviews found no issues, and therefore, we’re comfortable voting in favor.
Voted for this - three important upgrades in a single proposal. Enabling the precompile is a competitive necessity for account abstraction and wallet management in general, and Stylus opens the door to a richer future of possibilities for developers building on Arbitrum.
I voted yes, as Bianca is giving new tools like allowing Rust to be used as a programming language.
Should be this here https://forum.arbitrum.foundation/t/aip-arbos-31-proposal-review/26000/3?u=ezr3al
Blockworks Research will be voting FOR this proposal on Tally when live.
These upgrades are very important for the network moving forward. EIP/RIP-7212 will allow for much better gas optimization for smart wallet accounts using more traditional secp cryptographic curves which enables biometric signatures or other methods for wallet management, and Stylus will enable better and more diverse applications moving forward. This seems like a 'no brainer' for the DAO to support. Polygon, Optimism, and Base have already implemented RIP-7212, and it may be implemented as an EIP going forward so it's best to get ahead of the curve and join the others.
Here is our rationale for onchain voting:
AIP: Activate Stylus and Enable Next-Gen WebAssembly Smart Contracts
Here is our rationale for onchain voting:
AIP: Activate Stylus and Enable Next-Gen WebAssembly Smart Contracts
Stylus significantly improves Arbitrum by supporting Rust, C, and C++, expanding the developer community, enhancing performance, reducing costs, and improving security, all while maintaining EVM compatibility. This fosters innovation without disruption, ensuring Arbitrum’s success. So we will vote FOR this proposal.
AIP: Support RIP-7212 for Account Abstraction Wallets
We will vote in favor of the proposal. There is no reason for us to vote against as this standard will enhance user experience, security, and functionality by integrating account abstraction wallets into ArbOS 3.0, promoting innovation and more sophisticated wallet solutions within the Arbitrum ecosystem.
We decided to vote in favor of this , as This will reduce the DAO’s administrative burden and streamline handling Nova fees. With clear benefits.
We recommend getting a confirmation on whether the latest version of these files were covered in the audit
Before voting for this update, I would like to receive a response to OpenZeppelin's comment
Tell me, were audits conducted for the new contracts I see that 43 files were changed. I understand that most of them are replacements
// SPDX-License-Identifier: UNLICENSED // SPDX-License-Identifier: MIT
But I would like to have an audit report.
