Description:Description\
The createSwapPair function in the StableSwapTwoPoolDeployer contract is protected by the onlyOwner modifier, meaning it can only be called by the contract owner.
However, despite this restriction, there is no mechanism in place to prevent the contract owner from unintentionally creating multiple stable swap pools with identical token pairs and parameters (amplification coefficient _A, fees _fee and _admin_fee).
The function allows multiple identical pools to be deployed because a unique salt is generated using block.timestamp, which changes with each call, even if the tokens and parameters remain the same.
Attack Scenario\
The owner, either through operational error or oversight, might deploy the same pool multiple times, with the same token pair and parameters. This would result in Liquidity Fragmentation and Arbitrage Opportunities
The fix introduces a pool registry (swapPairRegistry) that stores deployed pool addresses using a unique key generated from the token pair and parameters.
The require statement ensures that a pool with the same parameters cannot be deployed multiple times by mistake, even by the contract owner.
This fix prevents accidental duplicate pool deployments, ensuring that liquidity remains consolidated and economic inefficiencies are avoided.
Github username: -- Twitter username: -- Submission hash (on-chain): 0xa0f76ed3f1cf016f8801f838b4ee6e099841950bfd2e45dac7c58f4d80d7a01a Severity: medium
Description: Description\ The
createSwapPair
function in theStableSwapTwoPoolDeployer
contract is protected by the onlyOwner modifier, meaning it can only be called by the contract owner.However, despite this restriction, there is no mechanism in place to prevent the contract owner from unintentionally creating multiple stable swap pools with identical token pairs and parameters (amplification coefficient _A, fees _fee and _admin_fee).
The function allows multiple identical pools to be deployed because a unique salt is generated using block.timestamp, which changes with each call, even if the tokens and parameters remain the same.
Attack Scenario\ The owner, either through operational error or oversight, might deploy the same pool multiple times, with the same token pair and parameters. This would result in Liquidity Fragmentation and Arbitrage Opportunities
Recommendation
The fix introduces a pool registry (swapPairRegistry) that stores deployed pool addresses using a unique key generated from the token pair and parameters.
The require statement ensures that a pool with the same parameters cannot be deployed multiple times by mistake, even by the contract owner.
This fix prevents accidental duplicate pool deployments, ensuring that liquidity remains consolidated and economic inefficiencies are avoided.