[tech] Debt and Improvements from ICR epic

[psparacino]

In the course of adding support for ICR projects, there many different areas of improvement that came to light to facilitate adding additional registries (ICR debt), clean up previous debt, and create central sources of truth for both registry and project data.

API

1. Move /retirements data to endpoint:
a. Currently queries to the digitalCarbon subgraph for retirements data take place in the FE. This should all be moved to a retirements endpoint so there are no direct subgraph queries from the app.

Subgraph

1. Project Info on marketplace and digital-carbon subgraphs
   • Both subgraphs need current project info for all projects. This is currently manually updated and can only be updated on redeployments. As some subgraphs (digital-carbon) have a significant sync time of around a day, we can dynamically update the project info using ipfs and ipfs fileDatasources on the subgraph.
   • To go along with the above, a script that assembles the required subgraph project info data from the central sources of cms project data and on-chain project data will facilitate this process.
2. Add tokenId to marketplace subgraph project info type:
   • This will negate the need for a modified url (to add vintage vintage as a query param) if retiring ICR. Not a big issue at all, but this makes for one less area to update when adding registries.
3. Digital Carbon ICR projectID
   • Currently the projectID for ICR projects is the unique ICR ID from the api, which is unusable outside of the ICR api. To reduce complexity in the api and frontend, the digital carbon subgraph can revised for ICR project IDs to be in the registry-registryProjectID format (or maybe even revised in the cms?)
4. Reduce dependency on external subgraphs

• Currently we need to use the ICR subgraph to query for ICR holdings. Ideally all data should be available on a subgraph maintained by CM (probably digital-carbon).
• 5. Polgon-Digital-Carbon: ICR Tokens need to show up as Token

App and/or Api

1. Central source of truth for supported networks
   • Most likely a map in the api constants that NetworkParam uses, as the frontend uses the generated NetworkParam for almost all network references
2. Conditional amount handling
   • All amounts coming from the subgraph are in 18 decimals at the moment, except for ICR which are regular integers (0 decimals). Rather than updating the amounts individually based on project ids or key, we should have a central source of truth for decimals relating either to registry or projects.
3. Remove serialization from all app and api. The serialization is only needed to query ICR's api or subgraph. Ideally only the cms should be querying the endpoint, everything else should be on a CM maintained subgraph so there should be no need for the serialization.