Completed the audit and repaired Foundry project.

• Enforced exactly 1 billion SIMD.
• Added pool validation and safe fee arithmetic.
• Replaced immediate fee payouts with beneficiary-controlled collection.
• Added a factory for deploying hooks at valid addresses.

forge build, forge fmt --check, and all 55 tests pass.

Findings: AUDIT.md. Deployment parameters and owner responsibilities: README.md. Activation requires configuring a verified PoolManager and mining the hook salt.

Created launch.json with SuperIMD followed by SuperIMDHookFactory, the exact billion-token supply, and $owner beneficiaries.

Constructor ABI checks passed. forge build succeeded; all 55 tests passed with the required seed. Only the manifest changed.

Notes document that hook activation requires later owner configuration of a verified PoolManager.

The review is complete. The findings file is written and validated, with both snippets matching the source lines exactly.

Outcome: the SuperIMD token and hook hold up under the Execution Trace, Periphery and First Principles checks. I found no critical, high or medium defect. Two issues are recorded in .imd-findings.json, both reproduced with a scratch Foundry test that passes on the current code by asserting the bad behavior.

Findings

• Low, fee collection to the PoolManager address strands ERC-20 fees. The destination filter in collectFees rejects the zero address and the hook itself but not the PoolManager. The callback burns the claims, then the manager transfers tokens to itself, which succeeds and moves nothing. The claims are gone and the tokens sit in the manager with no owner. Only the fee recipient can trigger it, so it is a self-inflicted loss by a trusted role. The native path reverts because the pinned PoolManager has no receive function. Fix is one extra condition on the recipient check.
• Info, the token constructor rejects the brief's whole-token figure. Passing 1000000000 reverts, and only the base-unit constant is accepted. Because the hook factory depends on the token, a manifest copying the brief's number parks the whole launch. The README documents the base-unit value, so this is a deployment hazard rather than a code defect.

What held, with the reasoning traced

• The swap fee path nets the hook's delta to exactly zero: the claim mint debits the hook and the returned positive delta credits it back. Currency selection matches v4's hook-delta placement in all four swap modes, and the sign checks cannot fire on a legitimate swap.
• Fee collection sets its guard before the unlock and resets it only on success. Reentrant collection, direct callback calls and third-party burns of the hook's claims are all blocked.
• The factory enforces the exact permission bits before CREATE2, the hook constructor re-validates them, and the manager setting freezes after deployment.
• The token is unmodified OpenZeppelin ERC20 and ERC20Permit with no mint, tax or admin surface.
• A dynamic-fee pool keyed to this hook still pays the 2% hook fee; the zero LP fee is a liquidity provider choice, not a hook defect.

Coverage: all nine listed entry points have a row, eight hold and one carries finding 1, plus four invariant and periphery rows. Not reached: a live-chain check of the target chain's PoolManager and the real IMD quote token, which the repository documents as operator responsibilities.

The review is complete and written to .imd-findings.json. The tree is otherwise untouched: the scratch test was removed and no source, config or test file changed.

Outcome. The permission model holds across all nine entry points. I traced each against the Access Control, Trust Gap and Asymmetry guides and against the pinned v4 PoolManager code, and confirmed the key claims with the existing suite and with a scratch test on the real manager.

What holds, with the reason:

• afterSwap is manager-only and pool-scoped to the project token. The claim mint debit is exactly offset by the returned delta the swapper pays, so the hook never ends a swap with an open delta. The hook never calls swap, so the self-call exemption that would skip the fee is unreachable.
• collectFees and unlockCallback can only be driven by the immutable fee recipient. The manager calls back only its own locker, the hook only unlocks from collectFees, and its claims cannot be burned or moved by anyone else because it never grants an operator or allowance. Reentry by the payout recipient is blocked twice, by the collection guard and by the manager's single-unlock rule.
• Factory roles are explicit constructor arguments, the manager can only be set before the one-time deployment, and nobody else can occupy the CREATE2 address.
• Token entry points are unmodified OpenZeppelin code with no admin, tax or mint path.

One finding, low severity. The token constructor accepts exactly one supply value, ten to the twenty-seventh base units, and reverts on anything else. The brief states the supply as one billion whole tokens. A manifest that copies that literal into the constructor arguments fails the protected constructor rehearsal and parks the launch. The reproduction is new SuperIMD(1000000000, owner) reverting with IncorrectInitialSupply. No funds are at risk and it is recoverable, but the parameter now only serves as a tripwire. The suggested fix keeps the economics: drop the parameter or scale a whole-token input.

Noted but not reported as a defect. Exact-input swaps pay 2% of output while exact-output swaps pay 2% of gross input, so an exact-output trader saves roughly four hundredths of a percent. That asymmetry is dust-level, non-compounding and documented in the README.

Not run. The protected owner-check test imports a floor file that is not in the tree, so it could not execute here. Nothing in the factory or token derives ownership from the deploying factory or transaction origin, which is what it checks.

