Everything is delivered and committed on main as 9e774be. Clean build, 35 passing tests, and forge fmt --check all succeed with an empty environment.

What was built

• src/LaunchGuardHook.sol is the launch guard. It enables beforeInitialize, beforeSwap, and afterSwap only, with no owner, no admin functions, and no delta or fee permissions. At initialization it records the window start, which side of the pair holds the launch token, and the cap of one percent of total supply. During the 24-hour window, beforeSwap rejects exact-output buys above the cap. afterSwap rejects any buy whose realized output exceeds the cap, which is what makes the guard hold for exact-input swaps. After the window, every swap passes.
• src/LaunchToken.sol is the fixed-supply OpenZeppelin ERC-20 named "Launch Guard" (LGRD) minting 10^27 units to its deployer, with no mint, pause, owner, or upgrade path.
• src/HookFlags.sol and test/mocks/MockERC20.sol match the paths and signatures the pinned admission tests import.
• script/DeployLaunch.s.sol mines a CREATE2 salt and deploys token then hook. Its run() reads the environment; tests call deploy directly with explicit arguments.
• Dependencies are vendored as plain files under lib/ with licences and a VENDORED.md listing exact commits. No submodules.

Verification

• 35 tests across three suites cover permissions, caller refusal, initialization binding, both pair orderings, native ETH quote, the exact window boundary at the 24-hour mark, per-pool windows, rejected swaps leaving state untouched, and three fuzz tests.
• I also ran the two pinned protected test files in scratch space against the real hook and token creation code. All nine passed, including the opcode scan and the flag agreement check.
• Slither and Mythril were not available and did not run.

One judgment call to flag

The brief names beforeSwap as the rejecting callback. I added an afterSwap check with the same cap and window because the output of an exact-input swap is unknown before the pool runs it, and exact input is the common router default. Without it, the stated behaviour would not hold. The README explains this, along with assumptions, deployment parameters, the Wizard-style configuration record, and operational responsibilities.

Open items for the deployer

• The hook constructor takes the PoolManager and the launch token address, so the factory must know the token address before finalizing the hook's creation code.
• The window starts at pool initialization, so liquidity should be seeded promptly afterward.
• An independent adversarial review is still required before the hook fronts a live pool.

Wrote .imd-findings.json with no substantiated defects and coverage for all four required entry points.

All 35 Foundry tests passed, including three fuzz tests. Production files remain unchanged. Deployment-specific manifest and constructor binding were not verified.

Saved .imd-findings.json with no substantiated defects and coverage for all four required entry points.

All 35 existing Foundry tests passed. Production files remain unchanged. Protected harnesses were read; protected-suite and fork execution remain unverified.

Saved .imd-findings.json.

No substantiated defects found. All four listed entry points covered; 35 existing tests and six additional control-flow tests passed. Live deployment checks were not run.

The review is complete and .imd-findings.json holds two substantiated findings plus a ten-row coverage record.

Findings

• Medium, src/LaunchGuardHook.sol:191. The cap is enforced only on the current swap, with no running total per pool, sender, block or transaction. Inside one unlock, twenty exact-output buys of exactly the cap each pass both callbacks and settle together. In the reproduction, one block after initialization, a single transaction bought 20% of total supply for about 600k gas, while the same amount in one swap was refused. The README's claim that the cap "slows a single-transaction sweep" does not hold. The brief's literal per-swap wording is met, so the fix is a scope decision for the author, which the finding spells out. A Foundry proof is attached: it fails on the current code and passes once a cumulative cap exists.
• Low, src/LaunchGuardHook.sol:167. The pool key's fee is never validated, so anyone can initialize a launch-token pool through the hook with the dynamic-fee flag. That pool starts at zero LP fee, and since only the hook may call updateDynamicLPFee and it never does, the fee is stuck at zero forever. Reproduced with a native-ETH/LGRD pool from an arbitrary address.

Checked and found holding

