The review is complete. No tracked file was changed, and the findings are in .imd-findings.json.

Verdict: no critical, high or medium defect. The corrected hook and token do what the task and SPEC.md require. The findings are three lows and two informational notes, each with a concrete failing input.

What I verified on this commit

• Offline suite: 34 passed, 0 failed, 512 fuzz runs, 2 fork tests skipped without an RPC.
• Real-LaunchFactory fork rehearsal on Robinhood Chain 4663 with the public RPC: both token orders pass, including 80/10/10, bind, enable, and relay commands 1 and 2 from a buy and a sell.
• Current pinned protected floor reproduced under test/scratch with shims for the verifier's helpers: 16 passed, 0 failed, 0 skipped when the harness builds its PoolManager at the hook's constant address.
• On-chain reads: chain id 4663, the factory's PoolManager equals the hook's constant, IMD has 18 decimals.
• launch.json: schema keys only, constructor args match the constructor in order, permissions match flags 0x2040, fee 12500, notes under 4,000 characters.
• beforeInitialize accepts only the PoolManager with the factory as sender, returns its selector, never binds or enables. Counterfactual initialization of the predicted key reverts. afterSwap logic, int128 widening, inclusive threshold and cooldown, zero delta and no fund handling are all correct. The token mints exactly 1e27 once to the factory with no owner, mint, tax or freeze.

Findings

• Low, bindPool accepts a never-initialized key at src/IMDPhysicalHook.sol:78. Binding fee 3000 instead of 12500 succeeds, the real pool then never emits, and rebinding reverts. Unchanged since the prior audit. The hook now sees the real key in beforeInitialize and could record it for bindPool to match without binding automatically.
• Low, hard-coded PoolManager at line 19. Correct for chain 4663, but the pinned floor fails one test and skips another when the verifier does not pass the manager address. The task fixes constructor args to owner and factory, so the adapter must either keep the constant and ensure admission supplies that address, or add a $poolManager argument.
• Low, inherited one-step renounceOwnership at line 16. After enabling, a renounce leaves nobody able to disable or retune the relay while commands keep firing. README documents this as accepted behaviour.
• Info, dust sells can hold relay 4 OFF. Selling for 0.05 IMD every 10 seconds wins each cooldown window and genuine buys inside it are skipped. Design property, owner-tunable.
• Info, scope statement listing what was read and run.

Contracts read: both project contracts in full, all tests, SPEC, README, VALIDATION, launch.json, the four protected floor tests, and the vendored v4-core Hooks and PoolManager constructor. Not reached: the LaunchFactory and admission/deployer sources beyond their ABI and on-chain behaviour, the IMD token source, the verifier's real helper files, and the external gateway.

Scratch reproductions live in test/scratch/OwnerSideRepro.t.sol and test/scratch/protected/, which are ignored by git and not part of the submission.

The work is committed as 8b893ef on codex/imdirector-launch, with a clean tree.

Outcome

The IMDirector / Director hook and token are adapted for the Robinhood Chain univ4_hook launch, and every check the brief names passes. Three audit findings reproduced and are fixed with tests. Nothing was deployed, by design: IMD's deployer launches the attested source through the LaunchFactory, so the token, hook and pool addresses, PoolKey and poolId exist only after that launch.

Source changes in src/IMDPhysicalHook.sol

• PoolManager is now a constructor argument. The constructor is (IPoolManager $poolManager, address $owner, address $factory). Audit finding a152f7ee reproduced: with the compiled constant, the pinned admission floor only passed when the verifier happened to build its manager at that exact address. The launch reference also forbids hardcoding it. The constructor stores the address and refuses zero, making no call. launch.json constructorArgs is updated to match.
• bindPool requires an initialized pool. Audit finding 16ef6c00 reproduced: a mistyped key consumed the one-shot bind forever. The hook now reads slot0 through StateLibrary and reverts with PoolNotInitialized unless the price is set. Since only the factory can open pools on this hook, this also enforces binding to the pool the factory actually opened.
• renounceOwnership is disabled. Audit finding cf32bd75 reproduced: a one-step renounce after enabling left no owner able to turn the relay off. Two-step transfer is unchanged.

The two info findings (cooldown griefing by dust sells, scope statement) changed no code. The griefing property follows SPEC items 5 and 6 and is owner-tunable through setRule.

Unchanged: RelayTriggered ABI, relay semantics (buys ON, sells OFF, 0.05 IMD minimum inclusive, 10 s cooldown, 120 s TTL), manual owner bind then enable, zero hook delta, no funds handled, token (1e27 minted once to the factory, no owner or mint), flags 0x2040.

Verification

Check	Result
forge build + forge test with the verifier's fuzz seed	38 passed, 0 failed, 2 skipped (need RH_RPC), 512 fuzz runs
Real-LaunchFactory fork rehearsal on chain 4663	2 passed, both token orders, 80/10/10, buy and sell commands
Canonical-fork integration suite	8 passed
Reproduced protected admission floor, token below IMD	16 passed, 0 skipped
Same, token above IMD	16 passed
Same, non-canonical manager address	16 passed (the previous build failed here)

The admission reproduction lives in test/scratch/ with the four pinned tests and stand-ins for the verifier's helpers; it is not submitted. ADAPTATION.md lists each change, file, and the rule or finding behind it. VALIDATION.md records the runs. ABIs are exported under abi/.

Open items for the requester and IMD

• One judgment call to be aware of: the brief fixed constructor arguments as [$owner,$factory]. I added $poolManager ahead of them, as the audit finding and launch reference require. The brief authorizes exactly this kind of compatibility fix when backed by a concrete finding, and the two named arguments keep their relative order.
• After launch, the owner reads the real Initialize event, calls bindPool once, the operator connects the gateway, and the owner calls setEnabled(true). Relay reactions stay disabled until then.

Repaired the build failure by loading fixture bytecode from build artifacts, preserving all assertions and run counts.

• Fresh forge build: passed.
• Required-seed offline tests: 98 passed, 0 failed, 2 RPC skips.
• Admission checks: 38 passed.
• Separate fork runs: 8 integration tests and both factory rehearsals passed.

Changes stay within test/. Results are documented in TESTING.md. No mainnet transaction was broadcast.

Done. launch.json is the only changed file and it describes the hook and token as they exist in this tree.

Manifest contents

• Hook IMDPhysicalHook, constructor arguments $poolManager, $owner, $factory, matching the declared constructor in order.
• Permissions beforeInitialize and afterSwap, matching getHookPermissions and the 0x2040 flags the constructor validates.
• Token IMDirectorToken, name IMDirector, symbol Director, 18 decimals, no constructor arguments.
• Pool paired with IMD at the given lowercase address, fee 12500, tickSpacing 60, initialPrice as the launch facts give it.
• Notes run 3164 characters, under the 4000 cap, and the first key is the discriminator.

Audit findings All three low findings reproduced against the arriving description but are already fixed in this working tree by earlier accepted work, each with a test: bindPool reverts on an uninitialized key, the PoolManager is a $poolManager constructor argument rather than a constant, and renounceOwnership reverts. The two informational findings needed no change. The notes record this per finding.

Verification forge build is clean. forge test with the verifier's fuzz seed passed 98 tests with 0 failures. The two fork rehearsals against the real Robinhood Chain LaunchFactory also passed in both token orders when run with the public RPC. The protected admission floor is reproduced under test/admission and passes in both token orders without skips.

No contracts are deployed by this task. Addresses, the full PoolKey and poolId come from the deployment receipts after admission, and relay reactions stay disabled until the owner binds the pool and enables the hook.

I found no permission defects, so .imd-findings.json has an empty findings list plus a coverage row for all 9 listed entry points, each marked holds. This came from reading the source and launch.json only. I did not run forge test or write any test under test/scratch/, and no other files were changed.

Access control

• afterSwap: only the PoolManager can call it. Swaps on another pool, or while the hook is unbound or disabled, return the selector with a zero delta and move no funds.
• beforeInitialize: it accepts only the PoolManager with sender == launchFactory (src/IMDPhysicalHook.sol:168-172). It is a view function, so it can never bind or enable. Anyone else trying to initialize the predicted pool first gets OnlyLaunchFactory.
• bindPool: owner only, and it works once. The key must point at this hook, have its two currencies in sorted order with IMD on exactly one side, and already be initialized in the PoolManager. Since only the factory can initialize, a mistyped key can't use up the one bind.
• setEnabled: owner only. Turning it on requires a bound pool; turning it off is always allowed.
• setRule: owner only, and a zero threshold is rejected.
• Ownership: it moves only in two steps (transferOwnership, then acceptOwnership by the new owner). renounceOwnership is overridden to always revert. The factory and tx.origin never get owner rights.

Trust gap and asymmetry

• Owner powers: the owner can change the buy and sell states, the threshold and the cooldown, including setting the cooldown to 0. SPEC.md allows this, so I count it as a trust assumption, not a defect.
• Initialization checks: beforeInitialize does not check the fee or tick spacing. The factory is the only caller allowed, and the brief doesn't ask for those checks.

Token: IMDirectorToken is a plain OpenZeppelin ERC20. It mints 1e27 once to its deployer (the factory) and has no owner, extra mint function or transfer tax.

Manifest: the constructor arguments are [$poolManager, $owner, $factory], which matches the constructor's parameter order. The brief said [$owner,$factory], but the PoolManager has to be a constructor argument written "$poolManager" under the manifest rules, so this is correct. The permissions match getHookPermissions, and the pool fee is 12500 (1.25%).

Static analysis leads, none turned into findings:

• Unused return at bindPool: only sqrtPriceX96 is needed from getSlot0, so ignoring the rest is fine.
• Timestamp comparison in afterSwap: it is used only for the 10-second cooldown, as the spec intends.
• Centralization risk: this is the owner role the spec asks for.

Not covered: I didn't reproduce the deployment receipts, the PoolKey or poolId, or the fork and admission test runs; the brief says these come after deployment.

I found no defects in the math review (precision, boundaries, numerical gaps). .imd-findings.json holds an empty findings list and 11 coverage rows: all 9 listed entry points marked holds, plus two extra checks (beforeInitialize and the launch.json numbers). I changed no other files. The local suite passed with 98 tests, 0 failed and 2 skipped; the skipped two are presumably the Robinhood-fork launch tests, which need an RPC this machine didn't have. That includes the protected admission floors for Hook, Owners, OwnToken and Token, run in both token orders.

What I checked in afterSwap (src/IMDPhysicalHook.sol:132-166):

• Amount: the IMD amount is the absolute value of the actual IMD delta. It is converted to a wider type before being negated, so the most negative possible value (int128.min) can't overflow.
• Buy or sell:
  • IMD going into the pool with the other currency coming out counts as a buy, and the reverse counts as a sell.
  • Zero or same-sign deltas are ignored.
  • This works whichever currency is first in the pair.
• 0.05 IMD threshold: inclusive, because the skip test is amount < minImdAmount.
• Cooldown:
  • The boundary is inclusive, because the skip test is now - last < cooldown. That subtraction can't underflow.
  • The first eligible swap fires even at timestamp 0, because the check is skipped while lastCommandId == 0.
  • A cooldown of 0 never blocks.
• Expiry: block.timestamp + 120 can't overflow.
• No side effects: skipped swaps change neither the timestamp nor the command ID, and the hook always returns a zero delta.

Other code:

• setRule / setEnabled: neither resets the cooldown timestamp, and a zero threshold is rejected.
• bindPool:
  • It checks that the currencies are sorted, both nonzero, and that exactly one of them is IMD.
  • It refuses a pool the PoolManager hasn't initialized.
  • Slither flagged that it ignores some of getSlot0's return values. That's intended: only the price is needed to tell whether the pool exists.
• Token: 1_000_000_000 ether is exactly 1e27, minted once to the deployer, using standard OpenZeppelin ERC20 maths.
• Ownership: the two-step owner transfer is inherited from OpenZeppelin unchanged, and one-step renunciation always reverts.

Manifest numbers: fee 12500, tick spacing 60 and 18 decimals are all correct. The constructor arguments are in the right order. initialPrice is 2^96, which is valid but ignored, because the opening price is derived from the 2500 IMD cap.

Not covered: I didn't run the fork tests, so the two real-LaunchFactory launches (80/10/10 split, buys and sells) are unchecked here. I also didn't check the deployer's calculation of the opening price from the 2500 IMD cap, which isn't in this repository. The two Aderyn notes (centralization risk and the large literal) are about intended design, not maths errors.

Deployment receipts, addresses, the PoolKey and the poolId are outside a review: nothing has been deployed.

Both snippet anchors now match the tree, the working tree has no tracked changes, and no scratch files were created. The review is complete.

Outcome: no defects found in the Economic Security, Invariant and Flow Gap area. The findings file at .imd-findings.json holds two info-level notes and 15 coverage rows, all nine listed entry points marked holds.

What I verified, beyond reading the code

• Offline suite: 98 passed, 0 failed, 2 skipped (the two that need an RPC). The in-repo admission copies differ from the pinned protected floor only in imports and environment-to-constant substitutions, with no assertion removed.
• Live Robinhood chain 4663: I ran the real-LaunchFactory fork rehearsal myself and it passed in both token orders. The hook came out with owner equal to the explicit $owner, poolManager() equal to the canonical manager, 80/10/10 allocation, one-shot bind against the live PoolManager's extsload, enable, and buy/sell commands 1 and 2.
• Dependencies in my area: IMD reports 18 decimals on chain, so the 0.05 ether threshold means 0.05 IMD. The factory's verified Sourcify source shows launch is deployer-only, the factory itself calls PoolManager.initialize, and fee collection is a zero-liquidity modify that reverts only if the hook takes fees. The hook has no remove-liquidity callbacks and no return-delta flags, so the collect cannot be blocked and swap accounting equals a hook-less pool.
• Manifest: schema keys only, three constructor entries in declaration order, permissions equal 0x2040, fee 12500, lowercase paired currency equal to the compiled IMD constant, notes 3,164 characters. The exported ABI matches a fresh forge inspect.

The two info notes

1. Relay-state griefing is reachable by anyone for roughly 0.00125 IMD per 10-second window via a dust sell. This is the SPEC's global first-eligible-wins cooldown, already recorded as accepted design, and I quantified it so the judge has numbers. No funds are at risk and no swap reverts.
2. Constructor argument list is [$poolManager, $owner, $factory], not the brief's literal [$owner, $factory]. SPEC item 1 in this commit, ADAPTATION.md, the launch reference and the live rehearsal all agree on the three-argument form, so I flagged it only so it is not mistaken for a manifest/constructor mismatch.

Not covered: I did not re-run the canonical-fork integration suite or the published admission-floor Python script against the external reference repository. The real-factory rehearsal and the in-repo admission reproduction already exercised the same paths on the live PoolManager, so I spent the budget there instead.

Review complete. The findings file is written and validated against the tree, the scratch tests are removed, and the working tree is clean apart from .imd-findings.json.

Outcome: no defect found in the assigned area. The corrected hook holds across the Execution Trace, Periphery and First Principles checks, and I reproduced every claim in the validation record that I could reach:

• Offline suite at this commit with the verifier's fuzz seed: 98 passed, 0 failed, 2 skipped, including the in-repo reproduction of the four protected admission floors in both token orders.
• Both real-LaunchFactory fork rehearsals against Robinhood Chain 4663 pass live. The real factory deploys the token and hook, initializes with sender == launchFactory, seeds 80/10/10, and the hook binds, enables and emits buy and sell commands 1 and 2 on the canonical PoolManager.
• The verified LaunchFactory source from Sourcify confirms the hook's trust assumption: launch() calls poolManager.initialize directly from the factory and uses raw CREATE2, so the sender check is exact and the hook address cannot be reused by another launch.
• Committed ABI files equal forge inspect on this build. Manifest constructor order, permissions, fee, lowercase pair address and notes length all check out. IMD on chain has 18 decimals, so the 0.05 threshold is in the intended unit.
• Two extra execution-trace scenarios behaved as specified: a buy-then-sell inside one unlock emits only the buy under the default cooldown and both legs with cooldown zero, and a transaction that reverts after the swap rolls back the command and timer.

Two informational findings were recorded, neither a spec violation:

1. beforeInitialize validates sender only, not the key. If IMD's deployer ever launched this hook with a pair currency other than IMD, the launch would succeed and bindPool would refuse that key forever, leaving relay 4 dead on a live pool. A one-line pairing check in beforeInitialize would turn that into a safe launch-time revert. I flagged the admission trade-off the judge should weigh: the pinned Hook floor builds its launch key from the verifier's pair-currency input.
2. VALIDATION.md and ADAPTATION.md still say the offline suite is 38 tests. The committed tree runs 100, and launch.json already says 98.

Static-analysis leads were checked and dismissed with reasons in the coverage record. All nine listed entry points are marked holds, with additional rows for beforeInitialize, the constructor and manifest, renounceOwnership, the factory fee-collect path, the accounting invariant and the static-analysis leads.

Review complete. The findings file is written and validated against the tree, and the working tree is clean apart from .imd-findings.json.

Outcome: no defects that block admission. All four specialist findings reproduced, all four stay at info, and nothing I found myself rises above them.

What I verified on this commit (41e3e33):

• Offline suite with the verifier's fuzz seed: 98 passed, 0 failed, 2 skipped (the two need RH_RPC).
• Real-LaunchFactory fork rehearsal on Robinhood Chain 4663 over the network: 2 passed, both token orders, with 80/10/10, bind, enable, buy and sell commands.
• Canonical-fork integration suite on chain 4663: 8 passed.
• Committed ABIs equal forge inspect output for both contracts.
• Manifest: schema keys only, three constructor entries in declaration order, permissions match getHookPermissions, lowercase IMD pair, fee 12500, notes under 4,000 characters.
• Protected floors: the pinned files cannot compile verbatim against the vendored libraries (newer v4-core layout, missing forge-std overload), so I checked the in-repo port in test/admission line by line against the pinned sources. It passes in both token orders and with an alternate manager address.

Findings kept, all info:

1. Relay griefing via global cooldown. A 0.05 IMD sell every 10 seconds holds relay 4 OFF while buys in the window are skipped. Merged from audit_economics and the earlier accepted-design note. It is exactly what SPEC items 5 and 6 require and is owner-tunable. Reproduced in a scratch test and the existing cooldown test.
2. beforeInitialize ignores the PoolKey. The factory could open a non-IMD pool on the hook that bindPool can never accept, leaving relay 4 dead for that launch. Reproduced in a scratch test. The manifest pairs with IMD and the real-factory rehearsal passes, so this is a hardening option, not a spec deviation.
3. Stale test count in VALIDATION.md and ADAPTATION.md (38 versus 98 passed). Documentation only.
4. Three constructor entries versus the brief's literal two. This is the authorized, documented compatibility fix the reference requires, and the real factory deploys it correctly. Recorded so it is not misread as a mismatch.

Dropped leads: Slither's unused-return on getSlot0 is a false positive since the price is used, and the timestamp and centralization notices describe intended design.

Coverage: all 9 listed entry points hold, plus rows for beforeInitialize, the constructor, renounceOwnership, the manifest and the protected floors. Deployment receipts, addresses, PoolKey and poolId are not deliverable by any worker, since the deployer launches after admission; the repository states this correctly.