Add Coingecko module to expose useful APIs directly from nodes

[leobragaz]

In order to make it easy to keep all the $DSM info update on coingecko page
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]

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]

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]

@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]

@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]

@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]

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

[leobragaz]

@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]

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.