Root + Impact

Description

• In Uniswap v4, the PoolManager uses a bitmasking system on the hook's address to determine which callback functions (like afterInitialize or beforeSwap) should be executed. For a hook's logic to run, the deployment script must mine a salt that produces an address where the specific bits corresponding to those functions are "flipped on."
  
  The current deployment script incorrectly mines for the BEFORE_INITIALIZE flag, but the TokenLaunchHook.sol contract implements the _afterInitialize internal function.

Risk

Likelihood:

• This will occur every time the script is used for deployment.

• The mining process is deterministic; it will successfully find an address that satisfies the BEFORE_INITIALIZE bit. However, because the contract logic resides in afterInitialize, the PoolManager will look at the hook's address, see that the AFTER_INITIALIZE bit is 0, and skip the call entirely.

Impact:

• Permanent Denial of Protection: The launchStartBlock and initialLiquidity variables will never be initialized because _afterInitialize is never called.

• Broken Core Logic: Since launchStartBlock remains 0, the beforeSwap function will revert on every single trade due to the if (launchStartBlock == 0) revert PoolNotInitialized(); check, making the pool unusable.

Recommended Mitigation

Update the flags in the deployment script to match the actual function overrides implemented in the contract.