Done. The RNNN launch is implemented, tested, documented and committed at c80e1a3. A fresh clone builds, passes all tests and passes forge fmt --check with no network.

What was delivered

• src/RNNNToken.sol: plain fixed-supply ERC-20, name and symbol RNNN, 18 decimals, 1,000,000,000 tokens minted once to the deployer. No owner, mint, pause, blocklist, fee or upgrade path.
• src/RNNNImdFeeHook.sol: the one-rule hook. On every swap it takes 1% of the swap's IMD side, in IMD, and sends it to the fixed recipient given as an immutable constructor argument. When IMD is the specified currency the fee is declared in beforeSwap, otherwise in afterSwap, so all four swap shapes pay exactly 1%. The fee is delivered at once with take when the PoolManager holds enough IMD. On a freshly seeded pool, which holds no IMD until the first buyer's input settles, the fee is held as an ERC-6909 claim instead, so no swap ever reverts. Later swaps deliver pending claims automatically, and anyone may call collectPending to deliver them to the fixed recipient. beforeInitialize accepts any initializer and any LP fee tier and only requires the pool to have an IMD side. No owner, no setters, no ETH entry point.
• src/HookFlags.sol and test/mocks/MockERC20.sol at the paths the pinned protected tests import.
• script/Deploy.s.sol: rehearsal deployment whose deploy function mines the salt and is called directly from a test.
• Vendored forge-std, Uniswap v4-core src/, and solmate's Owned.sol as ordinary files, no submodules.
• README.md documents the fee semantics per swap shape, the claim fallback, constructor arguments with their manifest values, launch parameters, assumptions, operational responsibilities, and the hook configuration record.

Verification

The tests cover exact-input and exact-output buys and sells each sending exactly 1% of the IMD side to the recipient, fuzzed IMD conservation, the fresh tokens-only pool deferring and later delivering the fee, callback access control, a privileged-selector sweep from several callers, pool initialization acceptance and rejection, and the token's supply and transfer behaviour.

Decisions worth knowing

• The brief's instruction that the recipient receives IMD overrides the generic launch guidance about selling hook fees for ETH, so nothing is sold and no price limit or ETH market exists.
• The IMD address is a constructor argument because the brief gives its value for the launch chain. The manifest step should write the PoolManager as $poolManager and the other two arguments as the literal addresses listed in the README.
• No launch.json was written, as instructed.

Created launch.json with matching contracts, constructor arguments, permissions, and required pool values.

forge build succeeded; all 37 tests passed. Only the manifest changed.

Notes disclose the existing hook’s deferred-payment and partial-fill fee limitations.

The findings file and the scratch proof are on disk. They are ignored by a global git exclude, which is the expected handling for review output, so nothing in the reviewed tree changed. The review is complete.

Outcome

The economics audit of the RNNN/IMD fee hook found one substantive defect, one minor inconsistency, and one design-level trust assumption. All are written to .imd-findings.json with a coverage row for every listed entry point.

Finding 1, high: the fee is computed from the requested amount, not the executed amount. When IMD is the specified currency, beforeSwap commits 1% of amountSpecified and afterSwap settles exactly that. A Uniswap v4 swap that reaches its price limit or exhausts liquidity stops without reverting, so on a partial fill the swapper pays 1% of the whole order for a fraction of it. The proof test under test/scratch/PartialFillFee.t.sol fails on the current code with these numbers:

This breaks the launch's single rule and pays the recipient IMD it is not entitled to. The report includes a fix sketch that keeps the no-owner design: derive the fee from the executed delta and return any over-commitment to the swapper's delta.

Finding 2, low: the two IMD-specified paths charge 1% of the swapper's gross while the two unspecified paths charge 1% of the pool's amount. The same trade pays 0.990%, 1.000% or 1.0101% depending on how it is routed.

Finding 3, info: nothing forces RNNN/IMD trading through the hooked pool, so a hookless pool avoids the fee entirely. This follows from the brief, so it is recorded as a trust assumption, not a defect.

What holds: delta accounting nets to zero on every path, deferred claims are always backed, the recipient only ever receives IMD, collectPending and unlockCallback are safe, and the token is a plain fixed-supply ERC-20 with no admin surface. I did not cover the Universal Router's exact settlement behaviour on partial fills beyond reading its action semantics.

The review is complete and .imd-findings.json holds two findings and eleven coverage rows. Both quoted snippets match the source lines exactly.

Finding 1, medium, with proof. src/RNNNImdFeeHook.sol:158. When IMD is the specified currency, the hook charges 1% of the amount asked for, not of the IMD the pool actually moved. v4-core subtracts the beforeSwap delta from the swapper regardless of fill, so a price-limited exact-input buy of 1,000 IMD that fills 1.01 IMD still pays a 10 IMD fee. On the launch pool's own opening state, seeded with RNNN only, the first exact-output sell fills nothing and the seller is still debited 10 IMD. The proof file in test/scratch fails both scenarios on the current code.

Finding 2, low, no proof. src/RNNNImdFeeHook.sol:268. The direct-pay branch has no fallback when the IMD transfer to the recipient reverts, unlike the balance-short branch that mints a claim. I checked the live IMD on Robinhood Chain over its public RPC. It is an owner-controlled LayerZero OFT with a per-address blocklist and a transfers-enabled switch. Both are currently permissive and the recipient is a contract that can hold IMD, so this is a documented trust risk, but one owner action on IMD would revert every fee-bearing swap. A scratch test demonstrates the reverts.

Coverage. All six verifier entry points have rows: afterSwap carries the findings, collectPending, unlockCallback and the three token functions hold. Extra rows record the beforeSwap delta bound, beforeInitialize access, the absent privileged surface, claim backing, and the manifest as unreached since no launch.json exists in the tree. Access control itself is clean: every callback is PoolManager-only, configuration is immutable, and there is no owner, setter, pause, mint or ETH entry point.

Sources used for the IMD check: Blockscout Robinhood API docs, Alchemy Robinhood Chain RPC details.

The review is complete. Findings and coverage are in .imd-findings.json; no tracked file was changed. The only working-tree additions are the findings file and the proof test under test/scratch, which the verifier runs.

Result: one high, two low, across the three guides assigned to me.

1. High. Fee on IMD-specified swaps is 1% of the requested amount, not of the IMD actually swapped. For an exact-input buy or exact-output sell the hook fixes the fee in beforeSwap from amountSpecified and settles that same number in afterSwap. v4 stops a swap at the price limit or when in-range liquidity runs out, so the pool can trade far less than requested while the hook's credit stays the same. Reproduced three ways on this tree: a buy with a 0.05% price limit paid 1,506 IMD of which 1,000 was fee. A buy against a bounded RNNN-only range paid 127,796 IMD with a 100,000 IMD fee for 27,796 IMD of trade. An exact-output sell on the fresh launch pool traded nothing and still took 10 IMD from the seller. The proof test fails three of three on the current code and passes on a scratch copy with a revert-on-partial-fill fix. The fix is a scope call for the author: either refuse the mischarged swap or refund the excess to sender, since the afterSwap return delta cannot touch the specified currency.

2. Low. The hook refuses fill-to-limit swaps the plain pool executes. fee.toInt128() overflows once the requested amount exceeds 100 times the int128 maximum. A plain pool with the same price limit fills the swap. No funds at risk, but it contradicts "never blocks".

3. Low. Fee base differs by swap form. Unspecified-IMD forms charge 1% of the pool's IMD; specified-IMD forms charge 1% of the swapper's IMD. The same trade pays a fee that differs by 1% of the fee depending on exact-in versus exact-out. Concrete percentages for all four forms are in the file.

Coverage. All six listed entry points have rows. afterSwap is a finding. collectPending, unlockCallback and the three token functions hold after tracing their checks and arithmetic. I added rows for beforeSwap, beforeInitialize, the constructor, _settleFee, the HookFlags constants and three invariants. Within my area I did not find anything in the deferred-claim arithmetic, the delta netting, the floor rounding, or the token's unchecked block. The Slither reentrancy-events leads and the Aderyn style leads did not reproduce as defects.

The review is complete. .imd-findings.json holds two findings and a 13-row coverage record; no source files were changed, and the only working-tree additions are the findings file and my scratch proof under test/scratch/.

Findings

1. Medium, src/RNNNImdFeeHook.sol:158. When IMD is the specified currency (exact-input buy, exact-output sell), the fee is fixed in beforeSwap as 1% of the requested amount and settled unchanged in afterSwap, never reconciled with what the pool actually traded. On a partial fill the swapper is overcharged. Two reproductions, both failing in the attached proof test:

   • Funded pool, exact-input buy of 100,000 IMD with a price limit ten ticks away: the pool consumed 506 IMD, the recipient received 1,000 IMD, about 197% of the pool's IMD side.
   • The launch pool's opening state (RNNN-only liquidity), exact-output sell asking for 1,000 IMD: the pool trades nothing, the swapper still loses 10 IMD, booked as a claim for the recipient. The unspecified-IMD paths read the real delta and are correct. I suggested two fixes: cap the fee at 1% of the traded IMD and return the excess to the sender inside the unlock, or refuse partial fills with a clear revert.

2. Low, src/RNNNImdFeeHook.sol:174. The fee base is inconsistent across swap shapes: exact-input swaps pay 1% of the gross IMD leg, exact-output swaps pay 1% of the net leg. Concretely, a 1,000 IMD exact-input buy pays 1.0101% of the pool's leg, a 1,000 IMD exact-output sell pays 0.9901% of it. The repo's own tests encode both definitions.

Coverage. All six ABI entry points have rows: afterSwap is a finding, collectPending, unlockCallback and the three token functions hold. Additional rows cover beforeSwap, beforeInitialize, the constructor and permission bits, the hook-holds-nothing invariant, the HookFlags and deploy periphery, the sync-before-swap router caveat, and the slither reentrancy-events leads, which are benign because the only external calls are to the immutable PoolManager.

Not reported. Delta accounting nets to zero in every branch including the deferred-claim path, access control on every callback is correct, the ERC-6909 claims can only reach the fixed recipient, and the token has no privileged path. One thing to carry forward to the manifest step: the hook's imd_ constructor argument must equal pool.pairedCurrency, or beforeInitialize refuses the launch pool. There is no launch.json in the tree to check it against yet.

The review is complete. No tracked file was changed. Only the findings file and my scratch tests exist outside the tree, both ignored by git.

Outcome. One high finding, three low, all reproduced against the code with Foundry. Nine specialist reports collapsed into these four. The economics specialist's info note about unhooked RNNN/IMD pools was dropped as a consequence of the brief rather than a defect.

Findings written to .imd-findings.json:

1. High, with proof. When IMD is the specified currency, the hook charges 1% of the requested amount, never re-reading what the pool filled. A price-limited exact-input buy of 100,000 IMD paid a 1,000 IMD fee on a 3,042 IMD trade. On the IMD-empty launch pool, an exact-output sell traded nothing yet debited the seller 10 IMD, booked for the recipient. Five specialists reported this; merged into one finding at high because a swapper loses funds to the recipient under ordinary slippage limits. The proof test fails on this tree and passes under either fix shape, a bounded fee or a refused swap.
2. Low. Fee base differs by swap shape. Measured 1.0101%, 0.9901% and 1.0000% of the pool's IMD side across three shapes. Three specialists, merged.
3. Low. Huge exact-input amounts that a plain pool fills to its limit revert in the hook on the int128 cast of the fee.
4. Low. A refused IMD transfer to the recipient reverts every fee-bearing swap, contradicting the README's own guarantee. Documented as an assumption, kept as a trust risk with a mock reproduction.

Coverage. All six listed entry points answered. The three token functions, collectPending and unlockCallback hold. afterSwap carries finding 1. I added rows for beforeSwap, beforeInitialize, constructor and deployability, undeclared callbacks, delta accounting and privileged functions. My own pass found nothing beyond the specialists: the manifest matches the constructor and permissions, the hook deploys under the factory model, claims can only be burned by the hook, and the full 82-test suite passes.

The responses file is excluded by the harness's own .git/info/exclude, so it is collected from the working tree by design, not committed. I'm leaving .git/ alone as the rules require. The work is complete.

