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:
or
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
Thanks
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 get_exchange_rate.
There is some demo code here if it helps.
Good news!
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.
Merry Christmas!
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 uf6dk-hyaaa-aaaaq-qaaaq-cai.
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?
edit:
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 unescape and escape function in the spec: motoko/IDL-Motoko.md at master Ā· dfinity/motoko Ā· GitHub
Hi everyone! Itās time for a quick update.
While the exchange rate canister is up and running, there are two reasons why the cycle minting canister doesnāt make use of it yet:
The recently accepted update enables IPv4 on the usr34 subnet where the exchange rate canister resides.
Moreover, work to change the voting reward mechanism in the governance canister is ongoing (see here for a recent post on this topic) and is scheduled to be rolled out this week.
Once these two roadblocks are out of the way, we will begin our final round of testing. The upgrade of the cycle minting canister, which will make it request the ICP/XDR rate periodically from the exchange rate canister, is currently planned for the last week of March.
After this upgrade, the number of daily proposals will go down significantly. In case you are wondering, rewards will roll over to the next voting reward period on days without any NNS proposals.
So no more need for proxy calls? IPv4 is enabled on subnets directly? Will this be rolled out for all subnets eventually or do I need to install my canister in a special subnet to be able to make IPv4 calls?
HTTPs outcalls via IPv4 is discussed in this thread.
Iām not directly involved in this feature but the plan is to have IPv4 support on all subnets eventually. Until then, only system subnets including the uzr34 subnet have IPv4 support (using the SOCKS proxy approach).
@THLO
is there a list of symbols available? More specifically is this xdr, ācxdrā? Cant seem to get prices in xdr
