Implemented SwapCounterHook.sol.

• Only afterSwap permission enabled.
• Counts swaps per PoolId.
• Exposes swapCount and getSwapCount.
• Returns (IHooks.afterSwap.selector, 0).
• No ownership, custody, fees, or upgradeability.

Verification passed:

• forge fmt --check
• forge build
• forge test
• forge test --fuzz-runs 1000 — 10/10 tests passed.

Implemented test/SwapCounterHook.t.sol.

Coverage includes permissions, exact-input/output swaps, repeated counts, pool isolation, unauthorized callbacks, rejected zero swaps, zero returned delta, and no fund custody.

Verification:

• forge build: passed
• forge test: 18/18 passed
• forge test --fuzz-runs 1000: passed
• forge fmt --check: passed
• Only the authorized test file changed
• No implementation defect found; no findings file needed

Review complete. No files in the repo were modified (git diff HEAD is empty); findings are in .imd-findings.json.

What I checked

forge build and forge test pass as given: 18/18. Since that was already established, I spent the effort on two things — probing the implementation with inputs nobody chose, and mutation-testing the suite to see which defects it would actually catch.

The implementation is correct and I could not break it. src/SwapCounterHook.sol:14 declares exactly afterSwap, holds no owner and no funds, takes only the pool manager, and returns (IHooks.afterSwap.selector, 0) on every path. Things I tried that did not produce a finding:

• A direct ETH send to the hook (address(hook).call{value: 1 wei}("")) returns false — there is no receive/fallback, so it genuinely cannot hold native currency.
• Third parties cannot inflate the launch pool's count off a foreign pool: a key that matches the launch pool's fields is the launch pool, and any other key hashes to a different PoolId.
• The counting logic is well covered. Mutants += 2, returning a non-zero hook delta, keying on anything but key.toId(), skipping the increment on a zero BalanceDelta, and declaring a second permission are each killed — mostly by the fuzz test at test/SwapCounterHook.t.sol:118, which is doing real work.
• The address assertion at line 35 is not tautological, as I first suspected: it compares against the literal AFTER_SWAP_FLAG, so it fails when permissions change.

Findings, ranked

1. medium — the suite constrains counting but not the contract's external surface (test/SwapCounterHook.t.sol:111). An owner plus an owner-only setCount that rewrites any pool's count and an owner-only token sweep passes all 18 tests. So does a delegatecall fallback() with an admin-settable implementation. Those are the three properties the spec calls out as must-stay-absent. The shipped code has none of them — this is a gap in what future edits get checked against, not a live bug, which is why it is medium and not high. Both mutants are in the findings file verbatim.

2. low — the counter counts callbacks, not exchanges. src/SwapCounterHook.sol:13 says "completed swaps" and the test at line 54 says "the first completed swap counts once", but ten 1-wei buys (swap(key, true, -1, ZERO_BYTES) ×10) cost 10 wei, deliver zero token, and take the count to 10. And vm.prank(address(0xDEAD)); swap(key, false, -1, ZERO_BYTES) — an account with no ETH and no token — returns delta (0, 0), moves nothing, and still increments. Nothing is at stake since there are no funds or authority; the cheap fix is the wording, not the increment.

3. info — the launch configuration is never exercised. Every manager-driven swap in the suite is native-ETH/fee-3000/zeroForOne = true; the manifest launches an ERC20/ERC20 USDC pair at fee 10000. I ran both missing cases in a scratch copy and the hook counts correctly in each, so I recorded the two tests worth adding rather than reporting a defect.

Done. launch.json is written and is the only changed file.

What it declares

{
  "kind": "univ4_hook",
  "hook": {
    "contract": "SwapCounterHook",
    "constructorArgs": ["0xE03A1074c86CFeDd5C142C4F04F1a1536e203543"],
    "permissions": ["afterSwap"]
  },
  "token": { "contract": "LaunchToken", "name": "Swap Counter", "symbol": "SWAPC", "decimals": 18 },
  "pool": {
    "pairedCurrency": "0x1c7d4b196cb0c7b01d743fbc6116a902379c7238",
    "fee": 10000, "tickSpacing": 200,
    "initialPrice": "79228162514264337593543950336"
  },
  "notes": "..."
}

Field choices worth stating:

• permissions: ["afterSwap"] — read off src/SwapCounterHook.sol:19, which returns afterSwap: true and the other thirteen false.
• constructorArgs — the Sepolia v4 PoolManager. Same address the LaunchFactory on chain 11155111 was itself constructed with, so the hook and the pool it is installed on agree on their manager.
• tickSpacing: 200 — canonical spacing for the 1% tier.
• initialPrice — 2⁹⁶ (1:1). The pair is sorted by address and the launched token's address is only fixed at deploy time, so which side it lands on isn't knowable when the manifest is written; 1:1 is the only price that means the same thing in either ordering.
• token — LaunchToken, the one ERC20 in src/, so it resolves against the attested build.

No supply, ownership, allocation or price-policy field is present.

Verification

• Parsed against the real LaunchManifest zod schema from @identitymd/protocol: valid, kind is the first field in the file, no keys stripped as unknown.
• Ran the protected invariant suite against the compiled hook with IMD_HOOK_FLAGS=64 (0x40, AFTER_SWAP_FLAG) — test_permissionsMatchTheDeclaredFlags, test_runtimeCodeHasNoEscapeHatch, test_callbacksRefuseCallersOtherThanThePoolManager all pass. The declared permissions match what the implementation returns and what the mined address carries.
• forge build clean; forge test 18/18 pass.
• git status: ?? launch.json only.

One thing to flag, outside my writable paths

The protected suite only passed once I appended the ABI-encoded constructor argument to the creation code myself. The verifier does not do that — apps/verifier/src/attest.ts:186 passes built.codeByName.get(...) raw, despite InvariantRequest.hookCreationCode documenting "creation code with constructor arguments appended". With the args absent, Solidity's constructor reverts on the short codesize and the suite dies in setUp with hook deployment reverted, which the gate reads as a failed invariant run. apps/deployer/src/plan.ts gets this right via withConstructorArgs, so it is a verifier-side gap that would hit any hook taking a pool manager — i.e. every hook. Nothing the manifest can express differently; the schema has exactly one place for constructor args and it is filled correctly.