OP Stack Configurability

Table of Contents

Consensus Parameters
Policy Parameters
Admin Roles
Service Roles

When deploying the OP Stack software to a production environment, certain parameters about the protocol can be configured. These configurations can include a variety of parameters which affect the resulting properties of the blockspace in question.

There are four categories of OP Stack configuration options:

Consensus Parameters: Parameters and properties of the chain that may be set at genesis and fixed for the lifetime of the chain, or may be changeable through a privileged account or protocol upgrade.
Policy Parameters: Parameters of the chain that might be changed without breaking consensus. Consensus is enforced by the protocol, while policy parameters may be changeable within constraints imposed by consensus.
Admin Roles: These roles can upgrade contracts, change role owners, or update protocol parameters. These are typically cold/multisig wallets not used directly in day to day operations.
Service Roles: These roles are used to manage the day-to-day operations of the chain, and therefore are often hot wallets.

Each category also defines the standard configuration values for it's given parameters. Standard configuration is the set of requirements for an OP Stack chain to be considered a Standard Chain within the superchain. These requirements are currently a draft, pending governance approval.

The recommended way to deploy L1 contracts for an OP chain that meet the standard configuration will be with the OP Contracts Manager.

Consensus Parameters

Batch Inbox address

Description: L1 address where calldata/blobs are posted ( see Batcher Transaction).
Administrator: Static
Requirement: Current convention is versionByte || keccak256(bytes32(chainId))[:19], where || denotes concatenation, versionByte is 0x00, and chainId is a uint256.
Notes: It is recommended, but not required, to follow this convention.

Batcher Hash

Description: A versioned hash of the current authorized batcher sender(s).
Administrator: System Config Owner
Requirement: bytes32(uint256(uint160(batchSubmitterAddress)))
Notes: Batch Submitter address padded with zeros to fit 32 bytes.

Chain ID

Description: Unique ID of Chain used for TX signature validation.
Administrator: Static
Requirement: Foundation-approved, globally unique value ¹.
Notes: Foundation will ensure chains are responsible with their chain IDs until there's a governance process in place.

Proof Maturity Delay

Description: The length of time that must pass between proving and finalizing a withdrawal.
Administrator: L1 Proxy Admin
Requirement: 7 days
Notes: High security. Excessively safe upper bound that leaves enough time to consider social layer solutions to a hack if necessary. Allows enough time for other network participants to challenge the integrity of the corresponding output root.

Dispute Game Finality

Description: The amount of time given to the Guardian role to blacklist a resolved dispute game before any withdrawals proven against it can be finalized, in the case of a system failure.
Administrator: L1 Proxy Admin
Requirement: 3.5 days
Notes: High security. Allows enough time for the Guardian to blacklist games.

Respected Game Type

Description: The respected game type of the OptimismPortal. Determines the type of dispute games that can be used to finalize withdrawals.
Administrator: Guardian
Requirement: CANNON ( 0)
Notes: The game type may be changed to PERMISSIONED_CANNON ( 1) as a fallback to permissioned proposals, in the event of a failure in the Fault Proof system.

Fault Game Max Depth

Description: The maximum depth of fault dispute game trees.
Administrator: Static
Requirement: 73
Notes: Sufficiently large to ensure the fault proof VM execution trace fits within the number of leaf nodes.

Fault Game Split Depth

Description: The depth in fault dispute game trees after which claims correspond to VM state commitments instead of output root commitments.
Administrator: Static
Requirement: 30
Notes: Sufficiently large to ensure enough nodes at the split depth to represent all L2 blocks since the anchor state.

Max Game Clock Duration

Description: The maximum amount of time that may accumulate on a dispute game team's chess clock.
Administrator: Static
Requirement: 3.5 days
Notes: High security. Allows enough time for honest actors to counter invalid claims.

Game Clock Extension

Description: The flat credit that is given to a dispute game team's clock if their clock has less than CLOCK_EXTENSION seconds remaining.
Administrator: Static
Requirement: 3 hours
Notes: Allows enough time for honest actors to counter freeloader claims.

Bond Withdrawal Delay

Description: The length of time that must pass before dispute game bonds can be withdrawn.
Administrator: Static
Requirement: 7 days
Notes: High security. Allows enough time for the Guardian to recover funds from DelayedWETH if bonds were allocated incorrectly.

Minimum Large Preimage Proposal Size

Description: The minimum size of preimage allowed to be submitted via the PreimageOracle large preimage proposal process.
Administrator: Static
Requirement: 126000 bytes
Notes: Large enough to ensure posting the large preimage is expensive enough to act as a deterrent but small enough to be used for any preimage that is too large to be submitted in a single transaction.

Large Preimage Proposal Challenge Period

Description: The amount of time that large preimage proposals can be challenged before they can be published to the PreimageOracle
Administrator: Static
Requirement: 24 hours
Notes: High security. Allows enough time for honest actors to challenge invalid large preimage proposals.

