search

tellor-io / dataSpecs

Data specifications for oracle queries
16 stars 9 forks source link

feat: Add MimicryCollectionMetric data spec #84

Closed dgca closed 1 year ago

dgca commented 1 year ago

Hey folks, I added this data type that my team will be using to power [Mimicry]. Open to changes and suggestions.

A couple considerations I made while creating this data type, and why I made the choice I ended up with:

1. Keeping the type name more abstract (e.g. NFTCollectionMetric) vs namespacing to Mimicry...

I started by calling this data type NFTCollectionMetric. The reason I decided to namespace this to Mimicry, is because there are some subjective criteria for how metrics are calculated.

E.g. by using Reservoir to collect sales data to calculate TAMI, we're explicitly collecting data from specific marketplaces. This seemed to me like a subjective decision, and one that could be confusing if we kept the name truly generic.

While the name is namespaced, we do intend for these data feeds to be able to be used by other smart contracts, assuming our methods of calculation are in line with their needs.

2. Creating different data types for each metric

After deciding to namespace the data type's name, it felt natural to keep the different metric types in this single data type. Creating different data types for each metric felt like it would just add noise to the repo.

themandalore commented 1 year ago

Looks good, I like the metric input array. It makes it easy to add things rather than have to redefine. But I would vote for "NFTCollectionData". I think the metric piece handles how you calculate TAMI. I'd just post more specific info on how to calculate that in the repo (so we don't rely on an external repo that might change)

dgca commented 1 year ago

@themandalore The main reason I want to scope this to Mimicry is cause of @oraclown mentioned regarding us owning the data source and definition. IMO, going with something generic implies that these are the authoritative way to determine these metrics, which is not the case at the moment.

If we do want to go straight to something generic like NFTCollectionData, I'd want to put a disclaimer on this data type that makes it clear that, for now, this is pretty centralized, subject to change, and should be considered a beta type until we come up with a more trustless solution (which I would be happy to continue to work on).

Does that make sense/do you y'all have a preference given what I just mentioned?

Also, just pushed up a change that:

themandalore commented 1 year ago

@themandalore The main reason I want to scope this to Mimicry is cause of @oraclown mentioned regarding us owning the data source and definition. IMO, going with something generic implies that these are the authoritative way to determine these metrics, which is not the case at the moment.

If we do want to go straight to something generic like NFTCollectionData, I'd want to put a disclaimer on this data type that makes it clear that, for now, this is pretty centralized, subject to change, and should be considered a beta type until we come up with a more trustless solution (which I would be happy to continue to work on).

Does that make sense/do you y'all have a preference given what I just mentioned?

Also, just pushed up a change that:

  • Adds chainId as part of the query params
  • Renamed the contract to MimicryCollectionStat (though open to renaming if we wanna genericize)
  • Adds full example in Solidity

Works for us. Thanks for the quick work on it and excited to get it implemented. I'll merge it in now and then work on getting it integrated into our reporter