Implemented the no-owner launch guard, fixed-supply token, vendored dependencies, and deployment documentation.

Both swap types enforce the 1% output cap until exactly 24 hours after initialization.

Verified with Solidity 0.8.26:

• forge build passed
• forge test: 72 passed
• forge fmt --check passed

The findings file is written and validated: both snippets match the tree, the proof fails on the current code, and the full existing suite passes. The review is complete.

Outcome. Within the Execution Trace, Periphery and First Principles areas, the hook's swap-gating control flow holds. The only code defect I could substantiate is a deployment-time one, plus one scope observation.

Findings written to .imd-findings.json:

1. Medium: the constructor needs a live token contract. LaunchGuardHook refuses to deploy unless the token address already has code, then reads totalSupply() from it. Those constructor arguments are baked into the attested creation code, and the admission floor in Hook.protected.t.sol deploys only a PoolManager before running CREATE2 on that code. In that environment the token address is empty, the constructor reverts with InvalidConfiguration, and every protected hook test fails in setUp. The manifest schema also resolves only $poolManager, with no placeholder for a token created in the same launch transaction. The scratch proof at test/scratch/ConstructorRequiresTokenCode.t.sol reproduces this and currently fails. A constant cap derived from the fixed supply, or a lazy read in beforeInitialize, would remove the dependency without changing the 1% rule.

2. Info: the limit is per swap call. Two consecutive exact-output buys of the cap in one block acquire 2% of supply. The README documents this and the brief says "any swap", so it is recorded as a design observation, not a defect.

What held under tracing. The preview library reproduces the vendored Pool.swap loop step for step: fee composition with protocol fee, price-limit validation, bitmap traversal and clamping, tick crossing with liquidity net, and rounding. Checked arithmetic in the preview cannot diverge from core's unchecked blocks for reachable values. The exact-output-within-cap shortcut is sound because core never delivers more than the specified output. All ten unflagged callbacks are unreachable from the PoolManager and reject other callers. The token is unmodified OpenZeppelin ERC20 with a fixed supply.

Static-analysis leads were checked and dropped: the strict equality on endsAt == 0 is safe because a stored deadline is never zero, the timestamp comparisons are the intended 24-hour boundary, and the "reentrancy" in the constructor writes only immutables after a view call.

Coverage record. All 13 listed entry points have rows, 12 holds and the constructor as finding, plus two invariant rows. Nothing was left unreached.

Added boundary and failure-path tests, plus stateful invariants for guard behavior, settlement, token balances, and allowances. All changes are under test/.

forge build and forge test pass: 97 tests, including 98,304 invariant calls, with no failures or skips.

No reproducible defects found.

Review complete. The findings file is written at .imd-findings.json, the scratch tests are removed, and no source files were changed.

Outcome: no permission defects found. The hook's access model holds under the Access Control, Trust Gap and Asymmetry guides. I recorded two info-level trust assumptions, each with a concrete reproduction I executed against the vendored PoolManager.

What I verified

• Every callback is guarded by onlyPoolManager from BaseHook. Only beforeInitialize and beforeSwap are enabled, and the mined address flags match them. The other eight callbacks are stubs that revert and are never called.
• guardEndsAt has one writer, reached only through PoolManager initialize, rejects re-initialization, and rolls back when the manager's own initialize fails.
• The simulate/execute pair is symmetric. The preview reads the same slot0, liquidity, bitmap and tick-net values Pool.swap reads, composes protocol and LP fees identically, and reverts in the same price-limit and exact-output-with-100%-fee cases. Nothing runs between the hook call and the swap. I confirmed this also holds for dynamic-fee pools, where the LP fee stays zero because the hook never calls the fee updater.
• The exact-output shortcut is sound: output can never exceed the specified amount, so skipping the preview at or below the cap cannot let a larger buy through.
• The hook has no fallback or receive and never calls the manager except for static reads, so no path makes it the swap caller, which would skip its own beforeSwap.
• The token is unmodified OpenZeppelin ERC20 with a fixed supply minted to the deployer.
• Static-analysis leads: the strict equality is an intended sentinel that cannot be zero, the timestamp comparisons bound a 24-hour window where miner drift is immaterial, and the constructor's external call precedes only immutable writes on the project's own token.

Info findings recorded

1. The cap is per swap, as the brief specifies. Five swaps of exactly the cap inside one unlock buy 5% of supply in one transaction at the same price as one rejected 5% swap. Documented in the README, so this is a design limit, not a defect.
2. beforeInitialize is permissionless. If deployment and initialization were ever split across transactions, an outsider could initialize the intended pool first at any price and start the timer. Safe under the documented and platform-enforced atomic flow.

Coverage has a row for all 13 listed entry points plus four invariants. Nothing was left unreached.

Review complete. The findings are in .imd-findings.json at the repository root, with two findings and a sixteen-row coverage record. No tracked files were changed; only test/scratch/ and the findings file were written.

Math area verdict: clean. I checked the Math Precision, Boundary and Numerical Gap failure modes against the hook and the preview library, and found no arithmetic defect.