Summary

All four findings reproduced and were fixed. The hook keeps its design, no owner, one rule, with the IMD-specified path corrected and the fee base unified.

High finding, short fills overcharged. afterSwap now reads the IMD the pool actually traded from its own BalanceDelta on every path and charges 1% of that. On the IMD-specified path beforeSwap still declares the full-fill fee, and afterSwap returns any unowed excess to the swapper's router inside the same unlock through take, sync, transfer and settleFor. When the PoolManager holds too little IMD to fund that refund, which is the launch pool's state before its first buy settles, the swap is refused with a dedicated ShortFillNotRefundable error instead of being mischarged. A zero-fill exact-output sell on the RNNN-only pool is now refused with the seller's IMD untouched.

Advisory findings.

• Fee base. All four swap shapes now charge 1% of the pool's IMD leg. The declared fee is X/101 on exact input and Y/99 on exact output, so a full fill needs no refund.
• SafeCast overflow. The declared fee is computed by division and clamped to the int128 range. Oversized orders fail with the hook's own short-fill error rather than an overflow, which the response explains honestly.
• Blocked recipient. The take to the recipient is in try/catch and falls back to an ERC-6909 claim, so an IMD blocklist entry defers fees rather than halting swaps.

Verification. forge build, forge test (51 tests, 14 new) and forge fmt --check all pass. The verifier's protected hook and token tests were rehearsed against the new bytecode in a scratch directory and passed. Short-fill tests use a new test/mocks/ActualDeltaRouter.sol that settles recorded deltas like the Universal Router, since v4-core's PoolSwapTest cannot drive a refund.

Documented in the README. The new fee table, the short-fill and refund rule, the refusal window at launch, which routers receive refunds, the blocklist fallback, and the one-wei rounding edge on exact-input buys.

I updated the notes in launch.json and changed nothing else. forge build succeeds and forge test passes all 51 tests.

Why the notes changed: another contributor revised RNNNImdFeeHook after my manifest was accepted, so the old notes described behaviour the hook no longer has. They claimed the fee is based on the amount the swapper asked for, with no adjustment for partial fills. The hook now:

• takes 1% of the IMD the pool actually traded, on every kind of swap;
• refunds any overcharge on a partly filled swap where IMD is the specified side;
• turns the fee into an IMD claim if it can't be delivered yet, including when the recipient refuses the transfer.

One problem with the brief: the notes now open with a limitation that conflicts with "does not block or alter swaps in any other way." A partly filled swap where IMD is the specified side reverts with ShortFillNotRefundable if the PoolManager holds too little IMD to make the refund. That can happen on the launch pool before its first buy settles. The hook refuses the swap rather than overcharging it. Full fills are never affected. Reviewers should decide whether that is acceptable.

Fields I checked and left unchanged:

• Hook: RNNNImdFeeHook, with constructor arguments in declaration order: "$poolManager", then the IMD address 0x5f7b…7127, then the fee recipient 0x45c8…be4. Both addresses come from the brief. The hook takes no token or owner argument, so "$token" and "$owner" don't appear.
• Permissions: beforeInitialize, beforeSwap, afterSwap, beforeSwapReturnDelta, afterSwapReturnDelta. This matches getHookPermissions and the address bits 0x20cc.
• Token: RNNNToken, named RNNN, symbol RNNN, 18 decimals, no constructor arguments.
• Pool: paired with IMD at fee 12500, tickSpacing 60 and initialPrice 79228162514264337593543950336. beforeInitialize accepts that fee and spacing.

The notes are 2,630 characters, under the 4,000 limit.

Done. The full suite is green again and the revision stays inside my three accepted test files.

What was wrong. The hook was revised after my tests were accepted. The fee base moved from 1% of the amount the swapper specified to 1% of the IMD the pool actually trades, with a refund path for short fills. That made 22 of my tests fail on arithmetic the implementation no longer has. The rejected attempt's work did not survive, so this is the first revision that lands.

What I changed. Only test/RNNNImdFeeHookOrdering.t.sol, test/RNNNImdFeeHookInvariants.t.sol and test/utils/RNNNImdFixture.sol. The other contributor's tests, the source and the README are untouched.

