Currently, the exchange rate proposals are titled like so:
This is confusing, since the number represented in the proposal is actually XDR/ICP, and not ICP/XDR, as shown by the payload of the proposal.
I suggest that verbiage for this be changed so that the proposals either read:
- The ICP/XDR conversion rate is now 0.3417
- The XDR/ICP conversion rate is now 2.9269
I agree that it’s somewhat confusing but it’s actually correct:
ICP/XDR = x, where
ICP is the base asset and
XDR is the quote asset, means that you get
x XDR for
1 ICP (see, for example, here).
So, we are using the standard currency pair notation. In the payload itself where the rate is scaled by a factor of 10,000, we use a more explicit field name to make sure that it’s clear what the number means.
I hope this explanation helps!
Has the canister id changed?
I don’t see the interface (ICSCAN) and when attempting to call, I get this error:
error: Found argument ‘get_exchange_rate’ which wasn’t expected, or isn’t valid in this context
No, the canister ID is still the same as you can see here.
I’m not sure why you got this error, though. The endpoint is indeed called
There is some demo code here if it helps.
Thank you @THLO. I’ll try it out.
The source code of the exchange rate canister is now publicly available.
Moreover, the proposal to give a principal controlled by the exchange rate canister team the right to install the exchange rate canister on the uzr34 system subnet has been accepted. After getting a few more code changes in, we will deploy the exchange rate canister on this subnet.
Note that we will remain in control of this canister in the upcoming weeks (the controller will be
ichnh-6yomf-ktta2-mcswl-h2yep-5w45d-n3i4d-wlfxr-qpsag-2sbbe-tqe) just to make sure that we could step in quickly if we observed any severe issues.
Of course, control will be handed over to the NNS before upgrading the cycles minting canister to make use of the exchange rate canister.
Hi everyone. This will be my last update in 2022:
We now have an empty canister on the uzr34 system subnet.
Since we already have a fully functional beta version running on the w4rem subnet, we decided against deploying the main exchange rate canister on the uzr34 subnet so close to the Christmas break.
The current plan is to roll it out in early January 2023 instead. I hope this decision makes sense to everybody!
Note that there is an open proposal already to remove the authorization for the development team’s principal to install canisters on the uzr34 system subnet.
Hey, just wondering what the state of the exchange rate canister is. Is it live yet? If not, can the beta be queried by canisters currently?
Good news, everyone!
The exchange rate canister is now installed on the uzr34 system subnet!
The canister ID is
However, the exchange rate canister cannot serve requests until the HTTPS outcalls feature is activated on this subnet. Please vote in favor of this proposal that enables HTTPS outcalls on its subnet!
Until then, you can use the beta version for testing, which is fully functional (that is, it responds to requests from other canisters).
Even more good news: There is now a dedicated wiki page about the exchange rate canister.
The HTTPS outcalls feature is now enabled and the exchange rate canister is up and running!
Feel free to try it out!
If there are no objections, the beta version will be uninstalled soon.
How is the local testing situation for these types of system canisters? Do we have the
dfx pull command yet?
dfx pull is not ready yet. Maybe @lwshang can explain how far along he is with implementing it.
At the moment, the simplest solution for local testing is to just deploy an up-to-date Wasm module locally (see here for an example).
Is this the candid? exchange-rate-canister/xrc.did at main · dfinity/exchange-rate-canister · GitHub ?
“class” is a reserved word in motoko so it is currently impossible to construct an Asset.
@claudio is there a work around for this?
The motoko converter for did files at https://k7gat-daaaa-aaaae-qaahq-cai.raw.ic0.app/docs/ puts a _ at the end of class, so hopefully that does it. :)…still…odd.
Yes, that workaround works, IIRC. @chenyan can confirm.
motoko/IDL-Motoko.md at master · dfinity/motoko · GitHub describes the escaping of Candid identifiers that clash with Motoko reserved words.
Yes, it’s a naming convention for converting between Motoko and Candid: append
_ in the identifier if the identifier is a reserved keyword. See the
escape function in the spec: motoko/IDL-Motoko.md at master · dfinity/motoko · GitHub