The review is complete and .imd-findings.json is written. No tracked file was changed; the only file I created besides the findings record is the scratch test under the ignored test/scratch/ directory.

Outcome. The hook's arithmetic holds under all three assigned guides. I found no defect above informational severity, and I recorded one informational finding with concrete numbers.

What I checked, against the pinned v4-core and OpenZeppelin sources.

• Fee currency selection matches v4's own unspecified-currency mapping for all four swap modes.
• Magnitude is widened to int256 before negation, so the minus 2^127 input no longer panics. Multiplication by 200 cannot overflow, and the result fits the int128 return.
• The mint debit inside afterSwap is exactly cancelled by the returned positive delta. The manager accounts the hook delta before the swapper delta, so the nonzero-delta counter returns to zero.
• Collection burns and takes net to zero. Overcollection reverts on checked underflow. Amounts at or above 2^127 revert in SafeCast, which the README documents as needing tranches.
• Reentry through the recipient is blocked by the guard, and nested unlock is blocked by the manager. The Slither and Aderyn reentrancy and unused-return leads reproduce as non-exploitable.
• The factory's CREATE2 preimage, flag mask and one-shot deployment are correct.
• The token is unmodified OpenZeppelin code with a fixed supply that fits v4's int128 settlement range.

The one finding, informational. The fee is floor(magnitude / 50), so it rounds toward the trader. A scratch test on the real manager measured these exact-input sells against a no-hook pool:

The loss is bounded at 49 base units per swap and is not farmable, since gas dwarfs it. The README already documents the rounding direction, so this needs no change unless the author prefers a ceiling fee.

Coverage. All nine listed entry points have a row, plus three invariant rows. Eight are holds and afterSwap is finding for the informational item. Nothing was left unreached. The exact-output fee base including the LP fee was measured and confirmed as documented behaviour, not a defect.

I audited SuperIMD, SuperIMDHook and the hook factory that earlier contributors added, and found no critical, high or medium defect. I added 12 tests in three new files under test/. forge build succeeds and forge test passes 67 tests, 0 failing, using the required fuzz seed.

What the earlier work already had: 55 tests, including runs against a real Uniswap v4 PoolManager, comparisons against identical pools without the hook, permit replay and expiry cases, and one hook invariant suite. What was missing: invariant tests on the token, a hook invariant covering more than one pool, and a few failure paths.

What I added:

• test/SuperIMD.Invariant.t.sol (token): five signing accounts make random transfers, transferFroms, approvals, time jumps and permits. Permits are sent valid, tampered, with an old nonce, expired, signed by the wrong key, or replayed. After every call:

  • total supply stays exactly 10²⁷ (one billion SIMD at 18 decimals);
  • the accounts' balances add up to the full supply;
  • every balance, allowance and nonce matches a separately kept record.

  Every rejected call must fail with the exact expected error and change nothing. The suite runs 128 sequences of 64 calls.

• test/SIMDhook.MultiPoolInvariant.t.sol (hook): three hooked pools — SIMD against ETH, and SIMD against tokens sorting on each side of it, with different LP fee tiers. Each is mirrored by an identical pool without the hook, so the fee can be checked exactly. Random calls include all four swap modes, very small and normal sizes, adding and removing liquidity, partial collection, collecting more than is owed, and outsiders trying to collect or fake the PoolManager callbacks. After every call:

  • for each currency, uncollected fees plus collected fees equal the fees earned;
  • the PoolManager holds enough to cover the hook's fees, and the hook holds no tokens or ETH directly;
  • no swap debt is left unsettled;
  • every currency is fully accounted for across all holders.

• test/SIMDhook.Edges.t.sol: these failure paths all revert cleanly and leave nothing changed:

  • collecting from inside another PoolManager unlock, after which a normal collection still works;
  • outsiders trying to collect fees that a third party sent to the hook;
  • collecting a currency that has no fees;
  • pools on a different PoolManager trying to swap through the hook;
  • non-owners calling the factory, and deploying from random salts.

  Both invariant files also include a fixed sequence that confirms every handler path is actually reached, so the random runs aren't checking nothing.

Findings (in .imd-findings.json in the repo root; none needs a failing proof):

• Low: the fee rounds down, so any swap whose fee-bearing side is under 50 base units pays nothing (src/SIMDhook.sol:78). That falls short of "2% on every swap". With 18 decimals this only matters where gas is nearly free. Rounding the fee up would close it.
• Info: the fee is taken in whichever currency the trader didn't fix the amount of. That depends on how the router builds the swap, not on whether it is a buy or a sell. On exact-output swaps, 2% of the pre-fee input works out to about 1.96% of what the trader pays. The hook also accepts any token paired with SIMD, not only ETH or IMD.
• Info: the fee recipient can't collect from inside its own PoolManager unlock (src/SIMDhook.sol:102). The attempt fails without side effects.

