<aside> 💡

This doc helps you understand what you need to do as an engineer managing a release (such as a hardfork or contract upgrade) to ensure the superchain-registry does not become stale or broken.

</aside>

Context

The what

The superchain registry is a repo containing (at least):

• Data backend several data files (TOML, JSON.GZ) for each chain which has been added
• Go bindings a superchain Go module which embeds that data and exports it (strongly typed and checked for consistency at init time)
• Chain insertion tooling: an add-chain Go module consisting of tooling to add a new chain, which scrapes data from rollup.json and genesis.json
  • associated tests and testdata
• Validation suite a validation Go module which embeds the standard configuration and also runs tests in CI against that configuration
• Diff bots github actions which run on PRs and detect if the PR will modify the effective configuration which will be read by downstream OPStack software (op-node and op-geth). They will comment on the PR if a change is detected.

For more information on architecture, see ‣

The why

A release could be:

• a hardfork being rolled out to OP Mainnet and other chains in the superchain
• a contract upgrade on OP Mainnet

A release might:

• break the chain insertion tooling and/or the diffbots
• break the validation suite
  • because the chains have changed
  • because the “standards” have changed (what we validate against)
• cause the data backend (and therefore the Go bindings and any downstream dependencies) to have outdated information