poolKey is the combination of the poolKey.token0, poolKey.token1, poolKey.fee and by standard, no project should be able to deploy with the same poolKey. Meaning no project should be able to deploy with the same token0, token1 and fees.
However, it should be made possible to deploy with a combination of both token0, token1 and a different fee according to how it is been done in uniswap, but this invariant is broken and when projects wants to deploy with same tokens but different fees, it fails.
Impact Summary
This breaks the protocol core invariant and as such is a denial of service.
Severity Explanation
This can be classified as a MEDIUM as it only breaks the protocol invariant
Lines of code
https://github.com/code-423n4/2024-06-vultisig/blob/cb72b1e9053c02a58d874ff376359a83dc3f0742/src/ILOManager.sol#L109-L122
Vulnerability details
Finding Description
poolKey
is the combination of thepoolKey.token0, poolKey.token1, poolKey.fee
and by standard, no project should be able to deploy with the same poolKey. Meaning no project should be able to deploy with the same token0, token1 and fees.However, it should be made possible to deploy with a combination of both token0, token1 and a different fee according to how it is been done in uniswap, but this invariant is broken and when projects wants to deploy with same tokens but different fees, it fails.
Impact Summary
This breaks the protocol core invariant and as such is a denial of service.
Severity Explanation
This can be classified as a MEDIUM as it only breaks the protocol invariant
Proof of Concept
The following test will revert with;
Recommendation
I am not really sure on how this can be fixed because it seems like some external issues from how the
createPool
interface is inherited from uniswapAssessed type
DoS