Completed the source contribution:

• Restored pinned contracts and tests unchanged.
• Corrected documentation to HARVEST/native ETH; SwarmSeller still outputs IMD.
• Included vendored dependencies and verified ABI exports.
• Passed forge build, all 56 tests, and forge fmt --check.
• Confirmed clean offline builds and tests with an empty environment.

Manifest generation, independent launch review, and deployment remain separate stages.

Created launch.json with HARVEST metadata, matching application constructors, and native-ETH pool settings.

Schema and ABI checks passed. Offline forge build succeeded with existing lint warnings; forge test passed all 56 tests.

Only launch.json is included in the deliverable.

I found no defects I could reproduce, so .imd-findings.json has an empty findings list and a coverage record. That record has a row for all 7 entry points, all marked holds, plus 6 rows for invariants and economic checks. I changed no other files; the findings file is excluded from git through .git/info/exclude.

What I covered (Economic Security, Invariant and Flow Gap):

• SwarmSeller.sellMany and its helpers:
  • Who pays: only the caller's tokens are pulled. No other wallet's approval can be spent, and calling back in is blocked.
  • Where the IMD goes: the IMD taken from the pool manager equals what the recipient gets plus the 0.5% burn (floor(G/200)). Gifts sent to the contract are never counted or paid out.
  • Swaps: every hop must use its whole input, and the ETH from the first hop is fully used by the second. A sale that fails gets its tokens refunded, and a failed refund reverts the whole batch.
  • Slippage: the per-sale minimum (before the fee) and the batch minimum (after the fee) are both enforced, and the deadline is inclusive.
  • Splitting batches to dodge the fee: only batches under 200 wei of IMD skip the fee, which is dust; the fee is voluntary by design anyway.
• Pool hooks and tokens: I checked malicious or delta-returning hooks and malicious, fee-on-transfer and no-return tokens. They can only revert or refund the caller's own batch. Fee-on-transfer tokens reverting a batch is a limit the README already states.
• SwarmHarvester.claimMany: I ran the optional mainnet fork test against the real distributor (0xdc54…916f). A real claim uses 87,735 gas, under the 200,000 cap. Claims with a changed round, a redirected account or a repeat all fail and are skipped. The harvester never holds tokens.
• Constructor inputs, checked live on mainnet:
  • The PoolManager 0x0000…4444c5dc…A90 has deployed code.
  • IMD 0xd34a…63b7 returns symbol IMD and 18 decimals.
  • Neither contract grants an owner or privileged role.
• LaunchToken: it is a plain fixed-supply OpenZeppelin ERC-20.
• Static-analysis leads: I checked each one. External calls in loops and the timestamp comparison are intentional, with gas caps and a caller-set deadline. The rest are low-level style notes with no way to cause harm.

What I didn't verify:

• There is no launch.json in the tree yet, so I couldn't review the manifest's constructor arguments.
• I didn't check whether a mainnet ETH/IMD pool exists with enough liquidity for the two-hop route. If none exists, ETH-paired launch tokens, including HARVEST, can't be sold through SwarmSeller.

The full suite passed: 56 tests, 0 failed.

The review is complete. The findings file is written and valid, and the working tree holds nothing but it (only build output, which is gitignored).

Result: no reproducible defect in the Math Precision, Boundary or Numerical Gap area. The file .imd-findings.json holds an empty findings list and a 12-row coverage record, all holds, covering every listed entry point plus five invariants and the ABI exports.

What I checked, in depth:

