search

desmos-labs / desmos

Improving the well-being of users on social networks through the blockchain technology.
https://desmos.network
Apache License 2.0
105 stars 48 forks source link

Add Coingecko module to expose useful APIs directly from nodes #773

Closed leobragaz closed 2 years ago

leobragaz commented 2 years ago
In order to make it easy to keep all the $DSM info update on [coingecko page](https://www.coingecko.com/en/coins/desmos) it would be useful to have a `x/coingecko` modules exposing useful APIs (GRPC and REST) that can be extended in time and provided by all the full-nodes. The module will use Cosmos-SDK modules (`x/auth`, `x/bank`, `x/distribution`) in order to retrieve supply and vesting accounts informations to properly calculate the most updated circulating supply at any time. The `circulating-supply` API will be exposed by the module through both GRPC and REST endpoints as follow: ``` /desmos/coingecko/v1/circulating-supply/{denom} ``` With it, it will be possible to query circulating supply of any kind of assets available in the chain. The above proposed implementation can already be tested by compiling and executing a chain from the following branch: https://github.com/desmos-labs/desmos/tree/leonardo/coingecko-APIs
dadamu commented 2 years ago

It is the oracle move. From my side, it should be implemented with other oracle provider like Chainlink or Band Protocol to solve the oracle problem if it would be integrated with smart contract in the future. Building oracle on desmos directly is not a desmos goal as I know. In addition, the feature seems for convenience, could/should be done with bdjuno. Personally, I trend to reject this feature. What do you think? @RiccardoM

kwunyeung commented 2 years ago

I tend to agree with @dadamu and I think this should be done with BDJuno. We already have the vesting account data indexed in the database. It seems easier and straightforward to do with BDJuno.

RiccardoM commented 2 years ago

@dadamu Honestly I don't understand what would be the problem here. We are not talking about getting the price of the tokens but only some on-chain data (es. total supply, circulating supply) which are already present on-chain

@kwunyeung I don't see what's the problem in implementing this endpoint directly inside the node. We already have all the data there without relying on an external (potentially unstable) thing such as BDJuno. It would only require us to implement a couple of endpoints that can be accessed by all data aggregators (CoinMarketCap, CoinGecko, etc) and relies on other modules (bank, auth, etc). Also, once done we could simply upstream this to the Cosmos SDK for easier of usage

dadamu commented 2 years ago

@bragaz @RiccardoM Ah my bad, I thought it will gather coingecko price to provide price related data for the user. It is the useful api to let coingecko to query it. Then this feature is fine with me.

leobragaz commented 2 years ago

@dadamu Maybe I wrote it a little bit bad. To clarify, it will be a module that exposes useful queries that coingecko (and coinmarketcap) will use to update info such as the circulating supply and the total supply.

dadamu commented 2 years ago

@bragaz Maybe we can call this module x/supply or something else.

leobragaz commented 2 years ago

@dadamu I was thinking the same. x/supply was also the name of an old module of the SDK that has later been merged into bank 😆. Btw I think the name explains the purpose of it pretty well so why not. @RiccardoM @kwunyeung comments?

kwunyeung commented 2 years ago

Ah I see. I thought it would be something state breaking. If it's only a few endpoints then we can just update our nodes and serve the new APIs.