New Exchange Rate Mechanism

dfx pull is not ready yet. Maybe @lwshang can explain how far along he is with implementing it.

1 Like

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).

1 Like

@THLO

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.

2 Likes

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

3 Likes

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 number of available data sources (exchanges and forex data providers) is currently too small. HTTPS outcalls to IPv4 hosts are needed to increase the number of data sources to a reasonable level.
  • The removal of conversion rate proposals significantly increases the risk of spam proposals. A change to the voting reward mechanism is required to remove the economic incentive for spam proposals.

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.

11 Likes

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).

2 Likes

@THLO
is there a list of symbols available? More specifically is this xdr, “cxdr”? Cant seem to get prices in xdr

1 Like

No, there is no (hard-coded) list. The exchange rate canister simply collects all the symbols that the forex data providers return.

There is only a small number of providers that support “XDR”, so it is possible that you don’t get any rates for specific timestamps.

Since we need support for XDR, there is a “computed XDR” rate (symbol “CXDR”), which is artificially added. It is derived from the rates and weights defined by the IMF (the weights are shown in the screenshot).

In short, if you need the IMF SDR asset conversion rate, the preferred way is to use the “CXDR” symbol.

2 Likes

Is there any way to receive multiple assets in one go? I feel like having to make 3 separate async calls per 3 different assets could cause some kind of reentrancy attack if thats the right term. Basically, if you need to calculate the amount of you hold in USD for five different assets simultanously, would this current exchange rate canister make that feasible?

or if not now, will there be plans to do this?

Oh yea, is this supposed to be the defacto one source exchange rate shop for the ic, similar to how chainlink is and its bad practice to use any other price feed sources or should this be looked at just as another source that could be faulty and its good to have backups? On localnet, I have quite a bit of random failures but so far none on the mainnet so I am curious?

1 Like

No, there is not. Note that the exchange rate canister needs to make calls to all exchanges for each requested asset individually anyway, so there is no way to reduce the number of HTTPS outcalls in this scenario. Moreover, if you don’t want to make the requests sequentially, you can choose to make multiple calls in parallel and await the completion of all these calls.
However, you should only request a small number of rates at any given time because there is rate limiting in place to make sure there aren’t too many HTTPS outcalls at the same time. If you are requesting too may rates, you’ll get a response containing the ExchangeRateError::RateLimited error.

As mentioned above, adding such an endpoint wouldn’t add a lot of value in my opinion. I agree that it would make things more convenient for developers. I will discuss it with the rest of the exchange rate canister team to see how they feel about it.

It is just one canister that acts as an oracle for cryptocurrency and fiat currency exchange rates. There can definitely be many others, for example, interacting with other/more sources, providing exchange rates for other assets such as stocks and so on.
Everybody is free to develop their own oracle services and use whichever service suits their needs.

Just to be clear, the exchange rate canister is more than “just another source” because it interacts with multiple data sources and consolidates the received rates to provide a rate that is likely to be accurate. Note that the cycle-minting canister will soon receive the ICP/XDR rate from the exchange rate canister.
There is no guarantee that the rate is correct, however, so you may choose to get the rate from other oracles as well (but they may be faulty, too).

4 Likes

Extremely helpful. :pray:

Just in case somebody missed it: The NNS proposal to upgrade the cycle-minting canister (CMC) is open, so please cast your vote!

If the proposal is accepted, the CMC will start using the exchange rate canister to get the ICP/XDR rate after the upgrade.

4 Likes

The CMC has been upgraded!

The dashboard of the exchange rate canister shows that the CMC (rkp4c-7iaaa-aaaaa-aaaca-cai) requests the rate from the exchange rate canister.
You can verify that the conversion rate proposals stopped a few hours ago on the Internet Computer dashboard (by looking at the Exchange Rate topic) and that the CMC updates the rate successfully using the get_icp_xdr_conversion_rate endpoint.

5 Likes

This is extremely awesome

1 Like

What are the privileged canister ids?

rkp4c-7iaaa-aaaaa-aaaca-cai is the Cycles-Minting canister (CMC).

ewh3f-3qaaa-aaaap-aazjq-cai is the Total Value Locked (TVL) canister, used to provide Total ICP Value Locked to the NNS front-end dapp.

1 Like

Thanks, I should have asked “what does it mean to be a privileged canister”, and then knowing which those are would be great.

I’m assuming they just don’t have to pay cycles?