Opening up discussion for requirements / ideas for creating an open-source registry for any and all OP Chains & OP Stack Forks.

Problem: Crypto data teams have a super hard time keeping track of deployed OP Chains & OP Stack Forks. Some chain deployers attempt to get in touch with OP Labs / OP Foundation, but otherwise this requires sleuthing through Twitter, blog posts, news aggregators, etc. Many people maintain their own lists with varying degrees of comprehensiveness (nobody knows how many production mainnet chains actually exist)

To solve for this, want to create a shared open-source resource for analysts, developers, educators, etc to identify OP Chains & OP Stack Forks with the relevant information about them.

See Key Definitions for Chain Segments

Goals:

• Be the best "source of truth" for identifying metadata for OP Chains & OP Stack Forks
• Store relevant information for analysts (i.e. Name, RPC, Block Explorer, L1 Contracts, Chain Configuration)
• Make it SUPER easy to contribute to (i.e. easy to add new chains, easy to modify data, easy to add bespoke attributes)
• Make it SUPER easy to read from (i.e. if we input in yml, outputs are available in csv, json, sql, etc)
• Provide the necessary metadata for analysts to create chain segments (i.e. RAAS provider, DA Layer, other Config Changes, potential superchain compatibility)
• Be scalable, we don't want to have to re-do this if/when there are thousands of chains

Existing Version(s):

• op-analytics Repo chain_metadata
• Dune Upload from OP Labs CRM dataset_op_stack_chain_metadata
• superchain-registry repo
• superchain.eco

Other Inspiration / Attempts:

• L2Beat
• growthepie
• Kofi's Rollup Economics
• OP Stack Data Dashboard
• ethereum-lists/chains

Open Questions:

• What are the top use cases for this? (Non-Labs teams, please share!)
• What fields do we need to track? What "requirements" should this have? --
• What's the best input format (i.e. csv, yml), output formats to be available (i.e. csv, json, sql cte)?
• What is the right organizational structure? (i.e. one ecosystem/chain deployer can have multiple chains, there may be a gazillion chains) --
• How can we "automate" parts of this? (i.e. identify new L2s via L1 contracts - somehow tie that back to metadata)
• What could/should be onchain? --
• What's the process for accepting/rejecting/verifying changes?
• How do we incentivize chain deployers to "register"?