• Fee oracle rebuilt from balances. Both suites now compute the pool's IMD leg from the manager's balance and the claim books alone, then assert the fee is floor(1%) of that leg, capped at the declaration when IMD is the specified currency. The swapper's IMD must move by the leg plus or minus that fee. This is independent of the hook's arithmetic, so it can check it.
• Short fills now exercised in both token orderings. Price-limited buys and exact-output sells go through the actual-delta router, with a fuzz over sizes and limits. The refund amount is checked against the emitted event, and the router and hook must end holding nothing.
• Failure paths added. A v4-core router that settles the returned delta cannot complete a short fill. The launch pool refuses a short fill until the first buy settles, then trues it up. An exact-output sell that fills nothing is refused. IMD blocking the hook stops short fills but not full fills. Oversized orders clamp instead of reverting.
• Invariant handler reworked. The IMD-specified shapes take a random price limit, so short fills and refusals occur under random sequences. A refusal is accepted only when the manager held less IMD than the declaration and nothing moved. Fees must sum to exactly floor(1%) of all traded volume, and the funded pool must never refuse or defer anything. I verified by probe that short fills, refunds and refusals are actually hit, not vacuous.

Results.

Findings reported in .imd-findings.json, both without proof since neither is high severity:

• Low. IMD-specified short fills are refused whenever the manager holds less IMD than the unowed part of the declaration. That blocks slippage-limited buys on the launch pool before the first settled buy, after IMD is sold out of the pool, and for orders over roughly 101 times the manager's IMD. The README documents two of the three cases.
• Info. An exact-input buy of X with X mod 101 equal to 100 pays one wei under 1% of the leg. Never over, not exploitable.

I drafted a third finding about the refund's sync breaking routers that sync before swapping, then reproduced it and found those routers already fail on every fee-bearing swap because of the take in afterSwap, which the README states. The refund adds no new exposure, so I dropped it.

The findings file is in place and the repository is otherwise untouched (the file is excluded by the harness, and my scratch tests are removed).

Outcome: all four round-1 findings are fixed. No new blocking defect. The file carries one low advisory and one info note.

Round-1 findings, settled by my own reproduction (fresh PoolManager, same inputs as before):

• 789cc455 (high, fee on partial fills): fixed. A price-limited 100,000 IMD buy on the funded pool now pays 30.42 IMD, which is 1% of the 3,042.38 IMD leg, and the swapper pays leg plus fee. The exact-output sell on the RNNN-only launch pool is refused with the dedicated error, the seller's IMD is unchanged and nothing is booked for the recipient. The refund path nets the hook to zero and credits the router inside the same unlock. I traced this against v4-core's Hooks.afterSwap and settleFor.
• 80701ca0 (low, fee base by shape): fixed. All four shapes charge floor(pool IMD leg / 100).
• 72cf4725 (low, SafeCastOverflow): fixed. The oversized order no longer overflows. It is refused with the hook's own error, which falls under the short-fill rule I accepted.
• f766513a (low, blocked recipient): fixed. With the recipient blocked, a buy and a sell both trade and defer the fee as a claim, delivered by collectPending once unblocked.

Kept, advisory only:

• Low: the short-fill refusal window is wider than the README says. The swap is refused whenever the manager's IMD is below the unowed declaration, not only before the first buy. I reproduced it on the launch pool after a 100 IMD first buy, where a hookless twin fills 3,053 IMD. This is the deviation my round-1 finding explicitly allowed, so it asks for a documentation correction, not a code change. Merged with the testing specialist's low.
• Info: the one-wei rounding at X mod 101 == 100, already in the README. Merged from the testing specialist.

Dropped: the economics specialist's note that other RNNN/IMD pools avoid the fee. That follows from the brief's plain token and one-rule hook, not from a code defect.

Coverage answers all six entry points, with afterSwap pointing at the advisory finding and the rest holding. Slither's unused-return on settleFor and aderyn's unsafe-erc20 lead did not reproduce: the settled amount is the measured balance difference and the transfer helper reverts on failure.