Hey everyone!
There haven’t been any news lately simply because the exchange rate canister is running smoothly. Since the canister went live, we’ve been working on several improvements that we’d like to roll out in a canister upgrade.
The upgrade would include the following:
The pricing has been updated in accordance with the new price function of HTTPS outcalls. In short, the number of cycles that need to be attached and the number of cycles charged have been reduced by a factor of 10!
The exchange rate canister now supports variable decimals. That is, the decimals field in the returned exchange rate metadata may deviate from the default value 9 to represent very small or large exchange rates.
Since all rates are represented as integers, the standard deviation in the metadata is now computed using an integer square-root function to minimize the use of floating-point operations.
The exchange rate canister now supports the upcoming dfx deps feature, which will make it possible to easily install canisters locally.
Several new end-to-end tests have been added to test the canister’s behavior in various scenarios.
We’d like to propose to upgrade the exchange rate canister to the latest version on the main branch (the source code is here), which contains all these changes.
If you have any questions or concerns, please let us know!
The current plan is to create an NNS proposal on Friday, June 21.
is there a minimum decimals that we can rely on? If in one of my applications, I want to just use a set amount of decimals. Will there always be 8 or something?
Would you want a particular set amount of decimals in the request?
Generally, you can depend on 9 decimal places unless the assets chosen have a fairly significant price difference. I would suggest though scaling the result in a similar fashion as the cycles minting canister: lib.rs - dfinity/ic - Sourcegraph
Most rates will have 9 decimals, but we cannot guarantee that value will not shift over time. An asset could experience a significant rise or lowering in price in comparison to the other asset. It would be best to have code in place that would adjust the value to what you expect.
As @0x5279616e said, there is no guarantee that there will always be a certain number of decimals for a specific currency pair because a shift may be required if the conversion rate becomes much larger or smaller. However, the number of decimals will always be in the range [0, 18].
Hey everyone!
Some community members reported issues when trying to get rates from the exchange rate canister.
The reason for the (many) RateLimited errors was that the Binance API failed to respond to requests, causing the rate retrieval process to stall for 30 seconds for each request. As a result, handling requests took so long that most requests were rejected because the number of requests that can be handled concurrently is limited.
This issue has gone away on its own; however, since calls to Binance often fail (calls from replicas in the US are always rejected), we’d like to replace Binance with Bybit, a smaller exchange, which, based on our initial testing, provides rates reliably.
Moreover, since the Monetary Authority of Singapore no longer provides a free API, we’d like to remove it from the forex data sources. There are ten forex data sources even without this source, so there is no immediate need to replace it. We will look into a suitable replacement at a later stage.
Our plan is to create a proposal to upgrade the canister to the latest version of the source code in the exchange rate canister repository on Friday, December 1, 2023.
If you have any questions or concerns, please let me know!
Could it be configured to automatically cancel calls to APIs that don’t respond within approximately 2 seconds? If the number of responding APIs is sufficient, XRC would then only consider these for determining the outcome.
We identified an issue with the acquisition of forex rates: There were many failures to reach consensus recently because the rates were not sorted in the transform function.
Fortunately, there is an easy fix.
Just to make sure that the exchange rate canister continues to gather enough forex data in the upcoming days, we decided to speed up the process and push out the upgrade proposal - including the changes presented in my previous post - already now.
You can view the proposal here. Please cast your vote!
Our previous proposal this week was successful in resolving an issue the XRC was experiencing while retrieving forex sources.
Unfortunately, it did not solve the RateLimited errors from occurring as ByBit is experiencing a significant amount of timeouts similar to Binance. To remedy this, we have proposed 126300 which will swap out ByBit for Crypto.com. This allows the XRC to maintain the goal of utilizing 7 crypto exchange sources while providing a more reliable source. Please cast your vote!
Earlier in the week, the XRC team identified an issue with the Gate.io exchange. Gate.io’s API was updated with a new field causing the XRC to be unable to extract a rate from the source. To fix this, we have proposed 127097. Please cast your vote!
The XRC team identified an issue with the MEXC exchange. MEXC is returning additional headers in the response that need to be accounted for in the max response bytes. To address this, we have proposed Proposal: 127671 - ICP Dashboard. Please cast your vote!
The XRC team has proposed a new version: Proposal: 129034 - ICP Dashboard. We have added two new crypto exchanges (Bitget and Digifinex) and a new forex source (Central Bank Of Turkey).
The XRC team has proposed a new version: https://dashboard.internetcomputer.org/proposal/131366. We have added a piece of functionality to exclude calls to exchanges if they have failed previously. This should help resolve an issue we have noticed if exchanges timeout causing subsequent calls to become rate limited.
