why 6 possible inputs from swap event?

[anhdungle93]

In the function resolveInputFromSwapResultEvent the solutionlist can have up to 6 potential solutions, but from my intuition most of the time solution 3 or 4 should be the answer. I would like to better understand the corner cases. Can you elaborate in which scenario (even better if you can give an example event) can one get other solutions? Thanks in advance.

[kafeikui]

Hi @anhdungle93, thanks for your in-depth reading!

We did some work to rebuild pool state from chain events. As mainnet events of swaps only represent the results of the swap, we had to use a try-and-error logic to test out the actual inputs(maybe not exactly the same input, but exactly the same effect on amount, liquidity and sqrtPriceLimitX96) of that swap.

In issue #51 , we know the actual amount result can be off by 1 LSB if we don't pass the matching SqrtPriceLimitX96 to ComputeSwap. So solution 1,2 and solution 3,4, set SqrtPriceLimitX96 or not matters. Well at that time solution 1,2 look like solution 5,6 today. #53

In issue #54 , we know a MEV attack can lead pool liquidity to 0 and make the state of the pool to the edge it can afford. So solution 1 and solution 2 for now, set the input to the point just exceeds the limit as the swap result records. #56

Afterwards we use subgraph as datasource, it seems that we can't get liquidity after a swap directly, so solution 5 and solution 6, to cover some unexpected conditions.

And There are some ifs to cut off unnecessary solutions. Right, if you look into the swap event data, the two neighbouring sqrtPriceLimitX96 can be the same. Something like that.

If you are still interested, I'll recommend reading and debugging this loop with some different inputs. The answer is out there.

uniswap-v3-simulator/src/core/CorePool.ts

Line 258 in 5b636b5

while (

[anhdungle93]

Thank you very much. Will study these issues.