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.

Added tests for failure rollback, claim settlement, partial fills, first-buy fee collection, and stateful balance/oracle invariants. All changes are under test/.

Validation:

• forge build passed.
• Offline suite: 88 passed, 0 failed; fork suite skipped.
• Mainnet fork: 3 passed at block 26,150,564.
• New invariants exercised 49,152 random calls without unexpected reverts.

No implementation defect was reproduced.

launch.json is complete and matches the hook as built. Only that file changed.

What the manifest declares

• kind is the first field, set to univ4_hook.
• Token: contract NUKE, name On-Chain Oppenheimer, symbol NUKE, 18 decimals. The token takes no constructor arguments and mints the full 1e27 units to its deployer.
• Hook: contract NUKEHook, constructor args ["$poolManager", "$token"], matching the constructor's declaration order of (IPoolManager manager, address launchToken).
• Permissions: beforeInitialize, beforeSwap, afterSwap, afterSwapReturnDelta. These are exactly what getHookPermissions returns, and they encode to address bits 0x20c4, which the hook's constant and tests agree on.
• Pool: pairedCurrency 0xd34a99bc0f67ae1bbd63c660e6d0b0dd03e263b7, fee 12500, tickSpacing 60, initialPrice 79228162514264337593543950336.
• Notes now spell out that IMD is a compile-time constant in the hook, so it binds to a single PoolKey. They also describe what beforeInitialize accepts and rejects, the fee mechanics, the permissionless sweep and batch functions, and the views. Notes run about 2100 characters, under the 4000 cap.

Verification

• A schema-shaped check in Python confirmed field sets, patterns, the permissions enum and field order.
• forge build and forge test both passed: 88 tests passed, 0 failed, 1 skipped. The skipped test is the mainnet-fork suite, which skips cleanly without an RPC URL.
• git status shows only launch.json modified.

Nothing is blocked. The hook needs no owner or factory address, so no placeholder beyond $poolManager and $token is required.

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.

The review is complete. The findings file is written at .imd-findings.json, and no tracked file was changed (the findings file and test/scratch/ are ignored by git).

Outcome. The seven specialist findings reduce to three reproducible defects plus one informational note. All were reproduced against the code in both currency orderings, and the three defects carry proof tests that fail on the current code. My own pass over the hook found nothing the specialists missed: callback access control, pool binding, permission bits, delta netting, claim settlement, cooldown and lock guards, and the manifest all hold.

Findings kept

1. Medium, stale reference lets anyone sandwich the buyback. Merged from economics, permissions and flow. The limit is 3% beyond the previous completed hour's mean tick, which never looks at current spot. After a 60k NUKE sell drops spot to 0.89, an attacker buys, calls executeBatch, and sells back for a profit of 1,132 IMD after all fees. The verified control with a fresh reference loses 1,309 IMD. The specialist proof fails here as stated and is attached.
2. Medium, free zero-liquidity tick push blocks every buyback. From math. On the launch-shaped NUKE-only pool, a 1-wei exact-input sell with the extreme price limit fills nothing, needs no tokens, and parks the tick at MIN_TICK. One 12-second block per hour drags the mean to -2958, so the limit sits below spot and the batch no-ops all hour. My proof fails in both orderings, with the control passing.
3. Low, a 2-wei fill consumes the hourly cooldown. Merged from economics and flow. Parking spot one sqrt-price unit inside the limit makes the batch spend 2 wei and set lastBatch, costing the griefer about 662 IMD per hour. My proof fails in both orderings.
4. Info, fee rounds down below 100 wei. Documented behaviour, bounded at 1 wei per swap, kept for completeness without a proof.

Dropped or downgraded. Nothing was dropped; the four specialists' reports had the same two root causes for five of their findings. Static-analysis leads (weak PRNG, divide-before-multiply, strict equality, reentrancy, unsafe cast) were traced and are false positives on this code.

Coverage. All 8 listed entry points are answered, plus 4 invariant and manifest rows. executeBatch() is the only entry point marked as a finding. Fork tests against live mainnet state remain owed since this environment has no network; the suite skips them cleanly.

Fixed both medium findings and the zero-output cooldown defect. Intentional fee rounding remains unchanged. All four findings are answered in .imd-responses.json.

forge build, forge test, and forge fmt --check pass. Both mainnet fork tests pass at block 26,150,958.

Updated the oracle test model and added six regression cases covering empty liquidity, zero-budget batches, and zero-output retries.

Verified:

• forge build passes.
• 114 offline tests pass.
• All 3 mainnet fork tests pass at block 26,151,012.

Only files under test/ changed.

Review complete. The findings file is at .imd-findings.json with two findings and a full coverage record. Only that file and my scratch tests under test/scratch/ were touched.

Settled from the previous round

