Corner case - when pool is drained by MEV transactions

[neptune-v]

Last one guys:

When I was syncing the original Pool I need (WETH/ENS) I ran into the Sqrt error still. This is because in this pool, all the Liquidity was drained by a MEV transaction, and it does not return the same Sqrt as UniswapV3Pool.sol in this instance, however when liquidity is restored the value corrects.

Hence I suggest adding the following to your scripts to protect against this scenario, not sure what pools you are investigating but low liquidity pools will definitely run into this issue.

      let dryRunRes =
        JSBI.equal(amount0, param.amount0) &&
        JSBI.equal(amount1, param.amount1) &&
        JSBI.equal(liquidity, param.liquidity) && 
        (JSBI.equal(liquidity, JSBI.BigInt("0")) || JSBI.equal(sqrtPriceX96, param.sqrtPriceX96));

Note that you will need to add liquidity to the return tuple of querySwap & swap. I've not done this as I'm not using the TS code, but this bug will be present in your repo, especially on the WETH/ENS pool with this data set:

        { block: 13578816, type: "mint", tickLower: 49800, tickUpper: 64020, amount: JSBI.BigInt("556973545490136947176"), owner: "0xC36442b4a4522E871399CD717aBDD847Ab11FE88" },
        { block: 13578904, type: "burn", tickLower: 49800, tickUpper: 64020, amount: JSBI.BigInt("529124868215630099817"), owner: "0xC36442b4a4522E871399CD717aBDD847Ab11FE88" },
        { block: 13578904, type: "burn", tickLower: 49800, tickUpper: 64020, amount: JSBI.BigInt("0"), owner: "0xC36442b4a4522E871399CD717aBDD847Ab11FE88" },
        { block: 13578932, type: "swap", amount0: JSBI.BigInt("-927248711787417535"), amount1: JSBI.BigInt("226019397190954581334"), sqrtPriceX96: JSBI.BigInt("1596559182082899146010277864392"), liquidity: JSBI.BigInt("27848677274506847359"), tick: 60068 },
        { block: 13578934, type: "swap", amount0: JSBI.BigInt("920000000000000000"), amount1: JSBI.BigInt("-223879353725590078001"), sqrtPriceX96: JSBI.BigInt("959633067218665487871404249200"), liquidity: JSBI.BigInt("27848677274506847359"), tick: 49886 },
        { block: 13578935, type: "swap", amount0: JSBI.BigInt("-959865922027525865"), amount1: JSBI.BigInt("242467151826027761469"), sqrtPriceX96: JSBI.BigInt("1647371161194432686455871832571"), liquidity: JSBI.BigInt("27848677274506847359"), tick: 60695 },
        { block: 13578936, type: "swap", amount0: JSBI.BigInt("450000000000000000"), amount1: JSBI.BigInt("-145297332972233388668"), sqrtPriceX96: JSBI.BigInt("1234007158439758347475901738156"), liquidity: JSBI.BigInt("27848677274506847359"), tick: 54916 },
        { block: 13578936, type: "swap", amount0: JSBI.BigInt("-354496843525935494"), amount1: JSBI.BigInt("107587674962888456320"), sqrtPriceX96: JSBI.BigInt("1539170731967240812097888883834"), liquidity: JSBI.BigInt("27848677274506847359"), tick: 59336 },
        { block: 13578936, type: "swap", amount0: JSBI.BigInt("99075117070465334"), amount1: JSBI.BigInt("-34876614258170369519"), sqrtPriceX96: JSBI.BigInt("1439948422944933305299128962054"), liquidity: JSBI.BigInt("27848677274506847359"), tick: 58003 },
        { block: 13578941, type: "swap", amount0: JSBI.BigInt("-200964582387892645"), amount1: JSBI.BigInt("76633097773913642784"), sqrtPriceX96: JSBI.BigInt("1657311889301420165775927484336"), liquidity: JSBI.BigInt("27848677274506847359"), tick: 60815 },
        { block: 13578941, type: "swap", amount0: JSBI.BigInt("100000000000000000"), amount1: JSBI.BigInt("-40586449235886312908"), sqrtPriceX96: JSBI.BigInt("1541845371296224062163342553694"), liquidity: JSBI.BigInt("27848677274506847359"), tick: 59371 },
        { block: 13578941, type: "swap", amount0: JSBI.BigInt("60000000000000000"), amount1: JSBI.BigInt("-21746203898771549812"), sqrtPriceX96: JSBI.BigInt("1479978455335465530025234166091"), liquidity: JSBI.BigInt("27848677274506847359"), tick: 58551 },
        { block: 13578943, type: "swap", amount0: JSBI.BigInt("820850720170027688"), amount1: JSBI.BigInt("-184363245697871389667"), sqrtPriceX96: JSBI.BigInt("4295128740"), liquidity: JSBI.BigInt("0"), tick: -887272 },

Originally posted by @jamescarter-le in #51 (comment)

[kafeikui]

There's some corner case like soon after a pool was deployed, since liquidity at this time was relatively small, swap with large amountSpecified could lead price to the edge of the model and drain the liquidity from the pool. And of course that kind of swap can be suffered from MEV actions.

With the fix #56 Tuner will reproduce the full state of the pool like things happened in the mainnet, however we believe both LP providers and traders should be careful when Tuner says global liquidity equals 0, it's not a good time to make decisions unless you're an expert.

Thanks to @jamescarter-le , without him we can hardly find this case. For more details , see issue #51 .