Price API Problem in case of low liquidity

Having trouble with the pricing API: Trying to price the token xBtrfly as of Jan-09-2022. According to the Moralis API, the price is $117,730. The actual price (according to Coingecko and other sources) is around $3,100. Here’s the Moralis API call:

and here’s the CoinGecko chart:

This address is for ** xBTRFLY (xBTRFLY)**, whereas 0xc0d4ceb216b3ba9c3701b291766fdcba977cec3a is the address for BTRFLY (BTRFLY) which is the one you ought to use

The address is driven by the user of my dapp, not by me.
If I can’t use the address for xBTRFLY, then it should not return a price.

You can use the address, xBTRFLY got it’s value too.
You’re checking for a different address, that’s why you got a different result

But the value for xBTRFLY is way off. It should be about the same as BTRFLY.

Their docs say xBTRFLY is deprecated, so that may be why. Can’t seem to swap for it on exchanges. If it should be 1 to 1 in reality (as in docs, it was given in return for staked BTRFLY), then you can just use BTRFLY.

Thanks, but this is not super relevant, because we are getting a historical price. xBTRFLY was not deprecated as of the block we are requesting.

The issue is that the Moralis API is returning a wildly incorrect price. If there’s no liquidity, it should return the “Not enough liquidity” error, in which case we have code that falls back to proxy tokens (such as BTRFLY in this case). But when Moralis returns a price, we believe it…

I think that sometimes getTokenPrice can return prices like that when the liquidity is low

That is not an acceptable answer.
If we say “sometimes it’s wrong” that is the same as saying “don’t trust this API.”

How do we detect when it’s going to return crazy prices?

you could try to use /{pair_address}/reserves endpoint to get the exact liquidity reserves values, not sure if it will work in your case

Can you please check if it will work in this case, since this is a tech support question and you are providing support for a paid product?

If the liquidity is not sufficient to return an accurate price, I think you’ve set the liquidity threshold too low in the API.

do you know what were to tokens in the liquidity pool at that time?

No - that’s your job :slight_smile: . We just use the price API Moralis provides.

As the price is obviously incorrect, the alternative is to just use BTRFLY address which according to the protocol should have been matching xBTRFLY at the time - this returns $3209 so in the same range as the chart which is what you’re using as a comparison anyway.

If it is user inputted, then you can set a case for it by default where it uses the BTRFLY contract address instead.

We have that case coded. It uses the fallback token (in this case BTRFLY) if the primary token the user inputs (in this case xBTRYFLY) does not return a price from the Moralis price API. However, in this case, it does return a price, and it’s a very wrong price. So this code does not kick in.

The other way to code it would be to try the fallback token first, but that is no good because sometimes the fallback token does not trade in line with the primary. For example, if the user wants a quote for stETH and we fall back to ETH, that doesn’t work when stETH breaks its peg.

If the user asks for an apple, you always try to give them an apple before falling back to a pear.

What we need is a price API that functions as advertised in the docs: If there is not enough liquidity to return an accurate price, we should get an error instead of a crazy price.

Related question: I’m trying the price API with another token (PolyCub), and getting a liquidity pool error…

…even though it has $190k of liquidity on Sushiswap on Polygon right now:

So, sometimes there’s plenty of liquidity and you COULD get a good price but return an error. Other times, it seems like there’s not enough liquidity and instead of returning an error, Moralis returns a crazy price. This is pretty difficult to code around.

Can I make a suggestion? Since the price API already checks the liquidity (to decide whether to return an error or return a price), what don’t you just return the liquidity in the API response, along with the price? Then each of us developers can set their own threshold.

You can add this suggestion on

Thanks. Done.
Would still appreciate an answer to the above.

the problem with that I think is that we only track quickswap on polygon now

  1. I think you are responding to the POLYCUB issue. So what’s the liquidity you are seeing in quickswap?
  2. Please address the xBTRFLY issue as well.