Liquidity calculation on data set with expensive price makes no sense

[TimDaub]

• See https://market.oceanprotocol.com/asset/did:op:a2B8b3aC4207CFCCbDe4Ac7fa40214fd00A2BA71 data set
• Page says it has 269,457.981 OCEAN and 49.98 LUMSTA-42 staked in pool. Concludes that liquidity is 3,163,722.59 EUR
• I assume that 3,163,722.59 EUR is the result of multiplying 49.98 LUMSTA-42 LUMSTA-42/EUR + 269,457.981 OCEAN OCEAN/EUR.
• At a price of 1 OCEAN/EUR ≈ 0.9, OCEAN supply in EUR for LUMSTA-42 is, however, roughly 242,511 EUR (10x less than calculated liquidity).

If someone wanted to sell 242,511 EUR worth of LUMSTA-42 into the pool in question, that pool would be devoid of OCEANs after the transaction. I'm aware that technically LUMSTA-42 could be viewed as a standalone, liquid token. A quick Google search, however, yields no other markets but Ocean for the token. LUMSTA-42 is not as liquid as is ETH, USDC, DAI where this argument would be void. IMO it is hence incorrect to say that the LUMSTA-42 market has liquidity of 3M€.

Note that for data tokens that have a much smaller value than LUMSTA-42, e.g. QUICRA-0 the issue may not be a problem.

[trentmc]

This is an interesting question to raise @TimDaub ! :)

Some related info:

• In 10-90 OCEAN-DT1 pools, then there's a small amount of OCEAN, which means high sensitivity to datatoken price (# OCEAN needed to buy a DT1). And as OCEAN increases, price goes kinda crazy. It's why we quickly moved from 90-10 to 50-50 to now 70-30 OCEAN-DT1 pools. The example you give is one of the early 10-90 pools 9 (most sensitive).
• The datatoken price is the spot price, basically the slope of the OCEAN:DT1 supply curve. It does not capture the extreme values of price and it is not meant to, of course.
• If I have a 50-50 Balancer pool of LINK-ETH, with $1000 of LINK and $1000 of ETH, then TVL = $2000 and Liquidity = $2000. It's the same thing for a pool of OCEAN-DT1. Datatokens are assets too. There happens to be just one market for the datatoken, but that doesn't negate its price calculation.
• @mihaisc reports that he double-checked the calculations in response to this issue, and they checked out.

Therefore the concern isn't in the setting the cases whether the dataset is expensive. Rather, it's in the setting when DT price (as a function of OCEAN) is sensitive; and in this setting, the concern is that liquidity calcs seem silly (regardless of if the math works out).

Let's explore this.

• I believe this is already solved for all but the earliest pools, which have 90-10 weights
• The publishers of existing 90-10 pools are all basically interested to migrate to 30-70 pools. We're headed towards supporting that well, e.g. MultiRepoIssue#59 which will be in the next couple months.

I'm not sure what else might be done in the near term. @TimDaub do you have suggestions? Or, we let it drop knowing that it's handled for all the new stuff for months now, and even the old pools will get handled over time.

[TimDaub]

Hey Trent, great response. Thanks!

In general, I may not have been aware about the fact that certain pools have different ratios. I guess for now the simplest possible fix would be to make a pool's ratio clear to users.

• I believe this is already solved for all but the earliest pools, which have 90-10 weights

You may be right. So far I haven't encountered another pool with the same problem that LUMSTA-42 has.

The publishers of existing 90-10 pools are all basically interested to migrate to 30-70 pools.

From a pure econ perspective, a 90-10 pool for LUMSTA-42 is of course marketing-wise a nice thing to have. Because for all unaware users, the numbers look relatively big.

@TimDaub do you have suggestions?

For 90-10 pools, I'd adjust the calculations done in the UI to "nerf" 90-10 pools such that there's an incentive to upgrade. In fact, I'll think about it on rugpullindex.com too...

[trentmc]

Hello! Thanks for the thoughts.

... such that there's an incentive to upgrade. In fact, I'll think about it on rugpullindex.com too...

Alas there's no "perfect" way to upgrade right now. MultiRep 59 will help. And Robin got a grant to do something that would help too. So I'm not sure we want to incentive just yet. But let's say it's already done. Then it's worth talking about incentives.

I guess for now the simplest possible fix would be to make a pool's ratio clear to users.

This is a good point. I guess we don't make that clear enough. @kremalicious wdyt?

For 90-10 pools, I'd adjust the calculations done in the UI to "nerf" 90-10 pools such ...

Do you have a suggestion of how to adjust the calculations? One idea is to simply cap it. Another one is "let it be", in a few months the 90-10 pools will likely have emptied out anyway.

[trentmc]

Closing, as

• this issue is already solved using 30/70 pools, within two weeks of Ocean Market launch
• legacy pools will migrate eventually, in the meantime the calculations are correct, they just look fishy
• there are bigger fish to fry:)

[TimDaub]

I haven't had time to write anything down yet. Anyways, my thoughts are that "slippage" is a good proxy for a pool's liquidity quality. Its usefulness can be seen in most exchanges, e.g., Uniswap takes care of informing the user about "price impact":

Note the color-coding of the value.

I'll likely add price impact or slippage as quality to https://rugpullindex.com in the future.

[trentmc]

I think that showing slippage is a good idea, but it's outside the context of this issue. Could you perhaps report it as a separate issue / feature request please?

[TimDaub]

Could you perhaps report it as a separate issue / feature request please?

I was lazy and reframed the original post of the issue. Feel free to reopen.

[trentmc]

Here's the problems by doing such a change. This issue's comments are in the context of the original (or slightly modified) title & description. This change is a completely different scope. It kinda wrecks the comments / provenance, and makes it hard for anyone working on the new scope.

Could you undo this please, and write an actual new ticket. Thank you.

[TimDaub]

reverted back to the original version, new issue: #430

[trentmc]

Thank you!

I will update the description of that issue so that it doesn't have to fully rely on this issue, which is of different scope.

[TimDaub]

* legacy pools will migrate eventually, in the meantime the calculations are correct, they just look fishy

It's now almost July and LUMSTA-42 has signaled no intention to change to another pool.

* there are bigger fish to fry:)

That's mostly subjective but in any case, I think that a user taking the time to open an issue deliberately should likely be prioritized in this project over anything else. From what I understand, nothing has been done about the issue and the points raised. Reading through it again, I think also some points in the issue have been labeled as "non-issues". They're not. My perspective is that no progress has been made since March. That's disappointing.

[trentmc]

Mar 9 comment:

the calculations are correct, they just look fishy

There was no disagreement on that comment since that time. Has something changed?