Skip to main content

Orbit chain ownership

A chain owner of an Orbit chain is an entity that can carry out critical upgrades to the chain's core protocol; this includes upgrading protocol contracts, setting core system parameters, and adding & removing other chain owners.

An Orbit chain's initial chain owner is set by the chain's creator when the chain is deployed.

The chain-ownership architecture is designed to give Orbit chain creators flexibility in deciding how upgrades to their chain occur.

PUBLIC PREVIEW CAPABILITY

Orbit chains are currently a public preview capability. This offering and its supporting documentation may change significantly as we capture feedback from readers like you.

To provide feedback, click the Request an update button at the top of this document, join the Arbitrum Discord, or reach out to our team directly by completing this form.

Architecture​

Chain ownership affordance is handled via Upgrade Executor contracts.

Each Orbit chain is deployed with two Upgrade Executors — one on the Orbit chain itself, and one on its parent chain. At deployment, the chain's critical affordances are given to the Upgrade Executor contracts.

Some examples:

  • The parent chain's core protocol contracts are upgradeable proxies that are controlled by a proxy admin; the proxy admin is owned by the Upgrade Executor on the parent chain.
  • The core Rollup contract's admin role is given to the Upgrade Executor on the parent chain.
  • The affordance to call setters the ArbOwner procompile — which allows for setting system gas parameters and scheduling ArbOS ugprades (among other things) — is given to the Upgrade Executor on the Orbit chain.

Calls to an Upgrade Executor can only be made by chain owners; e.g., entities granted the EXECUTOR_ROLE affordance on the Upgrade Executor. Upgrade executors also have the ADMIN_ROLE affordance granted to themselves, which lets chain owners add or remove chain owners.

With this architecture, the Upgrade Executor represents a single source of truth for affordances over critical upgradability of the chain.

Upgrades​

Upgrades occur via a chain owner initiating a call to an Upgrade Executor, which in turns calls some chain-owned contract.

Chain owners can either call UpgradeExecutor.executeCall, which will in turn call the target contract directly, or UpgradeExecutor.execute, which will delegate-call to an "action contract" and use its code to call the target contract.

The Arbitrum DAO governed chains, while not Orbit chains themselves, use a similar architecture and upgrade pattern; for more info and best practices on action contracts, see "DAO Governance Action Contracts".

(NOTE: The DAO Governed chains' Upgrade Executor contracts don't have the .executeCall method; only the .execute method)