token0Price and token1price from SDK do not match subgraph

[NoUJoe]

I've posted this on the discord, but haven't received any acknowledement as of yet. Upon investigation, I've discovered the cause the problems described. Here's the original post that I posted on discord, and I'll add more afterward.
Original post:

I'm having trouble trying to understand some properties from the v3 subgraph.
pool.token0Price and pool.token1Price

Let me provide an example, just with necessary info, this is from the BSC graph

"token0": {
"decimals": "18"
},
"token1": {
"decimals": "18"
},
"token0Price": "0.00000000000000000000000000000000000000293895680758558494927616942086432",
"token1Price": "340256786836388081269117234195560700000",
"sqrtPrice": "1461446703485210103287273052203988822378723970341",
"tick": "887271"
}

So this is the info returned from the subgraph. Now using the javascript SDK, I created the necessary objects (two tokens, and a pool).

There are some differences in the data produced in the SDK, and that from the subgraph. Some I understand, but others not.

The SDK produces:
pool.token0Price = 340256786836388094070642339899681172762
pool.token1Price = 0.0000000000000000000000000000000000000029389568075855848387034172747685

• pool.token0Price and pool.token1Price are swapped. token0Price in the SDK is token1Price from the graph, and vice versa.
• The prices from the graph are to 34 significant digits. This is why there are trailing zeros for token1Price on the graph. This is necessary for numbers < 1 to limit the number of decimal places. I understand why this is the case
• The prices, even when to the same significant digits, don't match.
  pool.token0Price.toSignificant (34) = 340256786836388094070642339899681200000
  Subgraph counterpart (token1Price) = 340256786836388081269117234195560700000

end of original post

So I'll keep this issue to the SDK problem, which is the swapping of prices. Based on the documentation for token0Price, "Returns the current mid price of the pool in terms of token0", I believe the issue is with the SDK and not the graph for this. The prices are the right way around in the subgraph, and the wrong way around in the SDK.

The remaining problems regard the subgraph, so I will open an issue there and reference this one.

[Florian-S-A-W]

I noticed this a while ago and it's indeed confusing. The way the sdk does it is consistent with the documentation though: "Returns the current mid price of the pool in terms of token1, i.e. the ratio of token0 over token1".
The v3 subgraph is not documented as far as I know so it's also not really incorrect. The price is displayed this way on the info page though.

The data from the subgraph is in general not 100% correct, discrepancies can happen in every single datapoint. I opened an issue on the Ticks but the actual issue is (at least I think so) that the graph doesn't handle reorgs correctly so some transactions are not indexed.

I don't believe the subgraph will ever be updated. I suggest making direct onchain calls for sensitive data.