🎉 We are deprecating the Optimism SDK and migrating all tutorials to use viem/op-stack. Read more →
Builders
Chain operators
Deployment
Contract deployment

OP Stack smart contract deployment

⚠️

This page is out of date and shows the legacy method for smart contract deployment. For the latest recommended method, use op-deployer.

The following guide shows you how to deploy the OP Stack L1 smart contracts. The primary development branch is develop, however you should only deploy official contract releases. You can visit the see the smart contract overview for the official release versions. Changes to the smart contracts are generally not considered backwards compatible.

💡

Standard OP Stack chains should use the latest governance approved and audited versions of the smart contract code.

Deployment configuration

Deploying your OP Stack contracts requires creating a deployment configuration JSON file. You will create a new deployment configuration file in the following monorepo subdirectory: packages/contracts-bedrock/deploy-config (opens in a new tab) For the full set of deployment configuration options and their meanings, you can see the rollup deployment configuration page.

Deployment script

The smart contracts are deployed using foundry (opens in a new tab) and you can find the script's source code in the monorepo at packages/contracts-bedrock/scripts/deploy/Deploy.s.sol (opens in a new tab).

State diff

Before deploying the contracts, you can verify the state diff by using the runWithStateDiff() function signature in the deployment script, which produces the outputs inside snapshots/state-diff/ (opens in a new tab). Run the deployment with state diffs by executing:

forge script -vvv scripts/deploy/Deploy.s.sol:Deploy --sig 'runWithStateDiff()' --rpc-url $ETH_RPC_URL --broadcast --private-key $PRIVATE_KEY

Execution

  • Set the ETHERSCAN_API_KEY and add the --verify flag to verify your contracts.
  • DEPLOYMENT_OUTFILE will determine the filepath that the deployment artifact is written to on disk after the deployment. It comes in the form of a JSON file where keys are the names of the contracts and the values are the addresses the contract was deployed to.
  • DEPLOY_CONFIG_PATH is the path on the filesystem that points to a deployment config. The same deployment config JSON file should be used for L1 contracts deployment as when generating the L2 genesis allocs. See the deploy-config (opens in a new tab) directory for examples and the rollup configuration page for descriptions of the values.
  • IMPL_SALT env var can be used to set the create2 salt for deploying the implementation contracts.

This will deploy an entire new system of L1 smart contracts, including a new SuperchainConfig. In the future, there will be an easy way to deploy only proxies and use shared implementations for each of the contracts as well as a shared SuperchainConfig contract.

DEPLOYMENT_OUTFILE=deployments/artifact.json \
DEPLOY_CONFIG_PATH=<PATH_TO_MY_DEPLOY_CONFIG> \
  forge script scripts/deploy/Deploy.s.sol:Deploy \
  --broadcast --private-key $PRIVATE_KEY \
  --rpc-url $ETH_RPC_URL

Deploying a single contract

All functions for deploying a single contract are public, meaning that the --sig argument to forge script can be used to target the deployment of a single contract.

Best practices

Production users should deploy their L1 contracts from a contracts release. All contracts releases are on git tags with the following format: op-contracts/vX.Y.Z. If you're deploying a new standard chain, you should deploy the Fault Proof Fixes release (opens in a new tab) with the permissioned game type enabled. Starting with permissioned fault proofs gives chain operators time to get comfortable running the additional infrastructure requirements: op-challenger (opens in a new tab) and monitoring (opens in a new tab). There are also additional changes to the economics of operating a permissionless fault proof that chain operators should have a firm understanding of.

Next steps