SOR - Normalized liquidity & tilted pools

[johngrantuk]

Hey friends. Found an issue in the SOR algo. The problem is how normalized liquidity is calculated for tokenPairs and that tilted pools can (like gyroE can tilt) mess up the calcs. So if you have a CSP with asset A and asset B with a lot of liquidity and a tilted gyroE pool with asset A and asset B with less liquidity it wont ever consider the CSP pool and not be able to route big trades.
I think the core of the issue is that the ABA method fails to deliver proper results if the pool is tilted and has almost 0.1% of asset A and 99.9% of asset B
I will add a workaround that it will at least continue to consider a second path (the CSP path in the above example) but that only works if there is only one tilted gyro pool for the same pair (which I hope fixes most cases for now).

[brunoguerios]

This is a problem intrinsic to ABA method. In oder to fix this we'll need a new approach.

One idea is to replace ABA with the existing spotPrice calculation (done in the backend), which can be used to calculate priceImpact and NL.

But this feels like a bigger task that should be done after v3 is launched and higher priority tasks are out of the way.

Ps: the current workaround seems to be working as expected, so I believe this is not such a high priority.

[johngrantuk]

This is a problem intrinsic to ABA method. In oder to fix this we'll need a new approach.

One idea is to replace ABA with the existing spotPrice calculation (done in the backend), which can be used to calculate priceImpact and NL.

But this feels like a bigger task that should be done after v3 is launched and higher priority tasks are out of the way.

Ps: the current workaround seems to be working as expected, so I believe this is not such a high priority.

At the onsite Jarek mentioned the possible option of using the API USD total liquidity amount. Not sure if this is valid but worth checking in with him when this task is picked up.