Wrong calculation of `tickCumulatives` due to hardcoded pool fees
Wrong calculation of `tickCumulatives` due to hardcoded pool fees\\nReal Wagmi is using a hardcoded `500` fee to calculate the `amountOut` to check for slippage and revert if it was to high, or got less funds back than expected.\\n```\\n IUniswapV3Pool(underlyingTrustedPools[500].poolAddress)\\n```\\n\\nThere are several problems with the hardcoding of the `500` as the fee.\\nNot all tokens have `500` fee pools\\nThe swapping takes place in pools that don't have a `500` fee\\nThe `500` pool fee is not the optimal to fetch the `tickCumulatives` due to low volume\\nSpecially as they are deploying in so many secondary chains like Kava, this will be a big problem pretty much in every transaction over there.\\nIf any of those scenarios is given, `tickCumulatives` will be incorrectly calculated and it will set an incorrect slippage return.
Consider allowing the fees as an input and consider not even picking low TVL pools with no transations
Incorrect slippage calculation will increase the risk of `rebalanceAll()` rebalance getting rekt.
```\\n IUniswapV3Pool(underlyingTrustedPools[500].poolAddress)\\n```\\n