Implemented NUKE, NUKEHook, launch manifest, vendored dependencies, deployment helper, and documentation.

Verified:

• forge build and forge fmt --check pass.
• 66 local tests pass, including 8,192 invariant calls.
• Both mainnet-fork tests pass at block 26,150,493.

The findings file parses as valid JSON, both anchor lines match the source exactly, scratch tests are removed, and the working tree has no stray files (.imd-findings.json is ignored by the harness's exclude rules, as intended).

Review summary

Scope covered. Control flow of NUKEHook under the Pashov Execution Trace, Periphery and First Principles guides: every state-changing entry point, the beforeSwap view, the oracle arithmetic, the delta accounting against the vendored v4-core Hooks.afterSwap and PoolManager.swap order, the standalone/busy guards, the CREATE2 miner, and the test routers. The existing 88-test suite passes locally and includes an independent oracle model and fail-on-revert invariants, so the core accounting holds.

Findings written to .imd-findings.json (two, each with a reproduced call sequence and observed numbers):

1. Medium. The batch price limit is 3% beyond the previous completed hour's mean, which can be 7199 s old and never moves during the current hour. After an organic 11% intra-hour drop, the limit sat 15.6% above spot, the batch paid an average 11% over market, and a same-block sandwicher around executeBatch() netted about 1,182 IMD on a 51.7k IMD batch after fees. A spec-compatible fix is to bound the limit by min(reference, spot) or use a trailing window ending now.
2. Low. A front-runner can park spot one wei inside the limit so the batch fills 2 wei, buys nothing, and still consumes the hourly cooldown. It costs the griefer roughly 662 IMD per hour at test liquidity and delays buybacks indefinitely without loss of funds.

Coverage record. All eight listed entry points have rows (seven holds, executeBatch → finding 1), plus rows for beforeSwap, the zero-delta invariant, oracle bounds, permission/manifest agreement, and the periphery helpers. Nothing was left unreached.

Not reached or out of scope. Live IMD token behaviour on mainnet (fork tests need an RPC this environment lacks), and the launch factory's seeding transaction, which is not in this repository.

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

What I found

The hook's mechanics are sound. Fee accounting, claim settlement, access control, cooldown, budget cap, the no-hook-fee on batch swaps and the IMD token assumptions all hold. I verified IMD on mainnet through Sourcify: it is a plain OpenZeppelin ERC-20 wrapped as a LayerZero OFT with no transfer tax, pause or blocklist. The two defects are both economic and both in executeBatch.

• Medium: stale reference makes the buyback sandwichable. The price limit is 3% beyond the mean tick of the last completed hour, which can be up to two hours old, and spot is only consulted to decide whether to no-op. After a decline the limit sits far above market. In a local reproduction the price fell to 0.595, the reference stayed at 1.0, and the batch paid an average of 0.707, about 19% above spot. An attacker who front-ran the batch with a 40k IMD buy and sold afterwards netted 3,004 IMD in one transaction. The same sandwich loses 1,737 IMD when the reference is fresh, so the fees only protect the design while the reference tracks spot. Suggested fix is to also bound the limit by spot, or use a trailing hour rather than the last completed window.

• Low: a dust fill consumes the hourly cooldown. Spot exactly at the limit returns zero without touching lastBatch, but one unit short of the limit the swap proceeds, fills 2 wei, and locks the hour. Anyone can park spot there, call the batch, and sell back. It costs the griefer roughly 4.4% of the volume moved, so this is costed griefing rather than theft.

Coverage

All eight entry points have rows. Seven hold, executeBatch carries both findings. Three invariant rows cover fee proportionality, the budget and cooldown rules, and same-block oracle resistance. Neither finding is critical or high, so no proof test files were attached. Fork runs against live mainnet state were not rerun here; the local reproductions use the project's own fixture in both currency orderings and give identical numbers.

The review is complete. The working tree is untouched apart from the two review artifacts, which git ignores by design.

Outcome. The hook's fee, settlement and oracle arithmetic is sound in every place the Math Precision, Boundary and Numerical Gap guides point to, except one boundary seam that lets anyone stall the buyback for free. Findings are in .imd-findings.json with a 13-row coverage record covering all eight listed entry points plus five extra rows for views and invariants.

Finding 1, medium, with proof. The hourly tick oracle counts time spent at any tick, including ticks reached through a zero-liquidity region. A one-wei exact-input sell with the price limit at the extreme fills nothing, pays no LP or hook fee, needs no allowance, and still parks the pool tick at the minimum or maximum. The launch pool is seeded with NUKE only, so that empty region sits directly beside the opening price. One block at the extreme tick per hour shifts the completed window's mean by roughly 2957 ticks, about 25 percent in price, against a 3 percent limit. Every subsequent call to executeBatch returns zero while IMD keeps accruing. Blocking needs only about 1.2 seconds per hour at the extreme tick. The scratch proof at test/scratch/OracleZeroLiquidity.t.sol fails on the current code for both currency orderings and includes a passing control run that spends 250 IMD without the push. The suggested minimal fix is to keep the previous tick in _observe when pool liquidity is zero.

Finding 2, info. Hook fees truncate, so fills under 100 wei pay nothing. Bounded at 1 wei per swap and non-compounding. Reported only because the guide asks for fee rounding direction to be checked.

Verified as holding. The sqrt(1.03) constant is an exact floor. Both limit roundings and the clamps are conservative. The int64 integral, int24 mean cast, int256-minimum handling in beforeSwap, int128 fee fit, 25 percent budget cap, and claim-versus-wallet settlement split all stay inside their bounds. Hook deltas net to zero in every unlock path. All 88 existing tests pass.

Static-analysis leads. The weak-PRNG, divide-before-multiply, unsafe-cast and strict-equality lines are false positives on bounded or intentional arithmetic. None was reported.

Not reached. Live mainnet IMD token behaviour and the real factory's position range were not verifiable offline. If the factory seeds full-range two-sided liquidity, the precondition for finding 1 weakens, but the repo's own fresh-pool tests model the one-sided seed.

Review complete. The findings file is written at .imd-findings.json and nothing tracked in the tree was modified.

Result: one medium finding, no access-control bypasses.

The permission model is tight. Every callback and unlockCallback checks the PoolManager, beforeInitialize pins the single NUKE/IMD key and runs once, the standalone guard keeps sweep and executeBatch out of foreign unlocks, hook claims can't be moved by third parties, and the fee return delta nets to zero on the hook in all four swap modes and both currency orderings. I also probed live IMD on mainnet: it is a LayerZero OFT with standard transfers and no pause or blocklist selectors, so the batch's settlement path has no token-side trust gap.

Finding 1 (medium, trust gap: access × economics), src/NUKEHook.sol:204. executeBatch() is permissionless and its only slippage guard is 3% beyond the mean tick of the previous completed hour, with no bound relative to the current spot. When spot has fallen below that stale reference, any caller can buy, trigger the batch, and sell back into the price the batch created.

The proof at test/scratch/StaleReferenceSandwich.t.sol is self-contained, fails on the current code, and passes on a scratch copy where the limit is also capped at 3% beyond spot (attacker then loses 460 IMD). Suggested fix keeps the spec's time-weighted reference and 300 bps bound and only adds the spot cap.

Coverage: all eight listed entry points have rows (seven holds, executeBatch → finding 1), plus four invariant rows. The one residual I did not promote is the documented ability to hold a ~4% reference deviation inside the 4.5% round-trip fee band, for which I found no profitable reproduction.