Skip to main content
The init command is used to create a new intent and state file in the specified directory. This command is the starting point of each new deployment.

​
Usage

The init command is used like this: 
op-deployer init \
  --l1-chain-id <chain ID of your L1> \
  --l2-chain-ids <comma separated list of chain IDs for your L2s> \
  --outdir <directory to write the intent and state files> \
  --intent-type <standard/custom/standard-overrides>
You should then see the following files appear in your output directory: 
outdir
├── intent.toml
└── state.json
The intent.toml file is where you specify the configuration for your deployment. The state.json file is where OP Deployer will output the current state of the deployment after each stage of the deployment.

​
Intent File

Your intent should look something like this: 
configType = "standard"
l1ChainID = 11155420
fundDevAccounts = false
useInterop = false
l1ContractsLocator = "tag://op-contracts/v1.8.0-rc.4"
l2ContractsLocator = "tag://op-contracts/v1.7.0-beta.1+l2-contracts"

[superchainRoles]
  proxyAdminOwner = "0xeAAA3fd0358F476c86C26AE77B7b89a069730570"
  protocolVersionsOwner = "0xeAAA3fd0358F476c86C26AE77B7b89a069730570"
  guardian = "0xeAAA3fd0358F476c86C26AE77B7b89a069730570"

[[chains]]
  id = "0x0000000000000000000000000000000000000000000000000000000000002390"
  baseFeeVaultRecipient = "0x0000000000000000000000000000000000000000"
  l1FeeVaultRecipient = "0x0000000000000000000000000000000000000000"
  sequencerFeeVaultRecipient = "0x0000000000000000000000000000000000000000"
  operatorFeeVaultRecipient = "0x0000000000000000000000000000000000000000"
  eip1559DenominatorCanyon = 250
  eip1559Denominator = 50
  eip1559Elasticity = 6

  # Revenue Sharing Configuration
  useRevenueShare = true
  chainFeesRecipient = "0x0000000000000000000000000000000000000000"

  [chains.roles]
    l1ProxyAdminOwner = "0x0000000000000000000000000000000000000000"
    l2ProxyAdminOwner = "0x0000000000000000000000000000000000000000"
    systemConfigOwner = "0x0000000000000000000000000000000000000000"
    unsafeBlockSigner = "0x0000000000000000000000000000000000000000"
    batcher = "0x0000000000000000000000000000000000000000"
    proposer = "0x0000000000000000000000000000000000000000"
    challenger = "0x0000000000000000000000000000000000000000"
Before you can use your intent file for a deployment, you will need to update all zero values to whatever is appropriate for your chain. For dev environments, it is ok to use all EOAs/hot-wallets.

​
Revenue Sharing Configuration

The useRevenueShare field controls whether your chain enables the revenue sharing system feature:
  • useRevenueShare = true (default for standard configurations): FeeVaults are upgraded and configured to use the FeeSplitter contract as the recipient, L2 as withdrawal network and 0 as the minimum withdrawal amount. The split logic is calculated using the SuperchainRevSharesCalculator contract. The L1Withdrawer contract is set to withdraw the OP portion of fees automatically.
  • useRevenueShare = false: FeeSplitter is deployed but initialized with zero address for the sharesCalculator field. No deployment is made for the SuperchainRevSharesCalculator and L1Withdrawer contracts. FeeVaults are upgraded but initialized using the custom configuration you provide.

​
Configuration Fields

  • useRevenueShare (optional): Enables or disables the revenue sharing system. Defaults to true for standard configurations, false for custom.
  • chainFeesRecipient (required when useRevenueShare = true): Address that receives the chain operator’s portion of fee revenue on L2. Must be able to receive ETH.
Since useRevenueShare defaults to true for standard configurations, you must either provide a chainFeesRecipient address OR explicitly set useRevenueShare = false to opt out. The deployment will fail validation if revenue sharing is enabled without a recipient.

​
Production Setup

In production environments, you should use a more secure setup with cold-wallet multisigs (e.g. Gnosis Safes) for the following:
  • baseFeeVaultRecipient
  • l1FeeVaultRecipient
  • sequencerFeeVaultRecipient
  • operatorFeeVaultRecipient
  • l1ProxyAdminOwner
  • l2ProxyAdminOwner
  • systemConfigOwner
HSMs (hardware security modules) are recommended for the following hot-wallets:
  • unsafeBlockSigner
  • batcher
  • proposer
  • challenger