• Cap arithmetic is exact. Total supply is 1e27, so the cap is 1e25 with no truncation. The cast of a positive exact-output amount to unsigned is safe.
• Exact-input boundary is exact. A binary search on a live local pool found the input whose output is exactly the cap is allowed, and one more wei of input, producing cap plus one, is rejected.
• Preview fidelity. I compared SwapPreview.outputAmount line by line with the pinned core swap loop and probed where fuzzing had not reached: tick spacing 32767 across a liquidity gap in both directions, protocol fee at its maximum with a zero LP fee, a dynamic-fee pool, a 100 percent LP fee, and a tight-limit partial exact-output fill. Every case matched core to the wei. Every revert the preview can raise is also a core revert, so the hook cannot block a swap core would accept.
• Time boundary is the documented half-open window of 86400 seconds per pool ID, with no overflow and a nonzero sentinel even at timestamp zero.
• Static-analysis leads did not hold up. The strict equalities are core's own loop semantics, and the aderyn reentrancy line is a constructor.

Findings reported

1. Medium, outside my area. The constructor reverts when the token address has no code. The pinned admission harness in Hook.protected.t.sol deploys only a pool manager before creating the hook from its attested creation code, so the hook cannot be constructed there and the whole protected hook floor fails in setUp. A proof test under test/scratch/ fails on the current code with "hook deployment reverted". The fix is to stop requiring token code at construction, for example deriving the cap lazily or from the fixed supply constant.
2. Info. Guarded exact-input buys pay a second full tick traversal. Measured on a tick-spacing-1 pool with distant liquidity, the guarded swap cost about twice the unguarded one. The README documents this; it is recorded for the deployer's choice of tick spacing and liquidity shape.

Not reported as defects: the per-swap cap is trivially aggregated across swaps in one transaction, which matches the specification's wording and is noted in a coverage row instead.

The economics audit is complete. The findings file is written and the working tree holds only that file beyond the original sources.

Result: no exploitable economic defect found. The hook enforces the stated guarantee correctly. One informational note is recorded.

What I verified in the assigned area

• Preview equals core. The guard's decision for exact-input buys rests on SwapPreview reproducing Pool.swap output. I compared it line by line against the vendored core (fee selection, price-limit checks, bitmap traversal and clamping, step math, tick crossing) and ran a differential fuzz far broader than the repo's own: six tick spacings including 1 and 32767, LP fees across the full range, protocol fees, initial prices across the whole tick domain, positions at the usable extremes, both directions, exact in and out, random price limits. Across 5000 runs, with the last 2000 forcing a successful core swap on every run, outputs matched exactly and the preview never reverted where core accepted.
• Cap paths. Exact output at or below the cap is bounded by core itself. Larger exact-output and all exact-input buys go through the equal preview. Sells, post-deadline swaps and partial fills behave as specified. The checked arithmetic in the preview cannot revert within the tick-spacing bounds core enforces.
• Token flow out of the pool. Every path that hands launch tokens to a non-LP passes through beforeSwap. Liquidity removal returns only the LP's own position, donate only adds, and the self-call skip in Hooks.beforeSwap is unreachable because the hook never swaps and has no owner.
• Timer and token. Per-pool deadline set once, not resettable, rolls back on failed initialization. The token is unmodified OpenZeppelin ERC20 with a fixed supply, so the constructor's supply read stays valid.

Informational finding recorded. The cap is per swap and stateless across swaps, exactly as the spec and README say. A demonstration bought 40% of total supply inside the window in a single transaction by chaining forty capped exact-output swaps, at roughly 980k gas in total. This is the intended design rather than a code defect, so it is filed as info with the concrete reproduction for the judge to weigh.

Static-analysis leads were checked and dismissed: the strict equalities and timestamp comparisons mirror core semantics, and the aderyn reentrancy line is a constructor with no reentrant surface.

Coverage. All thirteen listed entry points have rows, plus four invariant rows. The eight non-enabled callbacks are unreachable from the manager and revert on direct calls. Scratch tests were removed after use.

Recorded two medium findings in .imd-findings.json:

• Constructor cannot deploy in the protected admission harness.
• Manifest’s zero token address prevents launch deployment.

Specialist duplicates merged; all 13 entry points covered. All 97 original tests passed; both constructor proofs reproduced the failure. Production files remain unchanged.

Fixed the reproduced constructor failure by deferring token validation and cap resolution to authenticated pool initialization. Added regression tests, updated deployment documentation, and recorded the finding as fixed in .imd-responses.json.

Passed: forge build, all 80 project tests, the unchanged reviewer proof, and forge fmt --check.

The deployment failure is reproduced and remains unresolved: the verified LaunchToken deployment address is missing.

Corrected launch.json notes and recorded the blocker in .imd-responses.json. Schema validation, forge build, and all 82 tests passed, including the failure reproducer. Completing the fix requires the verified token address.

Updated tests for deferred supply validation, preserving failure and boundary coverage and adding initialization rollback/retry checks.

forge build and forge test pass: 107 tests, including three invariant campaigns covering 98,304 random calls.

Changes are limited to test/.

Wrote .imd-findings.json.

• Constructor finding: fixed; all prior proofs pass.
• Manifest finding: remains medium; zero token address still reverts deployment.
• All 13 entry points covered; 112 tests passed offline.
• No additional defects found. Temporary proofs removed.

Confirmed the deployment failure. Fixing it requires the verified production LaunchToken address or factory prediction inputs; neither was supplied.

Manifest unchanged. Recorded the unresolved finding in .imd-responses.json.

Schema validation, forge build, and all 82 tests passed. Passing tests do not resolve the deployment blocker.