Since we aren’t able to get the marketcap of tokens using BitQuery what’s the best way of comparing two tokens? I can get the value ok a single token but that isn’t helpful since $1 might buy 1 token but more sometimes it’ll buy 1 million tokens. I want to be able to relatively compare two tokens and see which one is performing better. Thanks.
Hello! Although the marketcap is not available directly from Bitquery, it can be deducted. Regarding the other thing, can you explain more in detail what you want to achieve?
Thanks for the reply. The same thing really. I would like to plot a chart with useful information on it but right now it’s hard to show the information relatively. A token with a marketcap of $1,000,000 going up 50% is very different to a token with a marketcap of $50 going up 50%.
How could I deduct the marketcap without knowing the circulating supply?
To obtain the marketcap of a token, you need the circulating supply
To obtain this data with Bitquery you can do the following:
- Obtain the minted tokens
- Get the tokens that have been burned
Note that the total mined tokens have to be subtracted by the burned tokens, usually projects use these directions for that:
Here’s a query that will let you know exactly that:
Here in this query you query for the balance of
0x0000000000000000000000000000000000000000 but you can add the addresses I mentioned by changing the
is to an
Brilliant, thanks. I knew how to calculate the marketcap but I think I misunderstood what’s meant by circulating supply. I always thought it meant the number of tokens that had actually been sold. This makes sense though, thanks.
Thanks again but I have one more question. I’ve been messing around with this query and noticed it uses about 500 points. I’m pulling data on quite a few tokens and this’ll get through my free allocation quite quickly. My query currently only uses about 1 point per call, any reason why this one is so expensive?
when a query takes many points it is usually because it occupies a large performance in the servers.
anyway, some ways to avoid spending a lot of points and optimize our queries could be:
- see which fields we are not using and do not get them
- see if you can get the data in an optimal way
referring to the query above, maybe there are some fields that are not needed, for example:
it all depends on the data you need.
I’m a little thrown by the part of your query which fetches the balance on those addresses that show minted and burned tokens. It looks like rather than querying the balance at a particular point in time, they look for transfers to those addresses over a window of time. If I want to get the minted tokens do I have to just guess when that would have happened and use a time window large enough?
Right now I have a query that works out when a token was launched and then uses a window between the launch date and the current time. If I were to add this function to my existing query would I have to set it to start something like three days before the launch date?
In the query, transactions does not have the dates defined, they are in null:
since: null, till: null
so you get that data without specifying the date