Skip to main content
The superchain-registry serves as the source of truth for OP Stack chain classification and what modifications chains have made. The superchain-registry introduces:
  • A step-by-step process new chains can follow to join the registry
  • Validation checks to ensure standard chains comply with the Standard Rollup Charter and non-standard chains pass baseline validation before joining the superchain-registry
  • A repository that shows who’s in the registry and each chain’s configuration
The main benefit of joining the registry is a practical one: a registered chain’s genesis and rollup configuration are baked into releases of the canonical OP Stack node software, including op-node and op-reth. Operators and node runners can start a node against a registered chain simply by passing its name to the client’s network flag, with no need to hand-distribute configuration files. See hard fork activation inheritance behavior below for the exact flags. Registration also lists your chain publicly alongside its configuration and signals reliability and alignment with the OP Stack ecosystem.

​
What is a standard chain?

The standard configuration within the OP Stack ensures that chains deployed in the OP Stack ecosystem adhere to a consistent set of technical and governance parameters. This standardization is critical for OP Stack interoperability, network security, and ease of upgrading your chain. This configuration targets the highest bar for security, uptime, and decentralization in the OP Stack ecosystem. For the parameter values themselves, consult the OP Stack Configurability Specification. A standard chain in the OP Stack refers to a rollup that adheres to the following principles:
  1. Technical conformance:
    • Compliance with the consensus parameters, policy parameters, admin roles, and service roles defined in the specifications. For more details, please see the OP Stack Configurability Specification.
    • Utilization of officially supported features and modules of the OP Stack.
  2. Governance alignment:
    • Adherence to the Standard Rollup Charter.
    • Transparent and collaborative decision-making aligned with the OP Stack ecosystem.
  3. Interoperability:
    • Standard chains get Superchain interop by default: they can exchange cross-chain messages and assets with other standard chains under identical trust assumptions.
Chains that deviate from these principles, such as introducing unsupported features, are considered non-standard configurations. For example, any alterations to core system contracts break standardization and aren’t supported in the official OP Stack specification. For a detailed list of standard configurations, refer to the Standard Rollup Charter documentation.

​
Why standardization matters

Standardization benefits the OP Stack ecosystem in several ways:
  • Interoperability: A standard stack and security model gives your chain interop with other standard chains by default, such as single block cross-chain messaging and token transfers, with identical trust assumptions across all interoperating chains.
  • Simplified upgrade path: Reduces the complexity of upgrading your chain to the latest version.
  • Reduced support overhead: Minimizes the need for custom support by ensuring uniformity across deployments.
Two features define a standard chain in practice:
  • Default system contracts: Core protocol contracts must use governance approved release implementations of the OP Stack to provide security and compatibility.
  • Specified sequencer configurations: Sequencer settings must follow prescribed parameters for transaction ordering and submission to maintain network stability.

​
Role of op-deployer in standardization

The op-deployer is a tool designed to automate and streamline the deployment of standard configuration-compliant chains. Key features include:
  • Default values: op-deployer provides default values that adhere to standard specifications.
  • Ease of customization within standards: The op-deployer tool allows for overriding default values. For example, you can override the L2 block time to 1s, which is standard. However, please ensure you know what you’re doing when applying overrides because they may violate standard specifications.
By using op-deployer, chain operators can reduce the complexity of chain deployment while ensuring alignment with OP Stack standards.
We strongly recommend using the op-deployer to deploy L1 contracts and generate the L2 genesis file that meets the configuration requirements outlined in the Standard Rollup Charter.

​
Joining the Registry

To join the Registry, follow the Join the Superchain Registry guide to submit a pull request and join the Registry. This guide will help you set up your chain, create your environment, and run all the validation checks needed to ensure your chain is ready to join the Registry.

​
Hard fork activation inheritance behavior

After being included into the superchain-registry, subsequent releases of the op-node and op-geth will contain the chain’s genesis and rollup configurations baked in. You can use then use the --network (op-node) and --op-network (op-geth) flags to start up your node with this information. Using these flags means that the node will automatically inherit the hard fork activation times from the superchain-registry, so you don’t need to manually set them in your node configuration. Additionally, chains can opt into the hard fork activation inheritance behavior by specifying the superchain_time in the chain’s TOML file to start inheriting OP Stack wide activation timestamps. Networks that utilize this mechanism will activate network hard forks specified in the superchain.toml files: Sepolia superchain.toml and Mainnet superchain.toml.