The new tests are committed on a new branch, audit-tests-simd, since the work started on a detached HEAD. .imd-findings.json is git-ignored, so it is on disk but not in the commit. Nothing ran against a live chain fork.

The findings file is valid, the snippet matches the tree exactly, and no tracked file changed (the scratch test and findings file are gitignored or untracked, which is the allowed state).

Recap

Area covered: Economic Security, Invariant and Flow Gap guides from the Pashov reference, applied to the token, the hook, its base, and the factory, plus the v4 PoolManager code paths the hook depends on at the pinned commit.

Result: one low-severity finding, written to .imd-findings.json with 14 coverage rows (all 9 listed entry points answered, plus 5 invariant and economic rows).

Finding 1 (low), range-order fee bypass. The hook enables only afterSwap, so liquidity operations never reach it. A holder can convert SIMD to ETH inside the hooked pool by placing a single-sided position just below the price, letting an ordinary buyer's swap fill it, and withdrawing ETH. Reproduced against the real PoolManager: a seller converted 2.986 SIMD into 3.013 ETH with zero hook fee, where a direct swap of the same amount accrues about 0.062 ETH to the hook. Only the active counterparty pays the 2%. This is inherent to concentrated-liquidity pools and closing it would be a design change needing liquidity-hook permissions, so it is reported as a documented gap in the "every buy and sell pays 2%" promise rather than a code bug.

What held, with evidence:

• Fee accounting nets to zero per swap in every mode and both token orderings; multiple hooked swaps inside one unlock settle cleanly; claims are always backed by the swapper's reduced delta.
• Collection is beneficiary-only and atomic; failed transfers restore claims; nested collection and nested unlock both revert; the callback runs only for the hook's own unlock.
• Token is a plain fixed-supply OZ ERC20 with standard permit; no economic surface beyond that.
• The full existing suite passes, 55 tests including the two stateful invariants.

Not reached or out of scope: no fork test against a live chain-4663 PoolManager, no nonstandard quote tokens beyond reasoning (fee-on-transfer, blacklisting are documented as unsupported), and the Slither and Aderyn leads all concern collectFees reentrancy, which I traced and found guarded, so none became findings.

One operational note for the manifest step, not a defect: the token constructor accepts only 1000000000000000000000000000 base units, so a manifest entry of 1000000000 would revert at deployment.

The review is done and the findings are in .imd-findings.json. Of the specialists' seven findings, two remain after merging and five were dropped. Nothing is critical, high or medium. The 67 existing tests pass, the build succeeds, and no tracked files were changed (the scratch test has been deleted).

Findings kept

1. Low: fee collection can destroy fees if the recipient is the PoolManager. At src/SIMDhook.sol:98, collectFees rejects a zero address and the hook itself as recipient, but not the PoolManager. If the fee recipient sends ERC-20 fees there, the hook's fee claims are burned, but the tokens never leave the PoolManager and can't be recovered. I reproduced this with the real PoolManager in a scratch test: collecting 20e18 of a test token to the PoolManager succeeded, the hook's balance went to 0, and the PoolManager's token balance didn't change. It's low because only the fee recipient can trigger it, and only against their own fees. Native ETH isn't affected, because the transfer reverts. The fix is to add || recipient == address(poolManager) to that check.
2. Info: the 2% fee rounds down. At src/SIMDhook.sol:78, any swap whose unspecified-side amount is 1–49 base units pays no fee, and every swap under-collects by at most 49 base units. With 18-decimal tokens this is far below gas cost and can't be exploited, and the README and manifest notes already say so. This merges the math specialist's finding and the test writer's, which share the same cause. The existing test test_tinySwapRoundsFeeDown shows it.

Specialist findings dropped

• Constructor rejects a supply of 1000000000 (reported by two specialists): launch.json passes the correct value, 10^27 base units. Rejecting any other value is a safety check, not a defect.
• Fees bypassed through single-sided liquidity (range orders): this is how concentrated-liquidity pools work. The original hook in the brief had the same permissions, and adding liquidity isn't a swap.
• Which currency the fee is charged in, and any quote token being accepted: this is the intended design. Accounting holds and no one loses money.
• Collecting fees from inside another PoolManager unlock reverts: the revert leaves fees and state intact and a later collection works. The code comments already document it.
• Static-analysis reentrancy and unchecked-return warnings: these don't reproduce. The collecting flag blocks re-entry, and nothing needs to be read from the unlock return value.

Coverage: all 9 entry points have a row, plus one for the manifest.

• Holds (7): the four token functions (standard OpenZeppelin ERC-20 and permit), unlockCallback, and both factory functions.
• Finding: afterSwap (finding 2) and collectFees (finding 1).
• Manifest: launch.json matches both constructors.
• Deployability: the contracts deploy within size limits (5.2 KB and 8.2 KB deployed). Their constructors make no external calls, and the hook is deployed later by the owner through the factory.