A set of contracts that are similar to Arbitrum gov-action-contracts, but are designed to be used with the Orbit chains.
yarn and foundry are required to run the scripts
Most of the action contracts only support the following ownership setup:
- Rollup Contract on Parent Chain owned by a
ParentUpgradeExecutor
- Rollup ProxyAdmin on Parent Chain owned by a
ParentUpgradeExecutor
- Arb Owner on the Child Orbit Chain is granted to alias of
ParentUpgradeExecutor
- Arb Owner on the Child Orbit Chain is granted to
ChildUpgradeExecutor
For token bridge related operations, these are the additional requirements:
- Token Bridge ProxyAdmin on Parent Chain owned by
ParentUpgradeExecutor
- Token Bridge ProxyAdmin on Child Orbit Chain owned by
ChildUpgradeExecutor
- Parent Chain Gateway Router and Custom Gateway owned by
ParentUpgradeExecutor
yarn install
Run the follow command to check the version of Nitro contracts deployed on the parent chain of your Orbit chain.
$ INBOX_ADDRESS=0xaE21fDA3de92dE2FDAF606233b2863782Ba046F9 yarn orbit:contracts:version --network arb1
Get the version of Orbit chain's nitro contracts (inbox 0xaE21fDA3de92dE2FDAF606233b2863782Ba046F9), hosted on chain 42161
Version of deployed Inbox: v1.1.1
Version of deployed Outbox: v1.1.1
Version of deployed SequencerInbox: v1.1.1
Version of deployed Bridge: v1.1.1
Version of deployed RollupProxy: v1.1.1
Version of deployed RollupAdminLogic: v1.1.1
Version of deployed RollupUserLogic: v1.1.1
This deployment can be upgraded to v1.2.1 using NitroContracts1Point2Point1UpgradeAction
For other networks, replace arb1
with the network name and configure INFURA_KEY or the rpc in hardhat.config.ts
This section is also referenced in the documentation on "How to upgrade ArbOS on your Orbit chain" as Step 2 and Step 3.
For ArbOS upgrades, a common pre-requisite is to deploy new Nitro contracts to the parent chain of your Orbit chain before scheduling the ArbOS upgrade. These contracts include the rollup logic, fraud proof contracts, and interfaces for interacting with Nitro precompiles. The scripts and instructions in this repository are meant for Orbit chain owners to upgrade the aforementioned contracts, set the new WASM module root, and then schedule the ArbOS upgrade.
Nitro contracts 2.1.0 (for ArbOS 32 Bianca)
The nitro-contracts 2.1.0
upgrade action will deploy nitro-contracts v2.1.0
contracts to your Orbit's parent chain. Note that this action will only work for chains with nitro-contracts v1.2.1
or nitro-contracts v1.3.0
.
Note: nitro contracts upgrade brings support for AnyTrust fast confirmations and Stylus. However, Stylus will be enabled only when ArbOS 32 Bianca
upgrade takes place, once it will be officially supported for Orbit chains.
Nitro contracts 1.2.1 (for ArbOS 20 Atlas)
The nitro-contracts 1.2.1
upgrade action will deploy nitro-contracts v1.2.1
contracts to your Orbit's parent chain. Note that this action will only work for chains with nitro-contracts v1.1.0
or nitro-contracts v.1.1.1
. ArbOS 20 Atlas, shipped via Nitro v2.3.0, requires nitro-contracts v1.2.1
or higher.
This section is also referenced in the documentation on "How to upgrade ArbOS on your Orbit chain"
Next, you will need to schedule the actual upgrade using the ArbOS upgrade at timestamp action.
This action schedule an upgrade of the ArbOS to a specific version at a specific timestamp.
Here is a list of common upgrade paths that can be used to upgrade the Orbit chains. These instructions are duplicated from the docs on How to upgrade ArbOS on your Orbit chain, specifically Steps 1 through 3. Step 4 is mentioned below under "Other Actions".
- Upgrade your Nitro node(s) to Nitro v3.1.2
- Upgrade
nitro-contracts
to2.1.0
using nitro-contract 2.1.0 upgrade action - Schedule the ArbOS 32 Bianca upgrade using ArbOS upgrade at timestamp action
- Upgrade your Nitro node(s) to Nitro v2.3.1
- Upgrade
nitro-contracts
tov1.2.1
using nitro-contract 1.2.1 upgrade action - Schedule the ArbOS 20 Atlas upgrade using ArbOS upgrade at timestamp action
Below are additional on-chain actions that Orbit chain owners and maintainers can take as part of Step 4: Enable ArbOS specific configurations or feature flags.
See setCacheManager.