[Idea Discussion] Open-Source OP Chain & OP Stack Forks Metadata Source

[MSilb7]

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"?

[mseidlx]

This is super helpful for us (growthepie.xyz). It is tedious work to figure out the differences between OP chains and the current metadata proposal would already solve this for us. i.e. we want to make sure that we group chains correctly (superchain, op stack, bedrock, etc.) and this shared list will help as a single source of truth. Having important links like RPCs and explorers also make our lives easier. And just having a list of OP related chains is helpful - it's already hard to keep track of all of them.

Might be interesting to add mainnet_launch_date. Defining the mods in greater detail could also be helpful (block size, block time, etc.)

It seems like with the current level of complexity csv is sufficient as input. Might make sense to use yml anyway just to be prepared for more complexity. Output csv or json are both great.

The automation part of detecting new L2 contracts is interesting - we might be able to look closer into that in the coming months.

[lgingerich]

Fields:

• I would recommend coming up with a base set of fields that apply to other stacks and try to give general names (change op_based_version to version or protocol_version). And then you have the is_law_of_chains fields, which just becomes a an OP-specific superset of the base fields.
• Not sure how I feel about the has_mods column. While potentially useful, this may be a subjective measure or what all qualifies as a modification.
• In op-analytics Repo chain_metadata, there is a column named raas_deployer, but in Dune Upload from OP Labs CRM dataset_op_stack_chain_metadata, there is a column named initial_chain_deployer. I would much prefer using initial_chain_deployer as there will never be null fields. Maybe there should also be a current_chain_deployer field in case someone change deployers?
• Dune Upload from OP Labs CRM dataset_op_stack_chain_metadata has several columns named for individual contracts. To generalize this, I would support having a single field named contracts (or similar), then use json/yml to nest the names of the contracts and their addresses. This would retain all the data currently in this dataset but generalizes for use with other chains.

Derive OP Chain data using the chain factory Would this handle partial automation of this, at least for those opted into the Superchain? You likely could determine some of this from onchain bytecode when a new chain gets deployed, but if there's any changes in their deployment, that wouldn't work anymore.

Given that it seems like potentially dynamic metadata is wanted to be included (which I agree with), I'm not sure that any of this needs to be onchain. Unless of course there's already a need for this that I'm not aware of.

For an OP Stack specific registry, unfortunately I think you or someone else at OP Labs will have to be the approver/denier. A more open solution would be great, but would likely lead to the list getting spammed with bad data.

While the ideal outcome is of course that projects always want to add themselves to the list, they may not care or know about the list. Of course make it as known as possible, but then maybe also tie in eligibility of going on the Superchain Eco website to first adding their data to this registry. There's never going to be a perfect solution here.

[Saraeutsza]

.