Implemented RISK, RISKHook, launch.json, vendored dependencies, deployment helper, tests, and documentation.

Validation passed:

• forge build
• forge test: 28 passed; fork suite skips offline
• forge fmt --check
• Mainnet fork at block 26151185: passed
• 8,192 invariant actions: zero reverts

Deployment parameters and operational responsibilities are documented in README.md. No transactions were broadcast.

Added adversarial unit, fuzz, invariant, and mainnet-fork tests under test/.

Validation:

• forge build passed.
• Offline: 52 passed; 2 fork suites skipped.
• Mainnet block 26,151,212: all 10 fork tests passed.
• New invariant: 16,384 randomized actions, no unexpected reverts.

No reproducible implementation defects found.

Updated only launch.json, clarifying deployment, fees, buybacks, and price provenance.

Validated schema constraints, constructor arguments, and permissions against the implementation.

forge build passed. forge test: 52 passed, 0 failed, 2 skipped.

Review complete. The findings file is written and validated against the tree.

Outcome

No defect in the Access Control, Trust Gap or Asymmetry areas. The file .imd-findings.json holds one informational entry and a 13-row coverage record answering all 9 listed entry points plus four invariants.

What I checked, with results

• Caller guards. Every callback and unlockCallback requires the PoolManager. The unlock callback additionally requires the hook's own operating flag, so its decoded bool can never come from an outsider. A nested unlock from a third party's callback reverts with AlreadyUnlocked, and the suite already tests this.
• Initialization. The hook pins the one RISK/IMD key with fee 12500 and spacing 60, so no second pool can ever route through it and corrupt the TWAP or mint foreign-currency claims. The sender and opening price are unchecked. Under the stated atomic deploy-and-initialize factory flow this is unreachable, so it is recorded as info with a reproduction showing an outsider can open the pool first only if the two steps are split.
• Fee symmetry. The afterSwap claim mint is matched exactly by the returned unspecified delta in all four swap modes and both currency orderings. The hook's own batch swap is exempt through v4's noSelfCall rather than the dead sender == this check.
• Permissionless executeBatch economics. Using scratch tests on a 1e24-liquidity pool I measured the two seams the Trust Gap guide targets. A same-block push past the price band to force a zero fill costs the attacker about 876 IMD to delay a 225 IMD budget. A buy, batch, sell sandwich loses 20 IMD at spot equal to reference and 37 IMD after a 30% dump. The single price guard is not extractable by the caller.
• Claims. Nobody can burn or transfer the hook's ERC-6909 claims; outsiders can only donate to the burn or buyback.
• Manifest. Permission bits, constructor argument order, pool fields and the fixed IMD address all agree with the code.

Static analysis leads were all traced and dropped: the weak-PRNG line is a floor-division remainder check, the reentrancy lines only reach the PoolManager and the plain OZ RISK token, and the int24 cast is a bounded tick mean.

Not reached. The live mainnet IMD token and the real factory's seeding could not be exercised offline. The hook never transfers IMD itself, so IMD transfer quirks cannot block sweep or batch, but the operator's fork rehearsal still owes that run.

The review is complete. The findings file is written, snippets match the source lines, and the scratch tests are removed so the tree is clean apart from .imd-findings.json (which git ignores).

Outcome: no critical or high defects in the math. The hook's arithmetic holds up under the Math Precision, Boundary and Numerical Gap checklists. I recorded two low findings and one informational note.

What I verified as sound

• The 1% fee is computed from the actual int128 fill on the unspecified side, with the sign conventions matching v4's Hooks.afterSwap in all four swap modes and both currency orderings. It is widened before negation, so int128.min is safe, and the int128 return cannot overflow.
• The UnrepresentableFee guard is overflow-safe for type(int256).min and only rejects the nominal domain the spec explicitly allows.
• The limit multipliers are correct to 18 digits and rounded toward a tighter band. The product fits uint256 with room to spare, and the clamps plus early-return conditions mirror v4's strict price-limit checks exactly, so the batch has no revert path.
• The time-weighted mean floors toward negative infinity, stays inside the tick range, and the view matches what _observe commits. The slither "weak PRNG" and reentrancy leads are false positives.
• Dust behaviour is benign: sub-100-wei fills pay no fee (documented), and a 98-wei batch budget still bought 95 wei of RISK.

Findings

1. Low. The 300 bps band is defined on the sorted price ratio. When IMD happens to sort as currency0 (RISK minted above 0xD34a..., roughly 18% of addresses), the IMD price of RISK may rise 309.3 bps instead of 300. Reproduced in the default fixture: the sorted ratio hit 0.970000000000000001 and the RISK price was 1.0309x the reference.
2. Low. Observation periods have no upper bound, so after a quiet stretch the reference can be days old. Reproduced: two idle days, then a large sell, and one second later the batch was authorised to pay 0.936 IMD per RISK against a 0.552 market, 69.5% above spot. The hook itself still bought near spot, so the exposure is a widened sandwich window, not direct loss.
3. Info. The sender == address(this) branch in afterSwap is unreachable because v4 skips a hook's own callbacks. The TWAP depends on the explicit slot0 re-read after the batch swap, which is present and tested.

Coverage. All nine entry points have a row, plus four invariant and lead rows. No proof files were attached since nothing reached high severity.

The findings file is in place and excluded from git by the harness's own .git/info/exclude, so no tracked file changed. The review is complete.

Outcome

No loss-of-funds or breakage defect found in the assigned area. The report at .imd-findings.json carries one informational finding and a 14-row coverage record. All 9 entry points are answered: 8 hold, executeBatch is linked to the informational note, and only the offline-skipped mainnet fork suites are marked unreached.

What I traced (Execution Trace, Periphery, First Principles):

• Fee path. The unspecified-side selection in afterSwap matches the PoolManager's own delta positioning in all four swap modes. The claim mint plus the returned delta net the hook's balance to zero, and the swapper pays the fee. The self-swap exemption is enforced by the manager, not the hook.
• Batch path. Limit sign, rounding and clamping are correct for both currency orderings. The zero-fill guard prevents the manager's price-limit revert, spent can never exceed pending, and every suite ends with zero nonzero deltas. Probes at the minimum and maximum opening price, after a century of inactivity, and with the period completing inside the batch all behaved correctly.
• Periphery. All 86 vendored files are plain blobs, no submodules. I fetched upstream v4-core at the pinned commit and OpenZeppelin v5.1.0: the only differences are forge-fmt whitespace in ten v4-core files. IMD on mainnet is a LayerZero OFT ERC-20 with 18 decimals and no pause or blocklist selectors, and the hook never transfers it. The sqrt constants round in the conservative direction. The manifest satisfies every schema constraint and matches the constructor and permission bits.

The one finding (info). The batch's 300 bps guard is anchored to a reference that can be up to two hours stale. In a measured scenario the guard sat 574 bps in sqrt-price terms from the pre-batch spot. This matches the brief and README, and both a sandwich and a cooldown-wasting grief were unprofitable in the test pool, so no loss is claimed. It is there for the author to decide whether to use the trailing window that referencePrice already computes once a period matures.

Not covered. The mainnet fork rehearsal at block 26151185 was not re-run. Scratch probes live under test/scratch, which is ignored and will not be kept.

Review complete. The findings file is written and validated.

Outcome. Two defects in the buyback economics, none in fee collection or claim accounting. Written to .imd-findings.json with 12 coverage rows (all 9 entry points plus three invariants).

Finding 1, medium, with proof. The batch's only slippage guard is 300 bps beyond the hook's TWAP reference, and the limit is never tightened against the pre-batch spot. Whenever spot has drifted from the lagging reference, which a late-hour sell-off produces naturally, the hook may move the price from spot all the way to the reference bound. Since executeBatch() is permissionless and its timing is public, a searcher buys RISK, calls the batch, and sells back in one block. With a 1e22 pool and a budget of about 4.4% of depth, the attacker nets 100.9 IMD of the 443.5 IMD budget and the burn shrinks 31%. The same sandwich is unprofitable when spot equals the reference, because the 4.5% round-trip fee burden exceeds the 3% cap. A spot-anchored cap (anchor to the tighter of reference and spot) makes it unprofitable in every tested scenario, verified on a scratch copy. Proof test fails on the current code at test/scratch/RISKHookSandwichProof.t.sol.

Finding 2, low. A zero-fill batch still consumes the hourly cooldown. Pushing spot past the limit, calling executeBatch(), and selling back costs about 0.07% of pool depth per hour (702 IMD against 1e24 liquidity) and defers the buyback indefinitely.

Covered and holding. Fee direction logic for all four swap modes, proportionality on partial fills, ERC-6909 claim accounting netting to zero, sweep and batch settlement, TWAP time-weighting and view/write consistency, sqrt constants and rounding direction, and the zero-fill guard matching v4's revert condition. Both stateful invariant suites re-ran clean.

Not reached. No mainnet fork run (no network), so the real IMD token's transfer behaviour and the live PoolManager remain unverified here. The factory's actual liquidity range, which sets how large a budget is relative to depth and therefore how soon finding 1 becomes exploitable, is outside this repository.

The findings file is in place at the repository root, excluded from git by the harness's own rule, and no tracked file changed. The review is complete.

Outcome. The RISKHook code is sound on access control, delta accounting and fee proportionality. One medium finding survives, built from three specialist reports that share a root cause. Two specialist reports are kept as informational notes, and two are dropped as non-defects.

Finding 1, medium. The batch's only slippage guard is anchored to a reference that can lag spot by hours, or by days in a quiet pool, and is never tightened against the pre-batch spot. I reproduced three consequences against the real PoolManager:

• Thin pool, spot 40% below the reference: a one-block sandwich around executeBatch nets the attacker 21.9% of the batch budget, and the burn shrinks by 30%.
• Deep pool, budget at 4.45% of depth, spot 28% below reference: the attacker takes 11.2% of the budget.
• Two idle days followed by a sell: the hook is authorised to pay up to 1.695 times the market price for one full hour.

The sandwich is a loss for the attacker whenever spot equals the reference, so the 4.5% fee burden works as designed in the normal case. The exposure arises naturally after a rally, when zero-fill batches let pending accumulate before a sharp drop. The suggested fix keeps M1 intact: anchor the band to the tighter of reference and spot, and cap how long an idle tick can be weighted.

Informational notes. The 300 bps band measures 309 bps in IMD-per-RISK terms when IMD sorts as currency0, which the README documents as a sorted-ratio bound. A zero-fill batch still consumes the hourly cooldown, which is documented and costs a griefer about 0.07% of depth per hour for no gain.

Dropped. The sender-agnostic beforeInitialize is explicitly permitted by the launch rules, and the unreachable self-call branch in afterSwap is dead code with no effect.

Coverage. All nine entry points are answered, seven hold and two carry finding 1, plus four invariant and manifest rows. The existing suite passes with 52 tests and 2 offline fork skips. The manifest validates against the schema, and all static-analysis leads traced to non-issues.

Updated the partial-buyback test to verify both reference and spot price limits and require the fill to reach the tighter bound.

Validation:

• forge build passed.
• Offline suite: 66 passed, 2 fork skips.
• Mainnet fork: 10 passed at block 26,151,445.
• Invariants: 24,576 calls, zero reverts.

Only files under test/ changed.

Wrote .imd-findings.json: no substantiated defects, all nine entry points covered.

The prior medium finding is fixed. Both advisories reproduce but remain documented design choices consistent with the brief.

Validation: 66 offline tests passed; 10 mainnet-fork tests passed at block 26,151,445. Build and formatting checks passed.