The deliverable is complete and committed on main as commit e2df7af.

What was built

• src/RnnnToken.sol: the rnnn.bid token, symbol RNNN, 18 decimals, one billion tokens minted once to the deployer. No owner, mint, pause, blocklist or fee.
• src/RnnnFeeHook.sol: the Uniswap v4 hook with one rule. On every swap it takes 1% of the swap's IMD amount and transfers it as IMD to the fixed recipient given in the constructor as an immutable. No owner, no setter, no pause, no other fee, no LP fee override. Constructor arguments are the PoolManager, the IMD address and the fee recipient.
• src/HookFlags.sol and test/mocks/MockERC20.sol: the helpers the protected floor suite imports.
• script/DeployRnnnFeeHook.s.sol: a manual CREATE2 deployment path with salt mining, separate from the launch factory.
• README.md: fee semantics per swap shape, deferred-claim behaviour, the Wizard configuration record, launch parameters, assumptions, and operational responsibilities.

Design decisions worth knowing

• IMD is taken on the specified side through beforeSwapReturnDelta for exact-input buys and exact-output sells, and on the unspecified side through afterSwapReturnDelta otherwise. All four swap shapes pay exactly 1%.
• When the PoolManager already holds IMD, the recipient is paid inside the swap. On the first buys into a pool seeded with RNNN only, the manager has no IMD yet, so the hook mints itself an ERC-6909 claim instead of reverting the trade. The next swap that finds IMD flushes it, and anyone can call redeemPendingFees at any time.
• beforeInitialize admits any pool containing IMD from any caller, so the launch factory can open the pool at fee 12500 and spacing 60.
• The brief's instruction to pay the fee in IMD rather than ETH is followed literally, and the README states this departure from the IMD default.

Verification

Dependencies are vendored as plain files under lib/ with no submodules. forge-std is taken from master rather than the v1.9.7 tag because the floor suite calls fail(string), which the tag lacks.

Open items for the launch

Slither and Mythril were not run because they are not available here. The hook enables beforeSwapReturnDelta, which the v4 security guide rates critical, so an independent adversarial review before release is recommended. Explorer verification and the fork rehearsal of the live pool belong to the network's deployer.

Created launch.json, matching the contracts, constructor arguments, permissions, and required pool settings. No other deliverable files changed.

forge build succeeded; all 42 tests passed.

Notes document existing limitations: deferred IMD payments and fees based on requested amounts for IMD-specified partial fills.

The review is complete and .imd-findings.json holds three findings plus ten coverage rows. No source files were changed; the only new files are the findings JSON and scratch tests under test/scratch/, which are not kept.

What I found

• Medium, with a proof test. When IMD is the specified currency, the hook fixes its fee in beforeSwap from the requested amount and never checks what the pool executed. A swap stopped early by the trader's price limit, or by missing liquidity, is charged 1% of the request rather than of the IMD that moved. In the proof, a 100,000 IMD request filled for about 30,000 IMD still paid 1,000 IMD to the recipient, over 3%. The launch pool is seeded with RNNN only, so every sell fills zero until someone buys. An exact-output sell there moves nothing and still takes 1% of the requested IMD from the seller, recorded as a pending claim for the recipient. The README documents partial fills as known, but the brief asks for 1% of the swap amount on every swap, so I reported it as a defect. The proof at test/scratch/PartialFillFee.t.sol fails three ways on the current code and accepts either reading of "the IMD side" after a fix.
• Low. The same root cause makes the int128 cast of the fee revert for sentinel-sized exact-input amounts above about 1.7e40. A hookless pool fills such a "swap up to this price" request to the limit. The hooked pool reverts. Fixing the first finding removes this path.
• Info. The fee rounds down, so swaps under 100 wei of IMD pay nothing. Dust, no compounding, documented in the README.

What holds

The unspecified-IMD paths, the take-or-mint accounting in _collect, the pending-claim flush, redemption, the unlock callback, and the token's fixed-supply arithmetic all trace cleanly. Slither's uninitialized-local and unused-return leads are intentional and harmless, so I did not report them.

Scope