Fault Game Absolute Prestate

Description: The VM state commitment to use as the starting point when executing the fault proof VM
Administrator: Static
Requirement: The state commitment of a governance approved op-program release.
Notes: The op-program version must have the rollup config and L2 genesis of the chain built in via the superchain registry.

Fault Game Genesis Block

Description: The L2 block number used as the initial anchor state for fault dispute games
Administrator: Static
Requirement: Block number of any finalized block between bedrock activation and enabling fault proofs. 0 for chains using fault proofs from genesis.

Fault Game Genesis Output Root

Description: The output root at the Fault Game Genesis Block
Administrator: Static
Requirement: The output root from the canonical chain at Fault game Genesis Block.

Fee Scalar

Description: Markup on transactions compared to the raw L1 data cost.
Administrator: System Config Owner
Requirement: Set such that Fee Margin is between 0 and 50%.

Gas Limit

Description: Gas limit of the L2 blocks is configured through the system config.
Administrator: System Config Owner
Requirement: No higher than 200_000_000 gas
Notes: Chain operators are driven to maintain a stable and reliable chain. When considering to change this value, careful deliberation is necessary.

Genesis state

Description: Initial state at chain genesis, including code and storage of predeploys (all L2 smart contracts). See Predeploy.
Administrator: Static
Requirement: Only standard predeploys and preinstalls, no additional state.
Notes: Homogeneity & standardization, ensures initial state is secure.

L2 block time

Description: Frequency with which blocks are produced as a result of derivation.
Administrator: L1 Proxy Admin
Requirement: 1 or 2 seconds
Notes: High security & interoperability compatibility requirement, until de-risked/solved at app layer.

Resource config

Description: Config for the EIP-1559 based curve used for the deposit gas market.
Administrator: L1 Proxy Admin
Requirement: See resource config table.
Notes: Constraints are imposed in code when setting the resource config.

Sequencing window Size

Description: Maximum allowed batch submission gap, after which L1 fallback is triggered in derivation.
Administrator: Static
Requirement: 3_600 base layer blocks (12 hours for an L2 on Ethereum, assuming 12 second L1 blocktime). e.g. 12 second blocks, $3600 * 12 seco n d s \div 60 \frac{seco n d s}{min u t e} \div 60 \frac{min u t e}{h o u r} = 12 h o u rs$ .
Notes: This is an important value for constraining the sequencer's ability to re-order transactions; higher values would pose a risk to user protections.

Start block

Description: Block at which the system config was initialized the first time.
Administrator: L1 Proxy Admin
Requirement: The block where the SystemConfig was initialized.
Notes: Simple clear restriction.

Superchain target

Description: Choice of cross-L2 configuration. May be omitted in isolated OP Stack deployments. Includes SuperchainConfig and ProtocolVersions contract addresses.
Administrator: Static
Requirement: Mainnet or Sepolia
Notes: A superchain target defines a set of layer 2 chains which share SuperchainConfig and ProtocolVersions contracts deployed on layer 1.

Governance Token

Description: OP token used for the Optimism Collective's Token House governance.
Administrator: n/a
Requirement: Disabled
Notes: Simple clear restriction.

The chain ID must be globally unique among all EVM chains.

Resource Config

Config Property	Standard Config Requirement
maxResourceLimit	$2 * 1 0^{7}$
elasticityMultiplier	$10$
baseFeeMaxChangeDenominator	$8$
minimumBaseFee	$1 * 1 0^{9}$
systemTxMaxGas	$1 * 1 0^{6}$
maximumBaseFee	$2^{128}$ -1

Policy Parameters

Data Availability Type

Description: Batcher can currently be configured to use blobs or calldata ( See Data Availability Provider).
Administrator: Batch submitter address
Requirement: Ethereum (Blobs, Calldata)
Notes: Alt-DA is not yet supported for the standard configuration, but the sequencer can switch at-will between blob and calldata with no restriction, since both are L1 security.

Batch submission frequency

Description: Frequency with which batches are submitted to L1 ( see Batcher Transaction).
Administrator: Batch submitter address
Requirement: 1_800 base layer blocks (6 hours for an L2 on Ethereum, assuming 12 second L1 blocktime) or lower
Notes: Batcher needs to fully submit each batch within the sequencing window, so this leaves buffer to account for L1 network congestion and the amount of data the batcher would need to post.

Output frequency

Description: Frequency with which output roots are submitted to L1.
Administrator: L1 Proxy Admin
Requirement: 43_200 L2 Blocks (24 hours for an L2 on Ethereum, assuming 2 second L2 blocktime) or lower e.g. 2 second blocks, $43200 * 2 seco n d s \div 60 \frac{seco n d s}{min u t e} \div 60 \frac{min u t e}{h o u r} = 24 h o u rs$ .
Notes: Deprecated once fault proofs are implemented. This value cannot be 0.

