In this post, I propose to add the clrfund subgraph as a package within the monorepo (as opposed to its own repo or within the clrfund-deployer repo).
The main case is that a subgraph – even though it is not necessarily a strict dependency – benefits clrfund as a whole and should therefore be treated as part of the core packages.
Perceived benefits of a subgraph to clrfund
- Creates a canonical data model that…
- Can automatically expand to index new rounds and (with the use of a clrfund factory factory, eg as planned for clrfund-deployer) even new community instances of clrfund
- Anybody can access, which opens up possibilities for all manner of new apps (alternative contribution UIs?) or other use cases (QF data analysis?) to be built permissionlessly by the community
- Allows us to more easily build dashboards tracking clrfund data (contributions, matching funds, etc.) over time and across instances. This will be useful for several reasons:
- for clrfund devs/contributors in evaluating and making decisions related to clrfund’s growth and success, and
- for the clrfund project to promote its success to attract additional funding and devs/contributors
- community members wishing to view aggregated (and detailed!) information about what’s happening in clrfund
- Typically enables faster contract data retrieval by apps
- note that the current clrfund app would likely need to be refactored to take advantage of these benefits; a decision on if/how/when to do that is outside the scope of this post
I’m quite confident that other benefits exist that I have not articulated here. I’m also confident that there are some drawbacks I’m not aware of. Please chime in on this thread with your thoughts on these and a reaction to the below recommendation.
@Daodesigner is currently working on developing a clrfund subgraph. My recommendation is to create a new
subgraph package in the monorepo for this work in progress and ultimately for the completed subgraph code to live.