Files read in full: src/RnnnFeeHook.sol (316 lines), src/RnnnToken.sol, src/HookFlags.sol, script/DeployRnnnFeeHook.s.sol, test/RnnnFeeHook.t.sol, test/utils/HookDeployer.sol, the protected hook suite, and the v4-core Hooks.beforeSwap / Hooks.afterSwap / PoolManager.swap,take,mint,burn paths the hook depends on. Area: Economic Security, Invariant and Flow Gap guides. The 42 project tests pass. Findings are in .imd-findings.json with a 14-row coverage record. Nothing in src/ was changed.

Severity counts: 0 Critical · 0 High · 1 Medium · 0 Low · 1 Info

[M-1] Fee is 1% of the amount requested, not of the IMD swapped: short fills overcharge, an unfilled sell still pays

Location: src/RnnnFeeHook.sol:174-175 (beforeSwap), booked again at line 192 (afterSwap) Root cause: When IMD is the specified currency, the fee is fixed from amountSpecified before the pool runs. The pool can stop short without reverting (price limit or liquidity exhausted), and the manager credits the hook the full 1% of the request anyway. Why it matters here: The launch pool is seeded with RNNN only, so the pool holds only the IMD buyers have paid in. A seller asking for more IMD than that gets a short fill and is overcharged. Reproduction: launch-shape pool, one buy of 100 IMD, then an exact-output sell for 1000 IMD.

On the fresh pool, an exact-output sell for 100 IMD moves no RNNN, delivers nothing, and still charges the seller 1 IMD, which the hook books as a pending claim. Proof: test/scratch/PartialFillFee.t.sol, two tests. Both fail on the current code and pass on a scratch copy of the hook that refuses short fills. The proof also accepts a hook that charges 1% of the actual fill instead. Fix: in afterSwap, when IMD was specified, compare the pool's IMD delta with the amount it was asked to trade and either revert on a short fill or charge 1% of the actual delta and return the excess credit. Refunding on the specified side is not possible through the return delta, so the author must choose.

[I-1] Fee base differs between the two legs of each direction

src/RnnnFeeHook.sol:191-192. IMD-specified swaps pay 1% of the trader's figure, IMD-unspecified swaps pay 1% of the pool's figure. The two bases differ by about 1% of the fee. The README documents all four shapes, so this is a definition note, not a defect.

Observations (non-blocking)

• Direct fee payment draws on the manager's global IMD balance, which includes other pools' reserves. This is solvent because the swapper settles in the same unlock.
• A router that interleaves sync, transfer, swap, settle would see its settlement shortened by the hook's take. No shipped router does this.
• The hook accepts dynamic-fee pools but never sets their LP fee. This cannot affect the launch pool.

Coverage

All six listed entry points have a row. afterSwap is finding, the rest holds. Additional rows cover beforeSwap (finding), beforeInitialize, the constructor, and four invariants: hook delta nets to zero on every path, IMD conservation with backed claims, no RNNN ever taken, and the 1% rule (finding). Nothing was left unreached.

The review is complete. Findings and coverage are in .imd-findings.json; no repository file was changed (the only new paths are the findings file and the two scratch tests, which are not kept).

Findings

• Medium, fee asymmetry on IMD-specified swaps. The two branches of afterSwap are not economically symmetric. When IMD is the unspecified currency the fee is 1% of the IMD the pool actually moved. When IMD is the specified currency the fee is fixed in beforeSwap at 1% of the amount requested. The branches agree only on a full fill. With a price limit that stops the swap early, an exact-input buy of 100 IMD filled 3.04 IMD into the pool and still paid 1 IMD, a 33% rate on the IMD side. An exact-output sell asking for 100 IMD with a tight limit received 0.05 IMD, paid the 1 IMD fee, and ended the swap with the seller paying IMD while also giving up RNNN. A front-runner can push a victim's fill toward their limit to trigger it. The proof test fails on the current code with both scenarios and passes once the fee is bounded to the IMD that moved.

