Implemented Swarm Pepes (SWARMPEPES): 1,000,000,000 tokens with 18 decimals, minted once to the deployer. Dependencies are vendored; deployment parameters and operational responsibilities are documented in README.md.

Passed with Solidity 0.8.26:

• forge build
• forge test — 30 tests, including four fuzz tests
• forge fmt --check
• Offline rebuild and tests with an empty environment

The external network launch harness remains a separate integration check.

Created launch.json matching the accepted token, exact supply, required pair, and verbatim economics.

Schema and constructor ABI checks passed. forge build succeeded; all 30 local tests passed. Only launch.json changed outside permitted scratch artifacts.

Added test/SwarmPepes.invariant.t.sol with multi-actor random sequences checking supply conservation, balances, allowances, failure rollback, and edge cases.

forge build and forge test pass: 32 tests, including 32,768 invariant handler calls. No defects found. Only test/ changed.

Review complete. .imd-findings.json is written with 0 findings and 8 coverage rows (all 3 listed entry points plus 5 invariant/periphery rows); the working tree is otherwise untouched.

What I checked (Execution Trace, Periphery, First Principles)

The code under review is 16 lines: SwarmPepes is ERC20 with _mint(msg.sender, 1_000_000_000 * 10**18) in the constructor, on OpenZeppelin v5.0.2.

Execution Trace — traced every entry point from calldata to final storage:

• transfer → _transfer → _update: reverts on to == 0 (even for zero value) and on balance < value before any write; exact amount moved; no external calls or callbacks anywhere, so no reentrancy, stale-read, or partial-update surface.
• transferFrom: _spendAllowance runs first; finite allowance decremented exactly, type(uint256).max left untouched; an over-allowance or over-balance call reverts and rolls back both (verified 5→3→3 sequence).
• approve: reverts on zero spender, overwrites, emits.
• Constructor: reproduced the protected harness path — etched a factory at a fixed address, deployed via CREATE2, confirmed the token lands at the predicted address with totalSupply == balanceOf(factory) == 10^27, decimals == 18, and the factory's caller holds 0. Then ran the full launch flow (10% to distributor, pool share via approve/transferFrom, remainder) — every leg arrives whole, factory ends at 0, no residual allowance, supply unchanged.

Periphery — the vendored lib/openzeppelin-contracts closure (5 files + LICENSE) is byte-identical to upstream commit dbb6104 (v5.0.2); I fetched upstream and diffed rather than trusting the self-reported SHA256SUMS. No submodule; ordinary files. Context._msgSender() is plain msg.sender.

First Principles — the only implicit assumptions are (a) the constructor's msg.sender is the factory, which holds under CREATE2 from the factory; (b) 1_000_000_000 * 10**18 equals the manifest supply — it's a compile-time constant evaluating to exactly 10^27 (this disposes of the aderyn "large numeric literal" lead). The compiled ABI exposes only the 8 standard ERC-20 functions plus the INITIAL_SUPPLY view; _mint/_burn are unreachable, and there is no owner, pause, blacklist, initializer, or upgrade path. Runtime opcode scan: no DELEGATECALL/CALLCODE/SELFDESTRUCT/CALL/CREATE/ORIGIN.

Notes that are not defects (recorded in coverage, not as findings): the runtime uses PUSH0 and MCOPY (Cancun target from foundry.toml), so the deploy chain must be Cancun-capable — the chain isn't specified in this task, so I can't name a failing state. No launch.json exists yet, which the brief says is expected at this stage.

Existing suite: 30/30 pass; forge fmt --check clean. Nothing in my area was left unreached.

The review is complete. The findings file at .imd-findings.json holds zero findings and eight coverage rows, and no tracked file was changed.

Result: no defects in the economics area. Swarm Pepes is an unmodified OpenZeppelin v5.0.2 ERC-20 with one constructor mint of 10^27 minor units to the caller. I checked it against the Economic Security, Invariant and Flow Gap guides and found nothing that fails.

What I verified:

• Supply invariants. Total supply can neither grow nor shrink after deployment. The compiled ABI exposes only the standard ERC-20 selectors plus the supply constant, and transfers to the zero address revert.
• Launch flows arrive whole. Factory to distributor, factory to pool, pool to trader, trader back to pool, and distributor claims all move the exact amount. A scratch test with a 97-way claim split and a 1-wei buy/sell round trip conserved the sum of balances. The scratch directory was removed afterwards.
• Constructor and roles. No arguments, no owner, no pause, blacklist, burnFrom or upgrade path. Under CREATE2 from the factory, the factory holds the whole supply and nothing else is created.
• Dependency integrity. All five vendored OpenZeppelin files hash-match the upstream commit named in the vendor README, so no hidden change to balance or allowance logic exists.
• Tool leads. Slither reported nothing. Aderyn's large-numeric-literal note on the supply constant is a style remark, not a defect, and I left it out.

Two notes for the judge rather than findings. First, the standard ERC-20 approve replacement race exists, as in every OpenZeppelin token, and the README documents it. Second, no launch manifest is in the tree, so pool price and allocation inputs could not be checked here. The reference states that an early review does not require one.

Review complete. .imd-findings.json is written with no findings and a full coverage record; the working tree is otherwise untouched (scratch tests live in the gitignored test/scratch/).

What I reviewed

src/SwarmPepes.sol is 16 lines on unmodified OpenZeppelin v5.0.2 (I verified the vendored bytes against SHA256SUMS, all OK). The only custom arithmetic is INITIAL_SUPPLY = 1_000_000_000 * 10 ** 18 minted once to msg.sender.

Coverage by my three guides

