Happy to announce our 100% on-chain DeFi Aggregator is now working alpha and stable after one month of extensive testing and debugging.
It serves all the information needed for a site like <icpcoins.com> including all charts (Notice: icpcoins is using the old web2.0 version currently). It also allows for a bit more than that. Treasury/time charts; Unlocking/time maps; Marketdepth/time maps; Supply/Time; Real circulating supply (without locked tokens) & Industry standard circulating supply.
Potential usage: Stats sites / Dashboards. DeFi contracts. Wallets - Currently all wallets are not displaying the USD value of your tokens (but have placeholders for it).
This aggregator is the only canister (that we are aware of) that currently has a liquidity-weighted average price collected from DEXes and all the other important information related to tokens.
The canister currently makes 2,815,200 inter-canister calls/ per month to collect everything from hundreds of canisters and you can get what you need with one call, potentially saving your apps tens of thousands of $ in development and IC fees. Additionally, without the DeFi Aggregator for many of the valuable attributes, while you can query the latest data, you cannot retrieve and chart the data from a month ago.
Example visualization coming from a single call get_latest
One way to go is to make it self-sustainable with fees (paid by other projects). If you have a wallet or a dapp that wants to use this data DM us. This way we can figure out what the demand is and calculate the fees these apps will have to pay to keep this running.
There are many other options, including SNS. Please let us know how you think it should be set.
Oracle external ICP/USD ETH/USD BTC/USD, market caps, and volume are pushed from outside. These values stay in their tracks and are not used unless XRC fetching the same stops working for more than 4 hours. They are refreshed every 5 seconds and someone can use them if they want faster updates. XRC prices are updated once per minute.
Sonic volume not included - no on-chain API for it. Sonic also doesn’t seem to record its pool prices and provide API for it, on or off-chain. There is only the current price available.
ICDex reports volume in tokens and not USD, which changes price. Then it becomes hard to tell what is the actual volume. When keeping track of volume by adding the transaction value not in tokens but in a stable currency like USD - it is more accurate. Example: Trades happen all day at a price of 2.3 (for a total of 30k USD) and at the end of the day the price goes to 4.6 (10k USD). If you convert volume 24 with the current token price, you will get a total volume (70k USD) - almost double what it really is. It will also be halved if the price goes down. Our API can record the total volume and use that to fix the issue, but it’s still good to have volume in USD.
ICPSwap We are currently ****using TVL to determine liquidity (depth -50%). The other way of doing it is complicated and may not even be possible without implementing a good portion of their dex algorithm. Some tokens aren’t tagged to count towards TVL, probably to discourage users from trying to cheat the reward system by filling it with custom coins without value. However, XTC and Ghost don’t count towards it too at the time of writing. Making the stat we are providing not very accurate. We have contacted them and asked for a multi_quote function, which could be used to amend that.
Conclusion: We will need to create a standard for fetching information from DEXes that will work for both order book and AMM DEXes and also for both single and multiple tokens inside one canister. This will ensure the stability of systems relying on such information. The functions we currently use are most likely made to serve the developer’s web apps. We will also need another standard for getting locked & unlocking(optional) tokens from non-SNS contracts.
This looks really cool and going forward is something we could probably make use of in our project.
I’m wondering, what potential use cases do you foresee for this, outside of maybe charts and stats?
Is one of the primary advantages of this, its ability to aggregate Internet Computer tokens? Since data for both ICP and Bitcoin is widely accessible via various Web2 APIs, would this mostly be beneficial for projects that aim to display statistics for native ICP coins?
Wallets, DeFi contracts (once it becomes bulletproof).
Yes, the primary advantage is that you have the data on-chain usable by other canisters and that you have coins from IC ledgers.
There is a benefit even for off-chain scripts. You can’t trust a single web2.0 API, so you would have to fetch a lot of them to make sure your data is correct. If you don’t want to write all that and maintain it (inside or outside a browser) - Your prices coming from IC are signed and come from multiple sources, so all you have to do is one call (after verifying contracts work as intended)
BTW. On second thought the circulating supply currently excludes locked tokens circulating = total - total_locked - treasury, but they aren’t really locked (a canister can own SNS neurons and sell them locked). Having that number is valuable, but we should probably use circulating = total - treasury to calculate the market cap, which is how icpcoins works right now.
Thanks for this. I have already started using it in my project, and I have an inquiry. when using the get_pairs function to get the price history for the tokens, the base of most of the sns tokens is ICP but I would want the base to be USD, is there a way I can twist the data to achieve this? I need some guidance.
The pairs are just rates between two tokens.
You can take the rate ICP/USD from one of the pairs and ICP/SNS1 from another. Then you can use these two to get SNS1/USD or SNS1/BTC for every tick.
One of the backend functions does this for the last tick, but not for get_pairs. That will be computationally expensive. I am doing these calculations inside the client/ frontend.