• Low, wrong README assumption about IMD. The README says IMD has no blocklist. The live IMD on Robinhood Chain is a LayerZero OFT whose runtime exposes blocked(address), transfersEnabled(), setV4Config and an owner. Because the hook pays with a direct take inside the swap whenever the manager holds IMD, blocking the recipient on the IMD side reverts every buy and sell in the pool, while the hook's existing claim path does not. Verified with a blocklisting mock. This is a third-party admin trust assumption, reported for the factual correction and the simple fallback fix.

What held in my area

Every callback and unlockCallback is PoolManager-only, and the manager only calls back the hook from its own redeemPendingFees. There is no owner, setter, pause, mint or escape opcode. Claims are minted only from the hook's own swap credit, can be burned only by the hook, and every take targets the immutable recipient. Third parties can open other IMD pools on the hook but only pay the same recipient. The recipient address is a permissionless forwarder contract that pushes received IMD into an adapter owned by the launch owner, so fees are not stuck there.

Coverage

All six listed entry points have rows, plus seven extra rows for beforeSwap, beforeInitialize, the constructor, the unused callbacks and three invariants. afterSwap and beforeSwap are marked finding against the first item, the rest holds. Nothing is unreached.

The review is complete. The findings file is written and validated, no tracked files changed, and the only files I created are the required output and one proof test under the scratch directory the task allows.

Outcome. The hook's control flow is sound in every path I traced except one: swaps where IMD is the specified currency are charged on the amount requested, not on the amount that moved. I reported that as medium with a failing Foundry proof, plus one info-level documentation inaccuracy. Both are recorded in .imd-findings.json with reproductions and a coverage row for every listed entry point.

Finding 1, medium. In beforeSwap, the fee for an exact-input buy or exact-output sell is fixed at 1% of params.amountSpecified before the pool runs, and afterSwap never reconciles it with the real delta. Three concrete consequences, all reproduced:

• A partial fill (price limit one tick spacing away, 10,000 IMD exact-input buy) pays 100 IMD on 3,142 IMD moved, about 3.2% instead of 1%.
• On the launch pool as seeded (RNNN-only liquidity, no IMD in the manager), an exact-output sell for 100 IMD moves nothing yet takes 1 IMD from the seller and records it as a pending claim.
• A sell asking for more IMD than the pool holds makes the trader pay 102 IMD plus 98 RNNN and receive nothing. The proof test accepts either a 1%-of-moved fee or a revert, so a fix that refuses partial fills of IMD-specified swaps makes it pass. The README discloses only the first case.

Finding 2, info. The NatSpec and README say direct payment always happens once the pool has traded. A buy whose fee exceeds the manager's current IMD balance still defers, regardless of history.

