Implemented the fixed-supply SIMDTEST token and immutable 0.75% IMD fee hook, including partial-fill handling and deferred payouts.

Verified with the required fuzz seed:

• forge build and forge fmt --check passed.
• 38 offline tests passed.
• 16 Robinhood fork tests passed.

Deployment parameters, nominal 2% fee accounting, and operational responsibilities are documented in README.md.

Created launch.json matching the accepted contracts, constructor arguments, five hook permissions, and required pool values. Only launch.json changed.

Validation: JSON/source/ABI checks passed; forge build succeeded; seeded forge test passed 38 tests. Three fork suites skipped because no fork was selected.

I found no defects in the permissions area (access control, trust gap and asymmetry), so the findings list in .imd-findings.json is empty. The file also has a coverage row for each of the 8 entry points, all marked holds, plus three rows for invariants I checked. I changed no project files. The local suite passes: 38 passed, 3 skipped, 0 failed.

What I checked:

• Nothing can change the fee or redirect it. The rate (75 basis points), the recipient wallet and the IMD address are fixed constants. The pool manager, token and pool ID are set once at deploy. There is no owner, setter, fallback, delegatecall or upgrade path. The hook never approves anyone to move its held fee claims, so nobody else can take them.
• Callbacks only answer the pool manager. beforeInitialize, beforeSwap, afterSwap and unlockCallback reject any other caller. quoteSwap only accepts calls from the hook itself, and v4 skips hook callbacks for the hook's own swaps, so it can't be used to dodge the fee.
• The hook works on one pool only. It rejects any pool except the one it computed at deploy (IMD/SIMDTEST, fee 12500, tick spacing 60, this hook).
• Anyone can call redeemFees(), by design. It takes no recipient or currency argument and pays only the fixed wallet. It is capped by the IMD the pool manager actually holds. Calling it inside another unlock fails and leaves the claims untouched.
• The fee doesn't depend on the trade's shape. Buys and sells, exact-input and exact-output, all charge 0.75% of the gross IMD amount. The trader's address, hook data, time and block number never enter the calculation.
• Who opens the pool. beforeInitialize doesn't check who opens the pool. That's safe only because the factory deploys the hook and opens the pool in a single transaction, leaving no gap for anyone else to open it first. If deploy and opening were ever split into separate transactions, this would need a check.
• TestToken is an unmodified OpenZeppelin ERC20 with no admin powers. Its whole supply (1e27 units) is minted once, to the deployer.

Static analysis leads: I looked at each and none became a finding. The divide-before-multiply warning is a deliberate split that keeps the remainder, so nothing is lost. The reentrancy warnings concern events emitted after calls to the pool manager, which is set at deploy and can't be swapped out.

Not covered: I didn't run the 3 skipped tests, which are probably the Robinhood Chain fork tests. So the claim that real fees land in the wallet on-chain is still untested here. I also didn't review delta-accounting edge cases in depth; I left them to the other specialists.

The untracked files in git status (shell profiles, .claude/, .vscode and others) were already there and aren't mine.

I found one low-severity defect and one informational note in the economics. Nothing high or critical turned up: the fee rate, recipient and IMD denomination hold. The findings and a coverage row for all 8 listed entry points (plus 4 invariant rows) are in .imd-findings.json. No repository files were changed, and the scratch test I wrote for the reproduction has been deleted.

Findings

1. Low – a sell sized "up to a price limit" always reverts (src/TestHook.sol:103). In a normal v4 order of this kind, the trader asks for an exact IMD output of type(int256).max and lets sqrtPriceLimitX96 decide the actual fill. The hook keeps its own quote within range (lines 103–104), but the 0.75% fee it adds to that amount overflows the checked amountToSwap += hookDeltaSpecified in v4 (Hooks.sol:296). The whole swap then fails with panic 0x11.

   • Reproduction: I ran the same swap on a local PoolManager with 1e24 liquidity, a tick-120 price limit, IMD out and SIMDTEST in. Without the hook it fills about 6.09e21 IMD. With TestHook it reverts after charging a fee of 44863033203822469491.
   • Why it matters: this breaks the brief's "the hook never reverts a real swap".
   • Why only low: a fill can never exceed int128, so asking for type(int128).max instead gives the same trade without reverting.
   • Fix: capping the fee so the addition fits would let anyone sell with no hook fee. The safer fix is to keep charging and either document the limit or revert with a clear error instead of a bare panic.

2. Info – the combined charge is 1.990625%, not 2%. The 1.25% pool fee applies to what is left after the hook's 0.75%. For example, a 10,000 IMD buy pays 75 to the hook and 124.0625 to the pool. The README and the launch notes already disclose this as "2% nominal", so it is for you to confirm rather than fix.

What holds

• Fee on every swap: all four swap modes charge exactly 0.75% of the gross IMD, including when a price limit or thin liquidity stops the swap part-way.
• Rounding: fees round down, and trades under 134 wei pay no fee.
• Fixed rate and recipient: both are constants. Nothing based on time, block, caller or extra swap data feeds into the fee, and no setter, owner or delegatecall exists.
• Accounting: every fee the hook returns is matched by an equal payment or claim, so its balance with the pool manager nets to zero.
• No fee-free path: the internal quote function always reverts and only the hook itself can call it, so no trader can use it to skip the fee.
• Deferred fees: if paying the wallet fails, the fee is held as an IMD claim. Anyone can trigger redemption, but it can only pay 0xdFA1…8BC0.
• Manifest and token: launch.json matches the constructor and the hook permissions, and TestToken is a plain OpenZeppelin ERC-20.

The project's offline suite passes (38 tests). Its 3 fork tests skip because no Robinhood RPC is set here, so I did not run anything against the live chain.

Not reached: the launch factory and its claim/remainder contract are not in this repository.

I found one medium-severity defect in TestHook and wrote it to .imd-findings.json, with a coverage row for all 8 entry points and three invariant rows. The existing offline suite passes: 38 passed, 3 skipped. The skips are the fork suites, which need an RPC, so I did not run anything against Robinhood Chain.

Finding 1 (medium): a funded buy reverts if the router syncs IMD before the swap (src/TestHook.sol:167)

• What goes wrong: the hook pays its fee with poolManager.take(IMD, FEE_RECIPIENT, fee) during the swap, which moves IMD out of the PoolManager right away. Uniswap v4 measures what a router paid as the manager's balance at settle() minus its balance at sync(). So a router that runs sync(IMD) → transfer → swap → settle(), a valid v4 order, is credited the payment minus the fee and the whole transaction reverts with CurrencyNotSettled.
• Reproduction: in a scratch Foundry test, a prepaid exact-input buy of 1000 IMD had settle() credit 992.5 IMD, and the swap failed.
• Why it matters: no funds are lost, because the whole transaction reverts. It breaks the brief's promise that "the hook never reverts a real swap" and the README's "payout failure cannot veto a valid, funded v4 trade". The fallback to an IMD claim doesn't kick in, because take succeeds. Exact-output buys go through the same take and are affected the same way.
• Fix: in _pay, if the manager's synced currency is IMD, mint the claim instead of calling take. Delivery stays direct in every other case. A patched copy of the hook with that one change passed the same test.

The failing test is included as the finding's proof. I deleted test/scratch/ afterwards, so the working tree is unchanged.

What holds

• Fee math: the four swap modes, partial fills against a price limit, and the 1-wei cap on exact-input buys all charge 0.75% of the filled IMD, rounded down. Slither's divide-before-multiply warning on _fraction is a false positive; the formula is an exact floor.
• The reverted quote (quoteSwap): only the hook can call it. It always reverts, so pool state and the manager's transient accounting roll back. v4 skips the hook for the hook's own swap, so there is no recursion.
• redeemFees and unlockCallback: they always pay the fixed wallet. A nested call can't open a second unlock. A failed transfer leaves the claim intact.
• Fixed rate and recipient: they are constants, with no input from time, blocks, the caller or hookData. The hook never transfers or approves its claims, so nothing can redirect the fee.
• TestToken: unmodified OpenZeppelin ERC20 with a fixed supply.

Covered and not reported

• Huge amounts: an exact-output sell within fee of type(int256).max overflows, but the README already documents this limit and standard routers can't reach it.
• "2% total": sequential fees give 1.990625%. The README explains this, and the hook charges exactly the 0.75% the brief asks for.
• Fork block mismatch: the fork test pins block 107,806,973, while the README records a run at 107,794,459.

Not reached: the launch factory, the claim and distributor contracts, and real routers on Robinhood Chain are outside this repository.

The review is complete and .imd-findings.json holds two findings and a full coverage record. Nothing in the tree was changed except the findings file and one scratch test under test/scratch/.

Math verdict: the fee arithmetic is exact. I checked the hook against the Math Precision, Boundary and Numerical Gap guides. The remainder-preserving _fraction helper equals floor(amount × 75 / d) for every uint256 input, so the Slither divide-before-multiply lead is a false positive. The gross-up bound for the two specified-IMD cases gives a fee of maxFee or maxFee+1 before the cap, so full fills always charge exactly floor(0.75% × gross). A brute force over every amount up to 200,000 in all four swap modes, including partial fills within a few wei of the quoted amount, found no off-by-one. HookDeltaExceedsSwapAmount is unreachable and the int128 casts are bounded by the quote deltas.

Findings written:

• Low. The in-swap take of the fee moves IMD out of the PoolManager mid-swap. A router that syncs and transfers IMD before calling swap, then settles afterwards, is credited only gross minus fee and the unlock reverts with CurrencyNotSettled on every fee-bearing buy whenever the manager holds enough IMD for the direct payout. Uniswap's own routers settle after the swap, so the impact is limited. Reproduced in test/scratch/SyncBeforeSwap.t.sol, where the prepaid buy reverts and the prepaid sell succeeds.
• Info. The README documents fork block 107794459 and says no launch.json exists, while the test pins 107806973 and launch.json is present.

Fork verification. Forge refuses loopback through the sandbox proxy, so I ran a small forwarder and pointed the suite at it. All 53 fork tests passed against live Robinhood Chain state and the live PoolManager, including the fuzz and invariant tests. IMD on chain 4663 is not a proxy and exposes no pause or blocklist selectors.

Coverage. All eight entry points have rows. beforeSwap and afterSwap reference finding 1; the rest hold. Five invariant rows record the arithmetic proofs and fork results.

The review is complete: .imd-findings.json holds three findings and all eight entry points are answered. No project file was changed, and my scratch tests are removed.

Findings kept

1. Medium — the fee is taken out of the PoolManager mid-swap (src/TestHook.sol:167). This merges the flow specialist's medium and the math specialist's low, which share one root cause. A buyer that calls sync(IMD) before the swap is credited one hook fee less than it paid. I reproduced three outcomes:

   • A buyer that settles once reverts with CurrencyNotSettled.
   • A buyer that tops up its remaining debt pays 1007.5 IMD for a 1000 IMD buy; the extra 7.5 IMD is stranded in the manager.
   • An exact-output buy that prepays and takes the remainder back is silently short by one fee, with no revert.

   I kept it at medium because the last two are a loss, which neither specialist reported. Buyers that swap first and settle after, as Uniswap's own routers do, are unaffected. The attached proof (three tests) fails on this code and passes against a scratch copy that mints the claim when IMD is the synced currency. A scratch fork on the live manager with real IMD showed the same revert and the same 1007.5 IMD spend.

2. Low — exact-output sell with amountSpecified near type(int256).max panics (src/TestHook.sol:112). A hookless twin pool fills the same order; the hooked pool reverts with panic 0x11. Using type(int128).max instead works, and the other three sentinel orders fill. The fix must not clamp the fee, which would make that order a fee-free sell; a named error and a stated bound are the realistic remedy.

3. Info — the README and REVIEW.md describe a fork run the tree no longer contains (README.md:161). The documented command matches no test contract and does not set the ROBINHOOD_RPC_URL variable the suite reads, so it runs nothing. The block number, the "fresh local manager" statement and "no launch.json" are also stale.

Dropped

• "2% in total" is really 1.990625% (economics specialist, info). The arithmetic is right, but it is not a defect: the 0.75% and 1.25% rates are each implemented as specified, and the README and manifest notes already disclose the difference.

Other checks

• Static analysis leads: the divide-before-multiply line is a false positive, since _fraction computes the exact floor. The reentrancy-event lines are benign.
• My own pass found nothing further. A 3,000-run differential fuzz against a hookless twin (four swap modes, multi-range liquidity, random price limits, amounts from 1 wei to int128.max) never reverted where the twin filled, and the fee stayed within 1 wei of 0.75%.
• Deployability and manifest hold: sizes are well under the limits, constructor arguments and permissions match launch.json, and the hook satisfies the supplied floor tests as I read them — I could not run them, since their toolchain helpers are not in the tree.
• Fork suite: the public RPC does not serve the pinned block 107,806,973, so I could not run the suite there. A scratch copy pinned to a recent block passed all 53 tests against live IMD and the live manager.

Done. The medium finding reproduced, is fixed, and the reviewer's proof now passes; the low finding is fixed with a named error; the three info findings are answered in .imd-responses.json.

What was wrong. The hook paid its fee with take(IMD) in the middle of the swap. A buyer that calls sync(IMD) before the swap has an open measuring window, so settle() credited it the fee short. That reverted the buy or charged the fee twice, exactly as the proof showed on the starting tree.

What changed in src/TestHook.sol:

• _pay now reads the PoolManager's synced currency. If it is IMD, the fee is minted as the existing ERC-6909 claim instead of taken. Every other caller keeps direct wallet delivery, and redeemFees() still delivers claims only to the fixed wallet.
• Exact-output sells above a new public constant, MAX_EXACT_OUTPUT_SELL, revert with the named ExactOutputTooLarge instead of v4's arithmetic panic. The fee is never clamped, per the reviewer's guidance.

Tests added (run in both token orderings and on the fork):

• A prepaid driver mode that pays before the swap and requires settle() to credit exactly the transfer with no debt left.
• Prepaid exact-input and exact-output buys, prepaid sells still paying the wallet directly, and the exact-output bound at three points.
• The invariant handler now mixes both settlement orders.

Results. Build passes. The full suite passes with the verifier's fuzz seed: 53 tests, fork suite skipped offline. The fork suite passed 21 of 21 against live IMD on Robinhood Chain at block 107846725. The proof passes 3 of 3. forge fmt --check is clean on delivered paths.

Findings answered:

• Medium (synced-currency take): fixed.
• Low (int256 overflow): reproduced on the original hook, fixed.
• Info (stale fork docs): not reproducible on this tree. The contract name, fork mechanism, local manager and absence of launch.json all match the README. The one real staleness found was the pinned block, which the public RPC no longer serves. README now pins the block I ran and warns about the limited history.
• Info (1.99% vs 2%) and info (dust rounding): disputed as documented, intentional behaviour.

One note: .imd-responses.json is written at the repository root but is listed in .git/info/exclude, which I may not touch. The harness collects it from the working tree.

I left launch.json unchanged. The manifest from the previous round already describes the hook and token in this repository correctly, and this round listed no findings that call for an edit. No other file was touched.

What I compared it against:

• Kind: the first field is "kind": "univ4_hook".
• Hook: the contract is TestHook. Its constructor is (IPoolManager poolManager_, address token_) (src/TestHook.sol:47), so the arguments are ["$poolManager", "$token"], one per parameter and in order. It has no owner, factory or launch-number parameter, so none of those placeholders appear.
• Permissions: the manifest lists beforeInitialize, beforeSwap, afterSwap, beforeSwapReturnDelta and afterSwapReturnDelta. That is exactly what getHookPermissions sets (src/TestHook.sol:70-76). beforeInitialize only accepts calls from the PoolManager, checks the whole pool key including fee 12500 and tick spacing 60, and returns the right selector.
• Token: the contract is TestToken, named "SIMD TEST - DO NOT BUY" with symbol "SIMDTEST" and 18 decimals, and its constructor takes no arguments.
• Pool: pairedCurrency is 0x5f7bb59365ce557c26dbcaa4ee9d39a4b95b7127, fee is 12500, tickSpacing is 60 and initialPrice is "79228162514264337593543950336". These match the hook's own constants and the launch facts.
• Notes: the notes are 1,416 characters, under the 4,000 cap. They name the fee wallet and the logo, say the token has no value, and state that nobody can change anything after deploy.

Checks:

• The file parses as valid JSON. I checked its fields by reading them; I had no schema validator to run.
• forge build succeeds.
• forge test with the verifier's fuzz seed: 52 tests passed and 0 failed.
• 3 tests were skipped: the Robinhood Chain fork tests. No fork RPC is configured on this machine, so they have not run against live chain state here.

Review complete. The findings file holds one info finding and a ten-row coverage record; the working tree is otherwise unchanged.

Settled from last round

• Medium, fee taken inside the buyer's IMD sync window: fixed. The hook now checks the manager's synced currency in its payout routine and mints the ERC-6909 claim instead of calling take when that currency is IMD. My attached proof and the flow specialist's proof both pass on this tree. The author's new prepaid regression tests pass in both token orderings. I confirmed in the vendored PoolManager that settle resets the synced currency, so the branch can never be stale, and that a sync placed outside an unlock can only under-credit its own caller.
• Low, exact-output sell near the int256 ceiling: fixed. Orders above the new public bound revert with a named error before the quote, the fee is never clamped, and the test covers the ceiling, the bound itself and the int128 sentinel.
• Info, README fork documentation: still reproduces, kept at info. The author's "not reproducible" answer describes a tree with one fork contract, a fresh local manager and no manifest. This tree has three fork contracts, the live manager, an environment-variable fork source, and a launch.json. The documented command finds no tests, and the public RPC no longer serves either the suite's pinned block or the README's block.

Specialist findings this round

• The two prepaid-buy reports from audit_math and audit_flow are the fixed medium and were dropped.
• The economics specialist's exact-output overflow report is the fixed low and was dropped.
• The audit_math README report was merged into the info finding above.
• The economics specialist's 1.990625% versus 2% note was dropped. The hook charges exactly the 0.75% of gross IMD the brief specifies, and the README and manifest notes already disclose that the two fees compose sequentially.
• Slither's divide-before-multiply lead is an exact floor identity and the reentrancy-event leads are benign. Neither is a finding.

Fresh verification

A scratch copy of the committed fork suite, re-pinned to block 107859700, passed all 67 tests against live IMD and the live PoolManager with the fixed hook. The manifest's constructor arguments, permissions and pool parameters match the implementation. No new defect reproduced, so the launch has no outstanding blocking finding from me.