You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As was noticed by a few validators, only one crypto provider is reporting back CoinGecko.
I thought maybe with the new endpoint that was shared it would be able to work with Binance. However, I tested it, and here is what I found. The alternative endpoint(s) do work, but it looks like it may only translate the price if it has a direct pair to USD. Binance does not have a LUNCUSD pair. The way the older oracle handled this was with this LunaProvider class here . When TFL repurposed the oracle repository for their purposes, they removed it. It appears the way it worked was to use the pairs provided in the default.js lunaProvider json object to translate if needed using the LunaProvider class (so something like LUNA v1 > USDC > USD)(where there was not a USD pair directly available to be defined).
I think the removal of the LunaProvider class is what may have caused an issue for the other crypto providers such as Kraken (which does have a direct LUNA/USD pair [LUNA v2 is called LUNA2/USD in their exchange]). By reworking it to add the LunaProvider class back in, it may save some time and work?
But, however the L1 team chooses to best handle this, right now CoinGecko is the only crypto provider actually working for the USD translation, and I am wondering if we can get that fixed since it is a single point of failure.
Here is the test I used to test this:
commented all crypto providers except the one I was testing in the default.js file
if the results gave back both crypto and fiat pricing, it appears it is working (would need further inspection to be sure)
if the results only gave back fiat pricing the crypto provider was not working
repeat test for next crypto provider
Thank you so much for looking into this (and thank you also for the work you have done to strengthen the fiat side with the extra SDR/XDR source, and making sure the other fiat SDR/XDR sources work).
The text was updated successfully, but these errors were encountered:
OhhBilboBaggins
changed the title
New price-server has only one crypto provider that is working
[BUG] New price-server has only one crypto provider that is working
Dec 20, 2023
OhhBilboBaggins
changed the title
[BUG] New price-server has only one crypto provider that is working
New price-server has only one crypto provider that is working
Dec 27, 2023
Porting this bug over from classic-terra#24 courtesy of @aeuser999
As was noticed by a few validators, only one crypto provider is reporting back CoinGecko.
I thought maybe with the new endpoint that was shared it would be able to work with Binance. However, I tested it, and here is what I found. The alternative endpoint(s) do work, but it looks like it may only translate the price if it has a direct pair to USD. Binance does not have a LUNCUSD pair. The way the older oracle handled this was with this LunaProvider class here . When TFL repurposed the oracle repository for their purposes, they removed it. It appears the way it worked was to use the pairs provided in the default.js lunaProvider json object to translate if needed using the LunaProvider class (so something like LUNA v1 > USDC > USD)(where there was not a USD pair directly available to be defined).
I think the removal of the LunaProvider class is what may have caused an issue for the other crypto providers such as Kraken (which does have a direct LUNA/USD pair [LUNA v2 is called LUNA2/USD in their exchange]). By reworking it to add the LunaProvider class back in, it may save some time and work?
But, however the L1 team chooses to best handle this, right now CoinGecko is the only crypto provider actually working for the USD translation, and I am wondering if we can get that fixed since it is a single point of failure.
Here is the test I used to test this:
Thank you so much for looking into this (and thank you also for the work you have done to strengthen the fiat side with the extra SDR/XDR source, and making sure the other fiat SDR/XDR sources work).
The text was updated successfully, but these errors were encountered: