The hook corrupts protection logic when attached to multiple pools because initialization of one pool overwrites the launch state of previously initialized pools, causing incorrect phase calculations and limit enforcement across all pools.
Likelihood: High
Reason 1: Uniswap V4's architecture explicitly encourages hook reuse across multiple pools—projects commonly attach the same hook instance to related token pairs (e.g., TOKEN/ETH and TOKEN/USDC during launches).
Reason 2: The hook provides no warnings or validation preventing multi-pool attachment, creating a silent failure mode where protection appears functional but is critically broken.
Impact: High
Impact 1: Phase calculations become completely unreliable—swaps on Pool A may be evaluated against Pool B's launch timeline, causing premature phase transitions or permanent Phase 1 enforcement.
Impact 2: Swap limits miscalculated using wrong liquidity snapshots (e.g., 5% of Pool B's liquidity applied to Pool A swaps), enabling attackers to bypass intended protections or legitimate users to be incorrectly blocked.
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.