Created launch.json matching the accepted contracts and constructors.

Schema and ABI checks passed. forge build succeeded; all 38 tests passed.

Notes preserve the IMD/native-ETH pairing conflict; the manifest uses required native ETH. No other deliverable files changed.

I found no permission defects I could reproduce. .imd-findings.json has an empty findings list and a coverage row for each of the 7 entry points, all holds. It also has 3 extra rows for things I checked across the code. The file is valid JSON and no tracked file changed.

The suite passes: 38 of 38 tests. I didn't write any proof tests, since there were no high or critical findings to prove.

Access Control

• No roles anywhere. None of the three contracts has an owner, setter, initializer, proxy or upgrade path. SwarmSeller's two constructor addresses (the Uniswap v4 PoolManager and IMD) are fixed at deployment and must be non-zero and different. They match the approved workflow and the README. No $owner argument exists, so there is no privileged beneficiary to check.
• Seller pulls: The seller spends allowances in only one place, a transferFrom(msg.sender, …) call. No call path lets a caller spend someone else's approval.
• executeSale can only be called by the seller itself. Passing the seller's own address as the token to sell just fails at the pull. The PoolManager and the harvester don't have the matching transferFrom, so passing them fails the same way.
• unlockCallback only accepts the PoolManager as caller, and only for the one sale currently in progress, which it marks used before making any outside call. A hostile pool hook or token that calls back in is refused.
• Harvester: anyone can call it, as the workflow intends. It passes the beneficiary through unchanged, holds no tokens or approvals, and skips the zero address and itself as beneficiaries. The real distributor already lets anyone claim for anyone directly, so going through the harvester grants nothing new.

Trust Gap

• No privileged actor exists, so no one can redirect fees or in-flight value.
• The pools, hooks and minimum outputs are chosen by the caller, who only ever risks their own tokens.
• Reentrancy:
  • While the PoolManager is unlocked, a hostile token or hook can't take the seller's balance with the PoolManager, because the PoolManager tracks balances per caller.
  • sellMany blocks reentry.
  • The callback check above blocks a forged or repeated callback.

Asymmetry

• Refunds go back to the same caller the tokens were pulled from.
• A failed pull skips that row. A failed swap is rolled back and refunded. A failed refund reverts the whole batch.
• The sale data is encoded before the swap and decoded in the callback the same way.
• The fee is computed once per batch as gross output ÷ 200 (0.5%, rounded down) and sent to the dead address.
• The ABI files in docs/abi/ match the compiled ABIs exactly.

Leads I checked and left out

• Slither "calls in a loop": intentional batching; each call has a gas cap and failures are caught.
• Slither "uses timestamp": it's the caller's own deadline check.
• Aderyn "unused error": InvalidSale is declared but never used; that's cosmetic.
• Aderyn "unsafe ERC20": the raw transferFrom call's return value is checked.
• Tokens that return false instead of reverting: one such row aborts the whole batch instead of being skipped. The contract comments and README document this, and the standard launch tokens revert rather than return false.
• Fake ClaimResult events: a contract posing as a distributor can make the harvester log a success. The README already tells frontends to use only verified distributors.

Not covered: I didn't re-run the optional mainnet fork test or trace PoolManager internals beyond what the permission questions needed. There is no launch.json yet, so the manifest's constructor arguments still need review once it exists.

The review is complete. The findings file is written at the repository root, the scratch tests are removed, and no tracked file was changed.

Outcome. The math, boundary and numerical-gap area is clean apart from one info-level deviation. I found no precision, overflow, downcast, zero-rounding or boundary defect that loses funds or breaks the contracts.

The one finding (info). The seller's burn is computed as floor of gross divided by 200, once per batch, at src/SwarmSeller.sol:92. Any batch with aggregate gross below 200 wei of IMD burns nothing, and every batch under-burns by up to 199 wei against the "exactly 0.5%" wording in the workflow. I reproduced it on the real vendored v4 core: a 150-wei sale yields gross 148, fee 0, net 148. Impact is dust with no victim, since the fee goes to the dead address and 199 wei is far below the gas cost of splitting batches. The requester can accept the floor semantics the README already documents, or round up.

What I verified in depth, mostly by running edge inputs against the real Uniswap v4 PoolManager rather than the mocks:

• 1-wei input: v4 rounds the whole input into fee, output is zero, the seller rejects it and refunds.
• Maximum accepted input of int128 max: no overflow anywhere; a deep pool legitimately consumes it all at a poor price, which only the caller's own minimum bounds.
• Thin pool hitting the price limit: partial fill is rejected and refunded.
• Empty second hop on the ETH route: both hops roll back, no ETH credit or token remains.
• Inclusive deadline, fee boundary at 199 and 200, fee plus net equals gross exactly.
• The harvester's 200k claim gas budget against the mainnet distributor replay, which used 87,735 gas including a cold recipient transfer.
• Mainnet IMD is a non-proxy 18-decimal ERC-20; the single CALLCODE byte the disassembler reports sits inside the compiler metadata trailer.
• The three exported ABI files are identical to the compiled ABIs.

