Deploy a production chain: an overview
It is highly recommended that you work with a Rollup-as-a-Service (RaaS) provider to deploy a production chain. You can find a list of RaaS providers in our integrations directory.
Deploying new Arbitrum chains is done through a RollupCreator contract that processes the creation of the needed contracts and sends the initialization messages from the parent chain to the newly created Arbitrum chain. To assist with these operations, the Arbitrum chain SDK contains a series of tools and scripts that help create and manage your chain(s). Its capabilities include:
- Configuration and deployment of your Arbitrum chain's core contracts
- Configuration and deployment of the chain's TokenBridge contracts
- Initialization of your chain and management of its configuration post-deployment
This overview describes the process for creating a new Arbitrum chain, with each step linking to the appropriate guide to follow. You'll find guides to use the Arbitrum chain SDK for deploying a new chain, configuring your node, initializing your chain's configuration, and creating a token bridge.
It is recommended to use the Arbitrum chain SDK when deploying new chains and performing chain owner actions.
1. Select a chain type
There are two main types of Arbitrum chains. Review the following table to determine which type best fits your needs:
| Chain type | Description | Use case |
|---|---|---|
| Rollup | Offers Ethereum-grade security by batching, compressing, and posting data to the parent chain, similarly to Arbitrum One. | Ideal for applications that require high security guarantees. |
| AnyTrust | Implements the AnyTrust protocol, relying on an external Data Availability Committee (DAC) to store data and provide it on-demand, effectively using it as its Data Availability (DA) layer. | Suitable for applications that require lower transaction fees. |
Additionally, Arbitrum chains can be configured to use ETH or any standard ERC-20 token as the gas token. To understand the implications of using a custom gas token, see Configure a custom gas token.
2. Deploy your chain
After selecting a chain type, follow the chain deployment guide to deploy your chain using the Chain SDK.
3. Configure your Arbitrum chain's node
Once the chain is deployed, you'll need to generate the configuration to run its node. To learn how, visit Configure your Arbitrum chain's node.
4. Deploy your Arbitrum chain's token bridge
Your Arbitrum chain's token bridge contracts allow ERC-20 tokens to move between your Arbitrum chain and its underlying parent chain. Read Deploy your Arbitrum chain's token bridge to learn how to set up your bridge.
How the two factory contracts relate
The four steps above run through two separate factory contracts, in order. Knowing which one does what makes the deployment sequence easier to reason about when something fails partway.
RollupCreator runs first. It deploys your chain's core contracts — the Rollup, the sequencer inbox, the delayed inbox, the outbox, and the bridge — and sends the initialization messages that bring the chain to life.
TokenBridgeCreator runs afterward, and it depends on the first step having completed. It takes your chain's rollup or inbox address as input, deploys the parent chain half of the token bridge, and sends messages to the child chain to deploy the counterpart contracts there.
Two consequences follow from that ordering:
- The token bridge cannot be deployed first, or in parallel. It needs an inbox to send messages through, and that inbox does not exist until
RollupCreatorhas run. - The token bridge step sends retryable tickets, so it needs gas on the child chain. On a chain using a custom gas token, this means granting
TokenBridgeCreatoran allowance for that token before calling it, because it has to pay for execution on the far side. To learn how, see Deploy your Arbitrum chain's token bridge.
For the addresses of both factories on each supported parent chain, see Canonical factory contracts.