What held. Delta accounting nets to zero on every path (take or mint before the manager's credit, burn plus take in flush and redemption). The redemption path is permissionless, re-entry safe through the manager's lock, and the callback can only be reached by the hook's own unlock. Pending claims cannot be moved anywhere but the recipient. The token is a plain fixed-supply ERC-20. Periphery (HookFlags, HookDeployer, script, mock) matches v4-core. I also confirmed, but did not report, that dynamic-fee IMD pools are admitted at 0 LP fee, since any such second pool is possible without the hook and the brief forbids blocking.

Not reached. No launch.json exists in the tree yet, so the manifest row is marked unreached; the README's constructor table and permissions match the implementation.

The review is complete and .imd-findings.json holds six findings and a thirteen-row coverage record. No tracked file was changed; only the findings file and my scratch tests under test/scratch/ exist, and both are gitignored.

What I found

• Medium, one merged finding. All five areas reported the same root cause and I merged them: when IMD is the specified currency, the hook charges 1% of the requested amount, fixed in beforeSwap, instead of 1% of the IMD the pool actually moved. Both specialist proofs fail on this tree for the stated reasons. A zero-fill exact-output sell on the launch pool's own seed shape takes 1 IMD from the seller for a 100 IMD request that moved nothing. A price-limited exact-input buy of 1,000,000 IMD fills about 50 IMD and pays 10,000 IMD of fee. I attached the write_foundry_tests proof, which fails with those exact numbers.
• Low. The same request-based fee overflows the int128 cast for a sentinel-sized exact-input amount that a hookless pool fills to its price limit, so the hooked pool reverts instead of trading. Reproduced against a plain pool side by side.
• Low. The direct take inside afterSwap ties every fee-bearing swap to IMD accepting a transfer to the recipient. Reproduced with a blocklisting mock: a blocked recipient reverts both buys and sells on a funded pool. I could not read the live chain, so the specialist's claim that IMD is an owner-controlled OFT with a blocklist is recorded as unverified.
• Info, three items. The NatSpec and README overstate when direct payment happens. A dynamic-fee IMD pool is admitted with a permanent zero LP fee. The fee base differs between the specified and unspecified swap shapes. Each reproduced in a scratch test.

What I dropped

The rounding-down note from audit_math is dust, documented in the README, and folded into the fee-base info item rather than reported on its own.

Coverage

All six listed entry points are answered. The swap callbacks carry the finding; redeemPendingFees, unlockCallback and the three token functions hold. Extra rows cover beforeInitialize, the constructor and deployment model, the manifest, and three invariants from the brief, all of which hold. Contract sizes are well inside the limits and the manifest is schema-valid with real addresses in lowercase.

All checks pass and every finding is answered. Nothing else is needed from the user.

Outcome

• The reviewer's proof reproduced on the starting tree (both tests failed with the reported messages) and now passes.
• forge build, forge test (59 tests, 0 failures) and forge fmt --check pass with the pinned solc = "0.8.26".
• The protected hook floor suite was rehearsed against the rebuilt creation code with the launch's pool terms and passed 4 of 4.

What changed in src/RnnnFeeHook.sol

• Short fills (medium finding, fixed). For swaps where IMD is the specified currency, beforeSwap now simulates the swap before committing its delta. It calls a new self-only simulateSwap, which runs the pool swap and always reverts with the resulting delta, so nothing persists. v4-core skips a hook's own callbacks for its own swaps, so the simulation is a plain pool swap. A full fill still pays 1% of the request; a short fill pays 1% of what the pool moved, and a zero fill pays nothing. The fee passes from beforeSwap to afterSwap through transient storage, so the hook's delta always nets to zero and no refund path is needed. A refund-in-afterSwap design could not pass the zero-fill case because an empty manager holds no IMD to refund with.
• Huge exact input (low, fixed). Amounts are computed in int256 and the only int128 cast is on 1% of the realised fill, which the pool already bounds. A test compares a 1e45 limited buy on hooked and hookless pools: identical fills.
• Blocked recipient (low, fixed). I verified the claim on chain through Robinhood Chain's public RPC: the live IMD token answers owner(), transfersEnabled() and blocked(address), and the recipient has code. The direct take now runs inside try/catch and falls back to minting a claim, so a blocked recipient defers fees instead of halting trading. A new test file covers it with a blocklisted stand-in token.
• Dynamic-fee pools (info, fixed). beforeInitialize refuses the dynamic-fee flag; static fees including 12500 are accepted.
• Direct-payment wording (info, fixed). NatSpec and README now state the real condition, and a test asserts the deferral of a large buy.
• Fee base (info, not reproducible as a defect). Confirmed as intended and documented explicitly.

Other files

• Tests: 15 new tests across test/RnnnFeeHook.t.sol and the new test/RnnnFeeHookBlocklist.t.sol, plus a BlocklistERC20 mock. One existing test was updated because a forged afterSwap without a preceding beforeSwap is now a no-op rather than a revert.
• README: new "How the fee is computed" section, corrected payment conditions and IMD blocklist facts, dynamic-fee refusal, gas note, and the updated test inventory.
• .imd-responses.json holds the six verdicts with details. It sits in the repository root and is excluded from git by the harness's own exclude file, as expected.

Nothing was committed, per the standing instruction to commit only when asked.

Manifest validates as JSON, the first key is kind, notes are 3600 characters, and only launch.json changed.

Outcome: launch.json now describes the accepted RnnnFeeHook and RnnnToken as they exist in the tree. The build passes and all 57 Foundry tests pass.

What changed: only the notes field. The previous manifest was written against an earlier revision of the hook and described behaviour the accepted code no longer has. It said partial fills charge 1% of the requested amount, said nothing about dynamic-fee refusal, and did not cover deferred payment when the IMD token refuses the transfer. The structural fields were already correct and are unchanged:

• Hook contract RnnnFeeHook with constructor arguments $poolManager, the IMD address, and the fixed recipient, in declaration order. The hook takes no $token, $owner or $factory because it has no owner, finds IMD in the PoolKey, and does not restrict who initializes.
• Permissions beforeInitialize, beforeSwap, afterSwap, beforeSwapReturnDelta and afterSwapReturnDelta, matching getHookPermissions and address bits 0x20cc.
• Token RnnnToken, rnnn.bid, RNNN, 18 decimals. Pool paired with IMD at fee 12500, tick spacing 60, the reference initial price.

What the notes now say first: the fee is paid inside the swap only when the PoolManager already holds enough IMD and the token accepts the transfer, so the first buys on the RNNN-only launch pool defer their fee as an ERC-6909 claim. Claims are flushed by the next swap or by the permissionless redeem function. The notes also disclose the swap-simulation gas cost on IMD-specified swaps, that other IMD pools can attach to the hook, and that the fee deliberately stays in IMD against the IMD default of settling in ETH.

The build succeeds; the lines printed are forge lint warnings on pre-existing code, not compiler errors. The revision is complete.

What was wrong. The rejected attempt failed at runtime because one of my accepted adversarial tests, the direct beforeSwap call from the manager's address, assumed the old view implementation. The hook was revised to simulate the swap inside beforeSwap, which needs the manager unlocked, so that call now reverts with ManagerLocked.

What I changed, all in test/RnnnFeeHookAdversarial.t.sol:

• Direct beforeSwap from the manager now asserts the real behaviour: with IMD specified it reverts with the manager's ManagerLocked, with RNNN specified it returns the zero delta and no LP fee override. Both leave no claim, no payout and no hook balance.
• Replaced the fee-overflow test, which only reverted for the wrong reason, with two real-pool failure paths. An exact input above int128 reverts whole on both a hooked and a plain pool and leaves nothing behind. An exact input of exactly int128.max fills in full, pays exactly 1% as a deferred claim backed by the settled input, and redeems to the recipient.

Verification. forge build succeeds and forge test passes all 77 tests across 7 suites, including the two invariant suites with 96 runs each. No .imd-findings.json was written: reading the revised simulation path adversarially, I found no concrete failing input. The scratch probe was removed and only the one test file differs from the accepted tree.

The review is complete: every finding from the previous round is settled as fixed, and I found no new defect. The findings file holds an empty list and a coverage record answering all eight entry points.

What I verified on the revised tree

• Medium, fee on request not fill: fixed. Both attached proofs pass (4 of 4). The new self-call simulation reverts fully, and v4-core skips the hook's callbacks for its own swap, which I confirmed in the vendored Hooks library. My fuzz probes over random sizes and limit distances agree: full fills pay 1% of the request, short fills pay 1% of the IMD the pool moved, zero fills pay nothing, and the trader always pays fill plus fee.
• Low, int128 cast on huge exact-input: fixed. The cast is now on the bounded fill, and the author's hookless-comparison test exists and passes.
• Low, blocked recipient halts swaps: fixed. The direct take is wrapped in try/catch and falls back to a claim. The Blocklist suite passes and the README now states the verified on-chain facts.
• Info, NatSpec/README direct-pay condition: fixed in text, with a regression test.
• Info, dynamic-fee pool: fixed. Initialization now reverts on the dynamic flag.
• Info, fee base by swap shape: dropped. The author confirmed it as intended and documents it, which matches what I reported.

Additional checks

• The whole suite passes (81 tests). The protected hook and token floor suites pass with the manifest's constructor arguments, flags, fee 12500 and spacing 60 from a factory probe.
• Two IMD-specified swaps in one unlock are each charged correctly, and a pending-claim flush during a sell leaves the seller's full output intact.
• The manifest's arguments match the constructor order, permissions match the implementation, and notes are under the length limit. Bytecode is well under the size limits.
• Slither's lines are benign: the uninitialized local is an intentional zero default, the ignored unlock return is unused by design, and the reentrancy-events hits are event ordering only.

Scratch tests were removed, so the only file written is the findings record.