Coverage record. All seven listed entry points have rows, six as holds and sellMany as finding pointing at the info item, plus five rows for the invariants and boundaries I checked. Nothing in my area was left unreached.

Leads outside my area, not reported as findings. Mainnet IMD exposes an owner, the same address as the launch treasury. Whether that owner can add transfer restrictions that would brick the seller's IMD payout is a trust-gap question for the token-behaviour reviewer, not a defect in this code.

The findings file is in place at the repository root, scratch tests are removed, and no tracked file was changed.

Outcome: no substantiated defects in the control-flow area. The file .imd-findings.json holds an empty findings list and a coverage record with 12 rows: all seven listed entry points, three invariants from the brief, the ABI exports, and the not-yet-written manifest.

What I traced, against the Execution Trace, Periphery and First Principles guides:

• SwarmSeller.sellMany pulls only from msg.sender through a one-word raw call, validates every row before any pull, isolates each swap behind the self-only executeSale boundary, and refunds or reverts atomically. The fee is computed once per batch from PoolManager-signed deltas, not balance snapshots. The reentrancy guard spans every external call.
• unlockCallback is bound to the immutable PoolManager and to the hash of the single pending sale, which is consumed before any swap. Each hop must spend exactly its input and receive a positive amount, so hook deltas and partial fills cannot leave stray credit. Settle is checked to equal the input and take exactly matches the output, so the v4 non-zero-delta check passes.
• SwarmHarvester.claimMany holds no state and no tokens, forwards the account unchanged, and catches reverts, return bombs and out-of-gas distributors without copying returndata.
• LaunchToken is plain OpenZeppelin v5.1.0 ERC20 minting exactly one billion tokens to the deployer.
• ABI exports under docs/abi match the compiled ABIs exactly. No git submodules are present.

I confirmed two edge cases against the vendored real v4 PoolManager with scratch tests: a thin narrow-range pool where the price limit is hit yields a refund with no custody left, and a hook with afterSwapReturnDelta that strips the whole output also yields a refund with the hook keeping nothing.

Leads I looked at and chose not to report, since each is self-affecting or documented: the fixed 2M gas cap per sale and 200k per claim can make a large or expensive row fail and refund; a token that returns false on a failed pull aborts the whole batch rather than skipping the row; batches with gross output under 200 wei pay zero fee because of the once-per-batch floor; the constructor does not check that the two addresses hold code, which the manifest reviewer must verify since adding that check could break the offline deployment floor.

Not reached: the launch.json manifest does not exist yet, and the mainnet PoolManager and IMD addresses could not be verified on chain in this offline review.

The economics review is complete. The findings file at .imd-findings.json holds an empty findings list and 11 coverage rows. No source files were changed, and the scratch probe was deleted.

Result: no economic defect substantiated. I covered the Economic Security, Invariant and Flow Gap guides against both application contracts and the token, and every listed entry point has a holds row with its evidence. The one unreached row is the launch manifest, which does not exist in the tree yet.

What I verified beyond reading:

• Seller value flow on the real v4 core. Scratch tests against the vendored PoolManager showed liquidity exhaustion is rejected and refunded rather than paid short, a thin second hop rolls back the first hop with no ETH credit left, and a mixed batch applies the aggregate minimum only to surviving rows with fee plus net equal to gross.
• Hook accounting. From Hooks.beforeSwap and afterSwap, a hook that takes an input or output fee still charges the seller exactly its input and only lowers the output, which the per-sale minimum bounds. The seller's exact-input check therefore catches partial fills, not hook fees.
• Mainnet dependencies. Both constructor addresses have code. IMD is a LayerZero OFT-style ERC20 whose owner powers are cross-chain config only, transfers to the dEaD sink and to the PoolManager succeed in simulation, and the PoolManager already holds IMD.
• Harvester cap. The fork replay of launch #953 passed, and the real distributor's claim costs 87,735 gas, inside the 200k cap, paying only the leaf account.
• Existing suite and ABI exports. All 38 tests pass, and the three ABI files in docs/abi are byte-identical to the compiled ABIs.

Two documented limits are worth the author's attention but are not defects: a fee-on-transfer input reverts the whole batch instead of refunding that row, and a recipient set to the PoolManager strands the payout. Both are caller-chosen inputs. When the manifest is produced, the reviewer at that stage must confirm the seller's two arguments are the literal mainnet addresses and that the paired currency is IMD.

Added 18 tests under test/ covering failure paths, refunds, rollback, proof validation, and fee boundaries.

The new four-wallet invariant exercises 16,384 random calls against local Uniswap v4.

Validation passed offline: forge build and all 56 tests, with zero failures or skips.

No reproducible contract defects found. Live mainnet fork tests were not run.

Review complete. The findings file is written and the working tree is otherwise unchanged.

Outcome. The three contracts hold up. The specialists' only finding reproduces but stays informational. The one material defect is in the manifest, not the source.

Findings written to .imd-findings.json

• Medium, launch.json line 23. The pool is paired with native ETH while the approved workflow decision and the accepted README both pair HARVEST with IMD. The manifest's own notes admit the conflict is unresolved. No network.json was supplied, so the exact pair-token address could not be confirmed from a pinned source. The fix belongs to the manifest step, which must set pairedCurrency to the network's IMD pair token, or the requester must amend the decision to ETH.
• Info, SwarmSeller line 92. Merged from audit_math. The 0.5% burn is floor(gross / 200) per batch, so sub-200-wei batches burn nothing. I reproduced it against the vendored real v4 PoolManager: a 150 wei sale produced 148 wei gross, zero burned. Impact is dust to a dead address, and the README already documents floor semantics.

What I verified myself

• Full suite passes: 56 tests including real v4 integration and two invariant suites.
• All three exported ABI files match the compiled ABIs exactly.
• Seller callback authentication, exact-fill checks, settlement equality, refund atomicity, and the reentrancy guard across pulls, swaps, fee and payout all trace as intended.
• Harvester custody, the code-length guard that avoids an uncaught extcodesize revert, and the 200k claim budget hold; the committed fork replay covers the real distributor.
• Constructor arguments match the workflow's PoolManager and IMD addresses in order, with no privileged beneficiary.

Coverage. All 7 entry points answered, plus 4 invariant and manifest rows. Static-analysis leads (calls-in-loop, timestamp, unsafe ERC20 call, unused error) were checked and are intentional or cosmetic, so none were kept.

Recorded a disputed verdict in .imd-responses.json.

The discrepancy reproduces, but switching to IMD violates this assignment’s explicit native-ETH requirement. launch.json remains unchanged; the pairing conflict remains unresolved.

Schema and ABI checks passed. forge build succeeded with lint warnings; all 38 tests passed.

The review is complete and written to .imd-findings.json. No tracked files were changed and the scratch directory is empty.

Outcome. The one blocking finding is not fixed. The advisory stands unchanged. Nothing new was found.

Pairing conflict, medium, still open. The manifest is byte-for-byte what I reviewed last round, with the pool paired to native ETH. The approved workflow decides "paired with IMD" twice and the accepted README says the same. The author did not dispute the discrepancy. They answered that their manifest assignment required native ETH only, so they left the file alone. I accept that they acted within their instruction, and there is no network.json in the tree to pin a pair-token value. But the launch this manifest describes is still not the one the requester approved: it opens a HARVEST/ETH pool under the ETH opening cap, while the README and site will publish an IMD pairing. The launch rules given to me allow the chain's pair token when the request chose it. The rule quoted by the author allows ETH only. Those two platform instructions conflict, and the manifest contributor cannot resolve it. The finding names the two ways to close it: the services confirm the chain 1 pair token and the manifest step re-runs with it, or the requester amends the decision to ETH and the README and frontend route follow.

Fee rounding, info, unchanged. The seller source has not changed, so the per-batch floor still burns nothing below 200 wei of gross IMD. I merged the math specialist's duplicate into it. The tester's new threshold test now pins that floor behaviour, so it is documented rather than accidental.

Verification run this round:

• Full project suite: 56 tests pass, including the two new invariant suites.
• Protected token floor: 7 of 7 pass with the real creation code.
• Protected project floor: 2 of 2 pass with CREATE2 deployment of both applications using the manifest's constructor arguments, supply preserved, no forbidden opcodes.
• ABI exports under docs/abi match the compiled ABIs entry for entry.

Coverage. All seven listed entry points are answered. Six hold. The seller's batch entry carries only the advisory rounding note. Three extra rows cover the manifest pairing, the constructor arguments, and the ABI exports. The static-analysis leads were all intentional design choices or cosmetic, and none reproduced as a defect.

Recorded disputed in .imd-responses.json.

The pairing discrepancy reproduces, but changing to IMD violates this assignment’s explicit native-ETH requirement. Left launch.json unchanged; the policy conflict remains unresolved.

Schema and constructor checks passed. forge build succeeded; all 38 tests passed.

The review is complete and the findings are in .imd-findings.json. The working tree is clean, with no scratch files and no source changes.

Outcome. Both prior findings are settled as unchanged, and nothing new was found. The source, tests, ABI exports and manifest are byte-identical to the previous round. The build succeeds and all 56 tests pass, including both invariant suites.

• Medium, still open: the manifest pairs the HARVEST pool with native ETH while the approved decision and the accepted README pair it with IMD. The author reproduced the discrepancy and answered that their manifest instruction forbids any value other than ETH. I accept that they acted within scope, and no network.json exists in the tree to pin a chain pair token. The conflict between the two platform instructions cannot be resolved by any contributor in this stage. It closes only when the services confirm the IMD pair token and re-run the manifest step under a rule that permits it, or when the requester amends the decision to ETH and the README and frontend follow.
• Info, advisory: the seller's fee rounds down once per batch, so batches under 200 wei of IMD burn nothing. The README documents floor semantics and a committed test pins it. The audit_math specialist's finding is the same root cause and is merged here.

Coverage. All seven entry points are answered, plus three invariant rows. Six hold, one carries the info advisory, and the manifest pairing row carries the medium finding. The static analysis leads were checked and none reproduced as a defect: the loop calls and timestamp use are the intended design, and the unused error declaration has no behavioural effect.

Next. The launch is blocked only by the pairing decision, which needs a requester or service answer rather than a code change.