• Window reset: a second initialize of the same key reverts in the pool library after the hook write, so the write is rolled back.
• Per-swap boundary at the cap and at the 24-hour mark, exact-input enforcement in afterSwap, sells and post-window swaps untouched.
• No fund custody, no delta returns, and the aderyn reentrancy lead is a view call to an immutable stock ERC20.
• All three token entry points are unmodified OpenZeppelin v5.4.0 with fixed supply.
• Slither timestamp and strict-equality leads are benign sentinel and window comparisons.

Not reached in depth: liquidity-position acquisition as a non-swap path to launch tokens, which I judged legitimate limit-order behavior rather than a cap bypass, and hookless pools, which are inherent to a hook-only guard. Scratch tests live under test/scratch/, which is gitignored.

Done. The hook holds up under adversarial testing; the one real defect I found is a low-severity overflow at the edge of the supply range, reported with a runnable proof. Nothing outside the test tree was modified, and nothing was installed.

What I delivered, all under test/, building on the existing 35-test suite without changing it:

• test/LaunchGuardHookEdge.t.sol: 23 tests on inputs the implementation did not pick. Re-initialization cannot re-stamp the window. A second PoolManager cannot open a pool through the hook. Swaps on unopened pools fail before the hook, and manager-level calls for unknown pools revert. White-box checks drive beforeSwap and afterSwap as the manager with crafted deltas, including the quote leg at int128 max, int256 max requests, zero and negative outputs, and sells of any size. Partial fills show afterSwap judges realized output while beforeSwap judges the request. A batched router proves the cap is per swap and that one bad swap fails the whole unlock. Tiny supplies round the cap down to one or zero, a mintable token's cap stays frozen, dynamic-fee pools stay capped, liquidity and donations stay open, and the callbacks stay under the gas target. Three fuzz tests at 512 runs cover the full int128 and int256 domains plus any supply.
• test/invariant/LaunchGuardHook.invariant.t.sol with its handler: 128 runs by depth 64 of random buys, sells, liquidity changes, warps across the window, new pools opened mid-run, stranger callbacks and re-initialization attempts. Each swap is first run in a state snapshot with every window closed, so the pool's own answer is the oracle. The real result must equal it exactly, or be a cap rejection naming that exact amount. Eight invariants cover no buy above the cap while active, no rejection outside the window or on sells, immutable launch records, guard state equal to the clock and never reopening, the hook holding no value, and supply conservation.
• test/invariant/LaunchToken.invariant.t.sol with its handler: 256 runs over transfers, overdrawn transfers, allowances, zero-address transfers and admin selectors. Supply is fixed and equals the sum of holder balances.
• test/utils/ and test/mocks/MultiSwapRouter.sol: shared fixture, a wrapped-error decoder, and a router that runs several swaps in one unlock.

Findings are in .imd-findings.json, five in total:

• Low, with proof: computing the cap as supply times 100 overflows for any token whose supply exceeds about 1.16e75, so such a token can never open a pool. The proof test fails on the current code with a wrapped arithmetic panic and passes once the cap is computed as supply divided by 100.
• Info: a pool initialized at timestamp zero is permanently unswappable because zero is also the "never initialized" sentinel. Unreachable on a live chain.
• Info: the cap is per swap, so a router can buy the cap several times in one transaction. This matches the brief and the README, and the batched-swap test documents it.
• Info: the guard only covers pools that name the hook. The token is unrestricted, so a hookless pool or any other venue trades it freely during the window. The README does not state this.
• Info: exact-output requests above the cap are refused even when the price limit would have delivered less. Safe direction, but integrators should size requests to the cap.

Verification: forge build is clean and forge test passes 63 of 63 delivered tests. The only failing test in the tree is the proof under test/scratch/, which is supposed to fail and is deleted before submission. The two harness problems I hit along the way were mine, not the hook's: an expected revert consumed by a view call in an argument, and v4's checked liquidity router asserting on fee credits, which I replaced with the no-checks router. The findings file is listed in the repository's git exclude file, so it does not appear in git status; nothing is committed, since the task did not ask