Deadline check is not effective, allowing outdated slippage and allow pending transaction to be unexpected executed
Deadline check is not effective, allowing outdated slippage and allow pending transaction to be unexpected executed\\nIn the current implementation in CurveSpell.sol\\n```\\n{\\n // 2. Swap rewards tokens to debt token\\n uint256 rewards = _doCutRewardsFee(CRV);\\n _ensureApprove(CRV, address(swapRouter), rewards);\\n swapRouter.swapExactTokensForTokens(\\n  rewards,\\n  0,\\n  swapPath,\\n  address(this),\\n  type(uint256).max\\n );\\n}\\n```\\n\\nthe deadline check is set to type(uint256).max, which means the deadline check is disabled!\\nIn IChiSpell. the swap is directedly call on the pool instead of the router\\n```\\nSWAP_POOL.swap(\\n address(this),\\n // if withdraw token is Token0, then swap token1 -> token0 (false)\\n !isTokenA,\\n amountToSwap.toInt256(),\\n isTokenA\\n  ? param.sqrtRatioLimit + deltaSqrt\\n  : param.sqrtRatioLimit - deltaSqrt, // slippaged price cap\\n abi.encode(address(this))\\n);\\n```\\n\\nand it has no deadline check for the transaction when swapping
We recommend the protocol use block.timstamp for swapping deadline for Uniswap V2 and swap with Unsiwap Router V3 instead of the pool directly!
AMMs provide their users with an option to limit the execution of their pending actions, such as swaps or adding and removing liquidity. The most common solution is to include a deadline timestamp as a parameter (for example see Uniswap V2 and Uniswap V3). If such an option is not present, users can unknowingly perform bad trades:\\nAlice wants to swap 100 tokens for 1 ETH and later sell the 1 ETH for 1000 DAI.\\nThe transaction is submitted to the mempool, however, Alice chose a transaction fee that is too low for miners to be interested in including her transaction in a block. The transaction stays pending in the mempool for extended periods, which could be hours, days, weeks, or even longer.\\nWhen the average gas fee dropped far enough for Alice's transaction to become interesting again for miners to include it, her swap will be executed. In the meantime, the price of ETH could have drastically changed. She will still get 1 ETH but the DAI value of that output might be significantly lower.\\nShe has unknowingly performed a bad trade due to the pending transaction she forgot about.\\nAn even worse way this issue can be maliciously exploited is through MEV:\\nThe swap transaction is still pending in the mempool. Average fees are still too high for miners to be interested in it.\\nThe price of tokens has gone up significantly since the transaction was signed, meaning Alice would receive a lot more ETH when the swap is executed. But that also means that her maximum slippage value (sqrtPriceLimitX96 and minOut in terms of the Spell contracts) is outdated and would allow for significant slippage.\\nA MEV bot detects the pending transaction. Since the outdated maximum slippage value now allows for high slippage, the bot sandwiches Alice, resulting in significant profit for the bot and significant loss for Alice.
```\\n{\\n // 2. Swap rewards tokens to debt token\\n uint256 rewards = _doCutRewardsFee(CRV);\\n _ensureApprove(CRV, address(swapRouter), rewards);\\n swapRouter.swapExactTokensForTokens(\\n  rewards,\\n  0,\\n  swapPath,\\n  address(this),\\n  type(uint256).max\\n );\\n}\\n```\\n