The functionality used in computePoolAddress uses the exact same calculation method for the pool address, using the tokens and fee, which would not work on ZK.
Vulnerability Detail
Due to different precompilers and bytecodes on ZK, the returned address from the method would be wrong, resulting in the swaps on Uniswapv3 to revert or force overpay.
This issue has been addressed in the past, but has remained unchanged by the team, contrary to their intentions in the README to deploy to ZK.
Impact
Medium. Unlikely to happen but would result in short-term DOS and more fees paid by the borrower.
ptsanev
medium
Address deviation will not work on ZKSync
Summary
The functionality used in
computePoolAddressuses the exact same calculation method for the pool address, using the tokens and fee, which would not work on ZK.Vulnerability Detail
Due to different precompilers and bytecodes on ZK, the returned address from the method would be wrong, resulting in the swaps on Uniswapv3 to revert or force overpay. This issue has been addressed in the past, but has remained unchanged by the team, contrary to their intentions in the README to deploy to ZK.
Impact
Medium. Unlikely to happen but would result in short-term DOS and more fees paid by the borrower.
Code Snippet
https://github.com/sherlock-audit/2024-02-leverage-contracts/blob/main/wagmi-leverage/contracts/abstract/ApproveSwapAndPay.sol#L251-L271
Tool used
Manual Review
Recommendation
Consider calling the Uniswap factory getter
getPool()to get the address of the pool.Duplicate of #35