Math Precision — mapped every arithmetic site: the constant, OZ _update (checked += on mint; < guard then unchecked -/+ on transfer), and _spendAllowance. No division, no scaling, no downcast, no fee formula exists. The aderyn "large numeric literal" lead resolves cleanly: the constant compiles to 0x33b2e3c9fd0803ce8000000 = 10^27 = 1,000,000,000 × 10^decimals(), exactly the spec.

Boundary — no external calls, no payable function, no receive/fallback (value-carrying calls revert, confirmed), no sentinel branch beyond OZ's address(0) reverts, no bytes decoding. Nothing to exercise beyond input edges, which I did.

Numerical Gap — no seam exists: there is no view/write pair, accumulator, cap, or rate to diverge under rounding.

I confirmed the edges concretely with 16 scratch tests (all pass as the standard requires): 0 / 1 wei / exact-balance / SUPPLY+1 / type(uint256).max transfers, full-balance self-transfer and self-transferFrom, allowance at max (sticky), max-1 (decrements), exact allowance (leaves 0, next wei reverts), allowance above balance (balance-bound, allowance preserved on revert), CREATE2 factory deployment crediting the factory, and fuzzed conservation of sum(balances) == 10^27.

One launch-relevant arithmetic fact worth recording for the judge: 10^27 divides exactly by 10,000 for every poolBps in the schema range [1, 9000], the 1000-bps swarm share (10^26) and its 200/800 split, and supply/1000, so none of the factory/distributor flows in the protected test can lose a wei to truncation; the supply also fits uint128/int128 for the v4 pool.

Limits

I did not run the protected Uniswap v4 harness (it needs network-owned libraries not in this tree), so "a seed and a swap succeed" is covered only by the arithmetic-fit argument above, not an executed swap. Static analysis (slither clean, aderyn one low lead) was treated as leads only.

Review complete. .imd-findings.json is written (valid JSON, 0 findings, 8 coverage rows), the scratch directory is removed, and the working tree is clean apart from the report itself (which git status doesn't show because it's untracked-but-expected output).

Summary

Scope: Access Control, Trust Gap and Asymmetry guides against src/SwarmPepes.sol — a 16-line contract that inherits OpenZeppelin v5.0.2 ERC20 and mints 10^27 units to msg.sender in the constructor.

Result: no defects found. All three listed entry points hold.

What I traced and confirmed:

• Permission model — There is none to break. The compiled ABI exposes only the ERC-20 surface plus INITIAL_SUPPLY(); storage is OZ's five slots with no owner/admin slot; no receive/fallback (bare call and unknown selector both revert); runtime contains no DELEGATECALL/CALLCODE/SELFDESTRUCT.
• Inconsistent-guard check — _balances has a single writer (_update) reachable only via a msg.sender-sourced _transfer, an allowance-checked transferFrom, or the constructor _mint. _allowances is written only by approve() for msg.sender as owner, or decremented in _spendAllowance for msg.sender as spender. The deployer/factory holds the supply but has no power over any other holder.
• Initialization — No initializer; constructor takes no args, so a CREATE2 factory deployment credits the factory, not tx.origin. This matches what the protected test's LaunchProbe requires.
• Asymmetry pairs — approve ↔ transferFrom and transfer ↔ transferFrom write mirror slots; transferFrom(self) still requires a self-allowance (standard OZ, probed). Infinite-allowance non-decrement and no Approval on spend are documented OZ 5.0.2 behavior.
• Supply-chain trust gap — The vendored OZ files are byte-identical to upstream commit dbb6104c (fetched and cmp'd), not just self-attested by SHA256SUMS.
• Static-analysis lead — The "large numeric literal" at line 11 evaluates to exactly 10^27, the stated supply. Style only.

The existing 30-test suite passes, and my four scratch probes (unknown selector, self-transferFrom, deployer-has-no-power, approval scoped to owner/spender) all passed before I deleted them.

Not reached / outside this repo: the protected test's live Uniswap v4 seed-and-swap run needs the network's factory libraries and manifest env vars that aren't in this tree. Since the token has no fee, hooks, or exemptions, nothing in the token itself can short that flow — but that end-to-end run remains the verifier's to execute.

The review is complete. The findings file is written and no tracked files were changed.

Outcome: the Swarm Pepes token has no reproducible defect. All five specialists reported nothing, and my own pass agrees. The only item I recorded is an informational documentation mismatch.

What I verified against the code

• The token is OpenZeppelin v5.0.2 ERC20 plus a constructor that mints the whole supply to the caller. The five vendored library files are byte-identical to the upstream commit and are committed as ordinary files, not a submodule.
• The constructor mint equals the manifest's totalSupply exactly, and decimals are 18 in both. The constructor takes no arguments, matching the manifest's empty argument list.
• The three entry points approve, transfer and transferFrom are unmodified library code. They move exact amounts, revert atomically, and touch neither supply nor other holders. The launch flows the protected test exercises therefore arrive whole.
• The compiled runtime contains no DELEGATECALL, CALLCODE, SELFDESTRUCT, CALL, STATICCALL or CREATE. No owner, pause, blacklist, mint or upgrade function exists.
• The manifest's initialPrice recomputes exactly to the stated formula. The economics block could not be checked against the original job, since the job's economics are not in this task's inputs.
• The aderyn large-numeric-literal line is a style lead only. The literal evaluates to exactly 10^27.
• The project's own 32 tests build and pass under Foundry 1.8.3 with solc 0.8.26.

Reported finding

1. Info. README line 49 states that no launch manifest is supplied, but launch.json is committed at the repository root. Documentation only, no code impact.

Coverage record: all three listed entry points marked holds, plus eight invariant rows covering supply, launch flows, privileged calls, bytecode opcodes, dependency integrity and decimals. No proof file was written because nothing reached high or critical severity.