CREATE2 factory permits same-address redeploy
Uniswap (v2 + v3)'s assessment for RD-F-144 — scored green on the v1.7.0 rubric. The evidence below is the curator's reasoning for this score.
Evidence summary #
V3 Factory uses CREATE2 with salt=keccak256(token0,token1,fee); requires pool==address(0) before creating — prevents same-address redeploy with different bytecode. V2 uses CREATE for pair deployment — same pool address re-use is minimal risk (pair already exists). Combined: green.
Detail #
UniswapV3Factory.createPool(): require(getPool[token0][token1][fee] == address(0), 'exists'); CREATE2 salt = keccak256(abi.encode(token0, token1, fee)). A different pool cannot be deployed to the same address — the factory check prevents this even if SELFDESTRUCT were used (which it is not). V2 Factory uses CREATE for UniswapV2Pair deployment: each pair has a deterministic address based on factory address + token0 + token1, but no CREATE2 redeploy risk since the pair already exists and the factory checks for its existence.
Sources #
- GitHubUniswapV3Factory sourceUniswapV3Factory.createPool(): require(pool==address(0)); CREATE2 salt = token0+token1+feeretrieved 2026-04-29
Methodology #
Determine whether a CREATE2 factory deployment allows redeployment to the same address with different bytecode (via selfdestruct + redeploy pattern).
See the full factor methodology and distribution across all protocols →