• Fee arithmetic. The burn is computed as gross divided by 200, which equals floor of gross times 50 over 10,000 exactly, because 50 divides 10,000. No intermediate overflow is possible. The net amount cannot underflow. A fee of zero occurs only for a gross output below 200 wei of IMD, which is dust and is explicitly asserted as intended by an existing threshold test.
• Signed casts and swap deltas. Sale input is capped at the int128 maximum before any cast. The second hop's input is a positive int128 output, so it fits too. The exact-spend check rejects partial fills, hook-paid input and zero output. I traced the v4 PoolManager and Hooks sources to confirm the delta returned to the seller already includes any hook fee, so hook deltas cannot bypass the accounting.
• Settlement boundaries. The seller requires settle to return exactly the pulled amount, so fee-on-transfer or rebasing inputs are rejected and refunded. Token, native ETH and IMD deltas each net to zero inside the manager, so the manager's unsettled-delta check cannot strand value.
• Return-data boundaries. The raw pull copies at most one word, accepts void returns, and reverts the batch on a false or malformed success, so a lying token cannot leave a half-moved state.
• Harvester. Codeless distributors and zero or self accounts are skipped, each claim gets bounded gas with no returndata copy, and the harvester never custodies tokens.
• Token and ABI. LaunchToken is an unmodified OpenZeppelin ERC20 with a fixed 1e27 supply. All three ABI files in docs/abi are byte-identical to the compiler output.

The existing 56-test suite, including the real v4 core integration tests and both invariant suites, passes offline. No files other than the required findings file were created, and no scratch tests were left behind.

Added 11 tests covering allowance invariants, malformed token responses, refunds, and batch rollback.

forge build and offline forge test pass: 67 passed, 0 failed, 0 skipped.

Only test/ files were added. No reproducible defects were found in these cases. Live mainnet integration remains unverified.

The review is complete. No reproducible defects were found in the Access Control, Trust Gap or Asymmetry areas, and .imd-findings.json records an empty findings list with coverage rows for all seven entry points plus five invariant and configuration rows. The working tree is clean and the scratch directory is removed.

What I checked

• Permission map. The seller has three entry points. Only the batch entry spends allowances, and it hard-codes the caller as payer. The self-call helper is guarded by a self check and has no payer parameter. The pool callback requires the real manager plus a hash match that is consumed before any external call. The harvester has no storage, approvals or balances, so there is no privilege for a confused deputy to borrow.
• Trust gap against real Uniswap v4. I wrote scratch probes against the vendored PoolManager with a flagged hook. A hook that reenters all three seller entry points mid-swap failed on all six attempts across a two-hop route. A hook that skims output via an afterSwap return delta had its cut reflected in the signed delta, with no stranded balance or delta in the seller. A hook that leaves an unsettled delta fails only its own row and the input is refunded.
• Asymmetry. Validation versus execution of a sale is bound by the encoded hash. Per-row minimum is gross and batch minimum is net, consistent with the README. Refunds are atomic with the batch. Donations are neither swept nor counted. Supplying the seller or the PoolManager itself as the input token is skipped at the pull with no side effects.
• Constructor and beneficiaries. The seller's two immutable arguments match the approved workflow addresses, the fee sink is the brief's dead address, and no owner or msg.sender role exists anywhere.
• ABI documentation. All three exported ABI files match the compiler output.
• Baseline. The full suite passed, 56 of 56 tests, including the real v4 integration and both invariants.

Notes that are not findings

• SwarmSeller declares an unused error, InvalidSale, at line 39. It appears in the ABI but has no behavioural effect.
• Anyone can trigger a claim for any account. This matches the brief and is a trust assumption on the deployed distributor's unlock semantics, which could not be verified offline.
• The static analysis leads (calls in loops, event ordering, timestamp deadline, unsafe ERC20 operation on the raw pull) were each traced and are intentional or guarded.

Not reached. Live mainnet state for IMD, the deployed distributor, and actual pool hooks was not checked, since the review runs offline. No launch.json exists yet in the tree, so manifest linkage was reviewed only through the README's stated constructor values.

The review is complete. The findings file is written with an empty findings list and a full coverage record, and the working tree is unchanged apart from that file.

Outcome: no reproducible defect found. I traced all seven entry points from my three guides (Execution Trace, Periphery, First Principles) and could not construct a failing input against any of them.

What I verified beyond reading the code