Admin Roles

L1 Proxy Admin

Description: Account authorized to upgrade L1 contracts.
Administrator: L1 Proxy Admin Owner
Administers: Batch Inbox Address, Start block, Proposer address, Challenger address, Guardian address, Proof Maturity Delay, Dispute Game Finality, Output frequency, L2 block time, L1 smart contracts
Requirement: ProxyAdmin.sol from the latest op-contracts/vX.Y.X release of source code in Optimism repository.
Notes: Governance-controlled, high security.

L1 ProxyAdmin owner

Description: Account authorized to update the L1 Proxy Admin.
Administrator:
Administers: L1 Proxy Admin
Requirement: 0x5a0Aae59D09fccBdDb6C6CcEB07B7279367C3d2A ²
Notes: Governance-controlled, high security.

L2 Proxy Admin

Description: Account authorized to upgrade L2 contracts.
Administrator: L2 Proxy Admin Owner
Administers: Predeploys
Requirement: ProxyAdmin.sol from the latest op-contracts/vX.Y.X release of source code in Optimism repository. Predeploy address: 0x4200000000000000000000000000000000000018.
Notes: Governance-controlled, high security.

L2 ProxyAdmin owner

Description: Account authorized to upgrade protocol contracts via calls to the ProxyAdmin. This is the aliased L1 ProxyAdmin owner address.
Administrator:
Administers: L2 Proxy Admin
Requirement: Gnosis Safe between Optimism Foundation (OF) and the Security Council (SC). Aliased Address: 0x6B1BAE59D09fCcbdDB6C6cceb07B7279367C4E3b ³
Notes: Governance-controlled, high security.

System Config Owner

Description: Account authorized to change values in the SystemConfig contract. All configuration is stored on L1 and picked up by L2 as part of the derivation of the L2 chain.
Administrator: L1 Proxy Admin
Administers: Batch submitter address, Sequencer P2P / Unsafe head signer, Fee Margin, Gas limit, System Config Owner
Requirement: Chain Governor or Servicer
Notes: As defined in the Law of Chains

2 of 2 GnosisSafe between Optimism Foundation (OF) and the Security Council (SC) on L1. Mainnet and Sepolia addresses can be found at privileged roles.

Aliased address of the 2 of 2 Gnosis Safe between Optimism Foundation (OF) and the Security Council (SC) on L1. The reason for aliasing can be found in the glossary. This address was calculated using the following arithmetic: 0x5a0Aae59D09fccBdDb6C6CcEB07B7279367C3d2A + 0x1111000000000000000000000000000000001111 = 0x6B1BAE59D09fCcbdDB6C6cceb07B7279367C4E3b.

Service Roles

Batch submitter address

Description: Account which authenticates new batches submitted to L1 Ethereum.
Administrator: System Config Owner
Requirement: No requirement
Notes:

Challenger address

Description: Account which can interact with existing permissioned dispute games.
Administrator: L1 Proxy Admin
Requirement: 0x9BA6e03D8B90dE867373Db8cF1A58d2F7F006b3A ⁴
Notes: Optimism Foundation (OF) multisig leveraging battle-tested software. This role is only active when the OptimismPortal respected game type is [PERMISSIONED_CANNON] (https://github.com/ethereum-optimism/optimism/blob/op-contracts/v1.5.0/packages/contracts-bedrock/src/dispute/lib/Types.sol#L31).

Guardian address

Description: Account authorized to pause L1 withdrawals from contracts, blacklist dispute games, and set the respected game type in the OptimismPortal.
Administrator: L1 Proxy Admin
Requirement: 0x09f7150D8c019BeF34450d6920f6B3608ceFdAf2
Notes: A 1/1 Safe owned by the Security Council Safe, with the Deputy Guardian Module enabled to allow the Optimism Foundation to act as Guardian.

Proposer address

Description: Account which can create and interact with permissioned dispute games on L1.
Administrator: L1 Proxy Admin
Requirement: No requirement
Notes: This role is only active when the OptimismPortal respected game type is [PERMISSIONED_CANNON] (https://github.com/ethereum-optimism/optimism/blob/op-contracts/v1.5.0/packages/contracts-bedrock/src/dispute/lib/Types.sol#L31). The L1ProxyAdmin sets the implementation of the PERMISSIONED_CANNON game type. Thus, it determines the proposer configuration of the permissioned dispute game.

Sequencer P2P / Unsafe head signer

Description: Account which authenticates the unsafe/pre-submitted blocks for a chain at the P2P layer.
Administrator: System Config Owner
Requirement: No requirement
Notes:

⁴

5 of 7 GnosisSafe controlled by Optimism Foundation (OF). Mainnet and Sepolia addresses can be found at privileged roles.

OP Stack Specification