• Stale-reference sandwich (medium, b513c7f7): fixed. Both pinned proofs now pass on the revised code. The spot-tightened limit caps the batch at 3% above execution-time spot, and the attacker's round trip loses 460 IMD after fees. I also checked that the dust-liquidity trick below cannot reopen it: a pushed-high spot only produces a no-op, never an overpaying fill.
• Zero-liquidity tick push (medium, 1b77976d): fix does not hold. The literal 1-wei push through empty liquidity is blocked, but the guard is getLiquidity != 0. A position with liquidity 1e18 at the extreme usable ticks inside the empty region costs exactly 1 wei of IMD, and a 1-wei NUKE sell stopping inside it lands the hook on tick -887161 with nonzero liquidity. Twelve seconds there poisons the hourly reference to the same 0.8625×2^96 value as before, and every batch no-ops for the next hour. Reported as finding 1 (medium) with a self-contained proof that fails in both currency orderings and whose control passes. The same trick also lets a batch "buy" 0.0275 NUKE of the attacker's own tokens for 2 wei and commit the cooldown.
• Dust fill consumes cooldown (low, 051c012b): only the zero-output case is fixed. Parking spot 131072 sqrt-price units inside the limit yields spent 3 wei, burned 1 wei, and the full hour consumed, at the same 662 IMD griefing cost. The author documented this as accepted. Reported as finding 2 (low) so the record is accurate; it is not blocking.
• Fee rounds down (info): author's dispute accepted. Bounded below 1 wei per swap, intentional, documented.

Fresh read of the changed lines

The try/catch on unlock correctly re-raises anything other than the hook's own EmptyBatch, resets the operation flag, and leaves busy consistent. The oracle casts stay within int24 and int64 bounds. The slither and aderyn leads at the oracle and batch functions are false positives for this code (floor-rounding modulo, intentional interval floor, guarded reentrancy). Full suite: 114 passed, 1 fork test skipped.

Coverage: all 8 entry points answered (5 hold, 3 carry a finding), plus 4 rows settling the prior findings.

The findings file is in place at the repository root (excluded from git by the harness's own .git/info/exclude, which is how it collects it), and the scratch directory is empty. The work is complete.

Summary

What changed since my last round. The implementer replaced the oracle's observation rule: instead of the raw spot tick, the hook now records the price at which 0.25% of the manager's NUKE is purchasable (a 16-step walk over initialized ticks), carries the previous observation when nothing of that size is for sale, clamps each observation to 2000 ticks below the last hour's mean, and only commits the hourly batch slot on fills of at least 1% of the budget. Twelve of my previous-round tests encoded the old rule and failed.

What I did (only test/ touched):

• test/helpers/ClaimActor.sol: added a revert-based ask probe that runs a real exact-output buy of the depth through the PoolManager and rolls it back, plus recording of the pre-settlement manager state the hook saw in afterSwap.
• test/StatefulAccounting.t.sol: the handler's oracle model now expects observations from the swap engine's landing price (never the hook's walk), reproduces the band clamp from its own hourly mean, models both observations of a funded batch, checks that nothing but swaps and funded batches move the observed tick, compares askPrice() with the engine at every step, and encodes the 1% floor rule for lastBatch. New actions: unlimited market orders and extra positions across bitmap word boundaries. Two new deterministic regressions (band clamp on sales only, shaped liquidity).
• test/SettlementEdges.t.sol: the reverted-settlement test now checks the observed tick rather than the spot tick.
• test/README.md: documents the model, its two deliberate tolerances, and gas measurements.

Results. forge build succeeds. forge test offline: 136 passed, 0 failed, 1 skipped (the fork test, which skips without an RPC and was not rerun this round). Both stateful campaigns ran 256 × 96 calls with zero reverts under the default seed and five others.

Findings reported in .imd-findings.json (none critical or high, so no proof files):

• Low: fills below 1% of the budget leave the interval open, so executeBatch can spend repeatedly within one hour when someone dips the price between calls. Bounded per call and price-capped, but a deviation from the "at most once every 3600 seconds" rule; the suite asserts the implemented behaviour because it is the accepted design.
• Info: the 16-step walk cap blinds the observation when 16 dust ticks sit between spot and real liquidity (measured: ~99k gas for the walk versus ~29k normally).
• Info: at the exact-amount segment edge the walk and the engine land on different prices, several ticks apart only with wei-scale liquidity.

Review complete. The findings file is written and no tracked file was changed.

Round-1 findings, settled

• Dust-liquidity oracle block (medium, ea4a4594): fixed. I re-ran my exact reproduction in both orderings. The 1e18 dust position at the extreme ticks plus the 1-wei sell no longer moves the observed tick, the reference stays at the real tick, and executeBatch spends the full 250e18 and commits. The liquidity-1 variant no longer tightens the limit or consumes the cooldown.
• Dust-fill cooldown (low, 578b57a9): fixed. The 131072-unit park makes the batch spend 3 wei and burn 1 wei, but lastBatch stays unchanged and the real batch then runs in the same hour.

Specialist findings

• The stale-reference sandwich (three specialists) is settled by the ask-tightened limit. The attached proof now passes with the attacker down 392 IMD, and my own probe shows a batch after a 40% intra-hour fall moves the sqrt price by only 1.6%.
• The dust-fill and zero-liquidity-oracle findings are the ones above, fixed. The fee-rounding note is documented behavior, not a defect.

One new low finding, with proof

The residual the README describes under "Cost of pushing the reference down" is cheaper than stated. Parking the spot in the empty region first, then adding a NUKE-only position just above it, pays no LP or hook fee, yet the position is adopted as the hour's observation. Held for the hour and withdrawn before the batch, it blocks the next hour's buyback. Cost is capital at risk (about 2.25M NUKE at launch scale, exposed at a 3.4% discount) plus front-running every executeBatch, so no funds are lost. The self-contained proof under test/scratch fails on the current code in both orderings and is embedded in the findings file.

Coverage answers all eight entry points plus the manifest and the no-spend-in-callback invariant. Only executeBatch carries a finding.