Flow-gap finding (execution x periphery x first principles). The requester's objective is a 5% FWA hook fee 'in the launch pool'. A Uniswap v4 pool has exactly one hook, fixed in its PoolKey at initialization.

The floor this launch is judged against (.imd/reads/protected/custom_token/Token.protected.t.sol, _key() at line 345-350 and setUp at 165-175) initializes the launch pool with IHooks(poolHook) where poolHook is the factory's PoolInitializationGuard, and the launch.json schema for kind custom_token has no hooks field (pool is only pairedCurrency/fee/tickSpacing/initialPrice). DCAHook can therefore only ever be an application contract beside that pool.

Its own pool (getPoolKey(): same currencies, fee 12500, tickSpacing 60, hooks = DCAHook) is a different PoolId; beforeInitialize at line 91 lets only launchFactory (the msg.sender of the hook's constructor, line 61) initialize it, and the factory's custom_token flow initializes only its guard pool.

End state after a launch as currently scoped: traders buy and sell DCA in the launch pool with FWA and pay zero hook fee; pendingFees() stays 0 forever; claimFees() returns 0; the fee recipient 0xCAE0B01E56cB164ce866A137d3528658b2FCBd4b receives nothing; neither the requester, the fee recipient nor anyone else can open the hook pool afterwards (OnlyLaunchFactory), and the guard pool's hook cannot be changed after initialization.

The README (line 93) acknowledges this dependency but the launch kind named in the job (custom token) does not provide the hook-capable path; the fwa-v2 reference names univ4_hook as the launch kind that deploys the hook as the pool's hook.

Also note for the manifest step: application contracts may only use $token, $requester or $contract:EarlierName, so the hook's first constructor argument must be written as the static PoolManager address 0x000000000004444c5dc75cb358380d2e3de08a90, and POOL_FEE/TICK_SPACING are hardcoded to 12500/60, so a launch policy with any other pool fee or spacing makes the hook pool un-initializable (InvalidPool).

Needed decision: either launch this project under the hook-capable launch kind so the factory initializes the pool with hooks = DCAHook, or accept that the custom_token launch carries no fee. No code change alone fixes it, so no proof test is attached.

Deployment-flow gap. Hooks.validateHookPermissions reverts HookAddressNotValid(address) whenever the hook's own address does not carry exactly the five flag bits 0x20cc in its low 14 bits, so only 1 in 16384 CREATE2 salts (and essentially no CREATE deployment) succeeds.

The protected harness deploys every application contract with a deployer-chosen salt (IMD_PROJECT_SALT_i) and requires deployed.code.length > 0 ('constructor failed'), and launch.json's contracts entries carry only {contract, constructorArgs}: there is no field through which the mined salt from script/PrepareHook.s.sol can reach the deployer.

If the deployer derives salts the way it does for the token (bytes32(launchNumber)) or any other non-mined way, the DCAHook constructor reverts, LaunchProbe.deploy reverts 'constructor failed', and the launch cannot be deployed at all (no funds lost; the launch is blocked until re-submitted).

This is a configuration/service gap rather than an arithmetic defect: the needed evidence is that the deployer supports hook-flag salt mining for this contract (or the hook-capable launch kind handles it). If it does not, the author must either obtain that support or the launch cannot include this hook. No proof test is attached because no code change alone makes it pass.

Area: Trust Gap (access x first principles) and Access Control. The hook only charges its fee inside the pool whose key is getPoolKey() = (DCA, FWA, 12500, 60, hooks = DCAHook). That pool exists only if PoolManager.initialize is called with this exact key, and beforeInitialize (line 91) refuses every initializer except launchFactory, the address that deployed the hook (line 61).

This project is judged as a custom_token launch (.imd/reads/protected/custom_token/Token.protected.t.sol).

In that flow the factory deploys the token and the application contracts by CREATE2, then initializes and seeds ONE pool whose hooks field is its own PoolInitializationGuard (protected test lines 165-175 and 345-350: IHooks(poolHook) with the manifest's IMD_POOL_FEE / IMD_TICK_SPACING), and the custom_token launch.json pool object has no hooks key (kind/token/contracts/pool{pairedCurrency,fee,tickSpacing,initialPrice}/economics/notes; an extra key refuses the file).

So the launch pool traders actually use is (DCA, FWA, 12500, 60, guard): DCAHook.beforeSwap/afterSwap are never invoked, pendingFees() stays 0, claimFees() returns 0 forever, and FEE_RECIPIENT 0xCAE0...Bd4b receives nothing, while the brief requires a 5% FWA fee on every buy and sell in the launch pool.

The breakage is permanent: a v4 pool's hook cannot change after initialization, the hook has no owner or setter, and the OnlyLaunchFactory guard means the requester, the recipient or any third party who later tries to create the fee pool is refused (the factory has no post-launch step that would call initialize with hooks = DCAHook).

The README (lines 93-94) acknowledges that 'merely deploying the hook as an application beside the default initialization-guard pool does not install a fee' and defers to a 'hook-capable deployment path', but no such path exists in the custom_token kind: the reference describes a separate univ4_hook kind that 'deploys only the hook and the token'.

Fix is a scope decision, not a code patch: either launch this project as the univ4_hook kind (so the factory initializes getPoolKey() and launchFactory == the initializer), or accept that a custom_token launch cannot carry a FWA-denominated swap fee and tell the requester. Dropping the OnlyLaunchFactory check alone does not help: the factory's fee-free pool would still be the launch pool. The salt problem in finding 2 is a second, independent blocker of the same root cause.

Area: Trust Gap at the deployment boundary (access control hands out roles in the constructor; the constructor itself has a precondition the launch flow cannot express). Line 63 calls Hooks.validateHookPermissions, which reverts HookAddressNotValid unless address(this) & 0x3fff == 0x20cc. That is only satisfied by a mined CREATE2 salt (about 1 in 16384 salts).

The custom_token launch.json contracts entries are {contract, constructorArgs} only; the protected harness deploys each application contract with a salt the verifier supplies (IMD_PROJECT_SALT_i) and requires the deployment to succeed (require(deployed != address(0) && deployed.code.length > 0, 'constructor failed')).

If that salt is derived rather than mined against this exact creation code, constructor args and the factory address, the hook constructor reverts and with it the whole launch (setUp of every protected test fails; on chain, ProjectFactory.launchCustom reverts). README lines 80 and 91 push this onto the deployer ('Prepare the hook's CREATE2 address using the actual deploying factory ...

The low address bits must be 0x20cc') but nothing in the repository, the manifest schema or the described service does it. Needed evidence before admission: the deployer's salt derivation for application contracts, or confirmation that the launch kind used mines hook salts (the univ4_hook kind presumably does). Mining must be redone whenever the token address, the compiler settings or the factory address changes, because all three enter the init-code hash.

Severity is medium rather than high because the failure is a revert before any funds move; it blocks the deliverable rather than losing value.

First-principles / execution-trace finding about the deployment leg.

DCAHook's constructor binds three assumptions that nothing in the custom_token launch flow enforces: (1) its own address must carry the hook flag bits 0x20cc, so it must be deployed by CREATE2 at a salt mined for that purpose (src/DCAHook.sol:63, src/HookMiner.sol:17); (2) the launch pool must be initialized with PoolKey.hooks == this contract, otherwise beforeSwap/afterSwap are never invoked and no fee exists (src/DCAHook.sol:62, 84-93); (3) PoolManager.initialize must be called directly by the address that deployed the hook (src/DCAHook.sol:61, 91).

The protected floor for this launch kind (.imd/reads/protected/custom_token/Token.protected.t.sol) models the factory as deploying application contracts at deployer-supplied salts (IMD_PROJECT_SALT_i, lines 186-197) and initializing the launch pool with the platform's PoolInitializationGuard as hooks (lines 165-175 and _key() at 345-350).

The custom_token manifest schema in the assignment has no contract salt field and no pool.hooks field, and the reference names a separate univ4_hook launch kind as the one that deploys a hook into the pool.

Consequences on the custom_token path: with any salt the requester did not mine (probability 16383/16384 per salt), the hook constructor reverts HookAddressNotValid and the factory's CREATE2 deploy fails, so the whole launch transaction reverts; with a mined salt the hook deploys as a sibling contract, but the pool the factory opens has the guard as its hook, every buy and sell in it pays zero hook fee, FEE_RECIPIENT never receives anything, and because a v4 pool's hook is part of its PoolId the launch pool can never be re-pointed at DCAHook.

The README states the dependency in prose but nothing in the tree or the manifest schema enforces it. This is not fixable in src: a v4 hook fee can only exist if the factory creates the pool with the hook.

Needed evidence before admission: the factory's hook-capable path (the univ4_hook kind or an equivalent), its ABI showing that it accepts or mines a CREATE2 salt with the 0x20cc bits for the hook's exact init code (type(DCAHook).creationCode ++ abi.encode(poolManager, token), with the canonical mainnet PoolManager that script/PrepareHook.s.sol:16 hardcodes), that it initializes PoolKey(sorted(DCA,FWA), 12500, 60, DCAHook), and that the initialize call originates from the same address that executed the CREATE2 (otherwise beforeInitialize reverts OnlyLaunchFactory at src/DCAHook.sol:91).

If no such path exists for this launch kind, the brief's hook fee cannot be delivered and the scope decision belongs to the requester.