OP Stack Configurability
Table of Contents
- Consensus Parameters
- Batch Inbox address
- Batcher Hash
- Chain ID
- Proof Maturity Delay
- Dispute Game Finality
- Respected Game Type
- Fault Game Max Depth
- Fault Game Split Depth
- Max Game Clock Duration
- Game Clock Extension
- Bond Withdrawal Delay
- Minimum Large Preimage Proposal Size
- Large Preimage Proposal Challenge Period
- Fault Game Absolute Prestate
- Fault Game Genesis Block
- Fault Game Genesis Output Root
- Fee Scalar
- Gas Limit
- Genesis state
- L2 block time
- Resource config
- Sequencing window Size
- Start block
- Superchain target
- Governance Token
- Resource Config
- 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 1.
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, .
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 | |
elasticityMultiplier | |
baseFeeMaxChangeDenominator | |
minimumBaseFee | |
systemTxMaxGas | |
maximumBaseFee | -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, .
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
2
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
3
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:
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
4
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.