Skip to main content

Post-launch deployment of deterministic contracts

Some forms of contract deployment rely on pre-made transactions with hardcoded gas limits designed for non-Arbitrum chains that only cover execution gas. Since Arbitrum also charges for data posting, these limits may be too low, causing transactions to fail. This page describes a safe, permissionless post-launch deployment method for such cases.

Using this approach, you can deploy contracts like Multicall3, the EntryPoint contract, or a create2 factory to a live Orbit chain without needing to modify chain configuration. It leverages Arbitrum's cross-chain messaging infrastructure via the Inbox.sendL2Message function, which submits a pre-signed child chain transaction from the parent chain. Unlike retryable tickets, these messages incur parent chain data fees only at submission and aren’t subject to the 100,000 gas cap imposed on deterministic deployment flows.

When to use this method​

This approach is useful when:

  • Your Orbit chain is already live.
  • You want to deploy a contract at a specific address (e.g., using create2).
  • The chain's genesis configuration did not include the contract.

Common examples include deployments of contracts like Multicall3, the ERC-4337 EntryPoint contract, or a create2 factory/deterministic deployment proxy. Note that if deployFactoriesToL2 is set to true when calling createRollup(), the following contracts are deployed to the Orbit chain by default:

Overview​

To deploy a contract post-launch:

1. Fund the deployer address on the child chain: Send ETH to the child chain address that will send the deployment transaction. Funding is possible using a retryable ticket or Parent-to-Child chain deposit.

2. Create the signed child chain transaction: Construct and sign a raw child chain transaction that performs the contract deployment (e.g., using create2). DeployHelper.sol can be used as a reference for formatting the transaction.

3. Send the message from the parent chain: Call Inbox.sendL2Message(bytes calldata message) on the Orbit chain’s inbox contract. Provide the signed transaction as the input.

4. Wait for the transaction to be executed on the child chain: The child chain will process and execute the message as a regular transaction. This flow does not use retryables, so if the transaction fails, it is not auto-retried and the nonce is consumed. This means the same transaction cannot be replayed, and a new transaction with a higher nonce must be created and submitted.

warning

Make sure that the deployer address is sufficiently funded on the child chain before sending the transaction. If the transaction runs out of gas or fails for any reason, the associated nonce will be burned. This means that the contract cannot be deployed at the predetermined deterministic address, potentially breaking tooling and integrations that rely on that specific address.

Advantages and considerations​

This approach avoids parent chain data fees and bypasses the 100,000 gas limit associated with retryable tickets. It also requires no chain upgrade or restart and works on any standard Arbitrum or Orbit chain setup. However, failed transactions are not automatically retried since the flow bypasses retryable safety mechanisms. The sender must have enough ETH on child chain to cover gas costs, and the signed transaction must be valid and use the correct nonce.