• Full suite passes: 56 tests including the real v4 PoolManager integration and both invariants (4,096 and 16,384 handler calls). Formatting check passes.
• Optional mainnet fork replay re-run and passes: the harvester, calling the live distributor at block 26,145,141, rejects a wrong round and a redirected account, pays the named account in full, and skips the duplicate. The README noted this was not rerun for this contribution. It now has been.
• Vendored libraries are not tampered: I downloaded the four upstream archives (hashes equal to the ones recorded in docs/dependencies.json) and compared every vendored file with whitespace stripped. Only Hooks.sol differs, by braces around a single return. The 17 mismatched hashes the implementer mentioned are purely reformatting.
• ABI exports match the compiler output for all three contracts.
• Constructor dependencies exist on mainnet: the PoolManager address carries the unlock, swap, sync, settle and take selectors the seller calls. The IMD address is the verified, non-proxy, OpenZeppelin-based "Identity.md" token, and a simulated transfer to the dead address succeeds, so the fee burn cannot brick batches.
• Two-hop route has a venue: a hookless ETH/IMD v4 pool at fee 3000 and tick spacing 60 exists, which the HARVEST sale needs since the launch pool pairs with ETH.
• Protected floors: all three runtimes are under the size limit with no forbidden opcodes, and the token mints exactly 10^27 to its deployer.

Checks that held under adversarial tracing: callback authentication and single-use hash binding, exact-input enforcement under v4 hook delta accounting, native credit netting inside the manager, settlement equality, refund atomicity, the one-word return check on the raw pull, nonReentrant coverage of every external call, and the impossibility of sweeping or counting donations toward output.

Static-analysis leads (calls in loops, reentrancy-events, timestamp, raw ERC20 call, unused error) were each reviewed and have no failing input, so none is reported.

Open items for other roles, not defects: the manifest assignment must still write launch.json with the token, SwarmHarvester with no arguments, and SwarmSeller with the PoolManager and IMD addresses in that order. The frontend must use exact deployed pool keys, including the hook address, since the seller accepts them verbatim.

The review is complete. The findings file is written and the tree is otherwise untouched (the findings file is gitignored, and my scratch probe was removed).

Outcome: no critical, high or medium defects. The four specialists and the tester reported nothing, and my own pass over the code confirms that. I reported two minor items.

What I verified myself

• Built and ran the full suite: 67 tests pass, including the real vendored Uniswap v4 PoolManager integration and both invariant suites.
• Traced the seller's callback against the vendored PoolManager: exact-input full-fill is enforced by the spent check, the native credit from hop one nets to zero inside hop two, and token, native and IMD deltas all close before unlock returns. The callback is bound to the pending sale hash and consumed before any external call, so hooks cannot reenter.
• The only allowance spend is a transferFrom from msg.sender; the seller never approves anyone. Failed swaps refund exactly the pulled amount, and the aggregate minimum reverts the whole batch.
• Over public mainnet RPC: the PoolManager address has code, the IMD address reports symbol "IMD" with 18 decimals, and the launch distributor cited in the README answers the claim selector, token, treasury and claimed queries as documented.
• On a mainnet fork: IMD transfers and transferFrom move exact amounts with no supply change, and the dead address accepts transfers, so the burn path works.
• The three exported ABI files equal the compiled ABIs. The manifest validates against the supplied schema, has no reserved or duplicate names, and matches the pinned prior manifest in every field except one.
• No git submodule links in lib, and the docs no longer carry the IMD-pair wording.

Findings recorded

1. Low, launch.json line 17. The PoolManager constructor argument is now in mixed-case EIP-55 form, where the previously accepted manifest used lowercase. The address is semantically correct, but the schema's only address pattern is lowercase-only and the private refinement rules could not be inspected. Restoring lowercase removes the risk at no cost.
2. Info, SwarmSeller.sol line 39. The custom error InvalidSale is declared and exported in the ABI but is never raised. No behavioural impact, and the workflow forbids changing the seller, so it is documented only.

Coverage: all seven listed entry points answered as holds, plus three invariant rows (no allowances, manifest validity which points at finding 1, and ABI equality).

Built the frontend, static export, and validation evidence. Build, typecheck, 9 tests, and browser checks pass. Complete Git bundle: 1.80 MiB.

Upstream CORS and RPC-history restrictions remain; the import fallback is tested. Workspace Git is read-only, so delivery files are ready for publisher capture.