poolImplementation, so an implementation change invalidates predicted pool addressesOff-chain integrators and users may compute the future pool address with Clones.predictDeterministicAddress(implementation, salt, factory) and optionally pre-fund or display that address before createPool executes.
Factory salt is only keccak256(abi.encode(agreement, index)). ERC-1167 initcode embeds the implementation, so a factory-owner setPoolImplementation() changes the CREATE2 address for the same salt. Tokens or approvals prepared against the old predicted address no longer match the pool that is actually deployed.
Likelihood:
Occurs when addresses are predicted under one implementation and the factory owner updates poolImplementation before create.
Requires an off-chain or front-end workflow that stores or funds the predicted address across an implementation change.
Impact:
Prefunded tokens or approvals can be sent to an unused counterfactual address.
There is no theft from an existing pool; the loss is stranded capital or a broken integration against a stale prediction.
Setup: append the function below to test/unit/ConfidencePoolFactory.t.sol (same ConfidencePoolFactoryTest harness already used by the factory suite), then run:
Predict the next pool address for (agreement, index = 0) under the current poolImplementation.
The factory owner calls setPoolImplementation to a new implementation.
The same salt now predicts a different address.
Prefunding the old predicted address strands tokens there.
createPool deploys at the new prediction, so the stranded balance never reaches the live pool.
Document that predicted addresses are invalid after setPoolImplementation, or include the implementation in the salt or prediction helper that front-ends must use.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.
The contest is complete and the rewards are being distributed.