Warning
This repository is a work in progress. At a later date, it will be proposed to, and must be approved by, Optimism Governance. Until that time, the configuration described here is subject to change.
The Superchain Registry is an index of chains which serves as the source of truth for who’s in the Superchain Ecosystem and what modifications they’ve made to their chains.
The Superchain Registry hosts Superchain-configuration data in a minimal human-readable form and includes mainnet and testnet Superchain targets, along with their respective member chains.
Other configurations, such as contract-permissions and SystemConfig
parameters, are hosted and governed onchain.
A list of chains in the registry can be seen in the top level chainList.toml
and chainList.json
files.
These files are autogenerated from scripts in the registry and will remain stable to build against.
A glossary, with key terms and more information about Superchain levels and requirements, is available here.
The Superchain configs are stored in a minimal form and embedded in downstream OP-Stack software (op-node
and op-geth
). This means that after a chain has been added to the registry and the dependency on the registry updates in the downstream software, it is possible to start an op-node
instance using the --network
flag (and also an op-geth
instance using the --op-network
tag) which will successfully sync with other nodes on that network.
If you would like your chain to automatically receive superchain-wide coordinated hardfork activations, you can enable this by:
- Adding your chain as above
- Ensuring the
superchain_time
in your chain's config is set to an appropriate value. Set it to0
if you want to receive all superchain forks that occur after your chain's genesis, and you have activated all superchain forks up to your genesis time at genesis. - Having that value reflected in the
main
branch well in advance of the testnet (resp. mainnet) release ofop-geth
andop-node
. - Having your chain's nodes started with the network flags.
This is explained in more detail in this specification on hardfork activation inheritance behavior.
MIT License, see LICENSE
file.