Discussion: Chainverse data model and integration of community features

This post will host our discussion around the Chainverse core data model to support the Community Manager UI MVP as well as our ad-hoc analytics needs.

Background info

“Chainverse” refers to the underlying data platform that supports Diamond DAO data products. Relevant DAO data is sourced from on-chain (e.g. The Graph subgraphs) and off-chain sources (e.g. manual research, Snapshot API), processed to fit a useful data structure, and stored in a place that we can query from. One of the most powerful features of what we’re building is not only the ability to view current state, but we’ll be able to tell the story of a DAO through the entire history of transactions over time.

Core data source
For our MVP we are focused on DAOhaus DAOs only (mainnet and xdai). The DAO metadata (DAO, members, proposals, votes, etc) is coming exclusively from The Graph DAOhaus mainnet subgraph and The Graph DAOhaus xdai subgraph. This work is being done in partnership with Raid Guild and being overseen primarily by me, with input/acceptance (so far) by @ro4438.

Additional data sources
Diamond DAO has had several contributors submit proposals to create new data features: mainly the governance profile by @ricepapi and the Discord data bot by @karmacustodian. This work supports features requests we’ve heard consistently: community managers want to know more about who is behind the wallet address, and Discord provides so much off-chain insight into the community interactions.

Current state

All three data projects above are in flight. The DAOhaus data pipeline is progressing, and I’ve started constructing a data model of final results.

Working repo for data model development: here
Example final output of DAO data: here
First pass at a partial data model

Now what we need to focus on is a standard data model that information from various sources can be mapped to and utilized for our core product and analytics offerings.

Where we’re going

In our Discord dev channel @amphiboly.eth raised an important question:

One thought, to guide feedback. Should we think of this schema as a schema for reporting on DAOs and associated wallets regardless of framework? I.e., would we extend this to include Snapshot/Colony etc? Or is this specifically for reporting on DAOhaus.

Link to message here

The answer is yes, this model should serve to include data from various sources, not exclusive to Daohaus.

Since making this original sketch, I’ve updated to include two types of entity: static and dynamic. Some elements of an entity never change: the date a DAO was summoned, the address of the DAO, the address of the original summoner, etc. Some, however, generate history over time: number of outstanding shares, number of members, treasury balance, etc.

For this reason I’ve started to sketch out an iteration of the first pass:

There are entities (static and dynamic) still to be added: proposal, votes, and others I haven’t thought of yet.

Path to integration

I imagine each data app built by the Diamond DAO community will have to include a mapping function into a core entity. For example:

A similar relationship would have to be defined for the output of every data app we build.

Questions for developers

  1. How would you define the “entities” of the resulting data your application produces? Would it be a static or dynamic entity?
  2. What would the “mapping function” look like to format the output of your data application into a row-level structure?
  3. Any major red flags or huge problems with the above approach to a general Chainverse data model?

I feel that given the recent discussion on going with an SQL style database in the background, this becomes very very relevant. Relational databases have the “issue” of needing to think the columnar structures in advance, making the multiple styles of DAO highly relevant to working out what will go into them?