Implemented Swarm Sticker (STICK): 1 billion tokens, 18 decimals, minted once to the deployer, with no fees, further minting, or owner powers.

Added vendored dependencies, success/failure tests, fuzz tests, stateful invariants, and deployment documentation covering the 88% pool allocation and 10 ETH starting market cap.

Verified with Solidity 0.8.26:

• forge build
• forge test
• forge fmt --check

All passed, including a fresh offline build and tests with an empty environment. Actual Uniswap v4 integration remains for the independent launch verifier.

Created launch.json with the exact supply, economics, and accepted constructor arguments.

Schema and ABI checks passed. forge build succeeded; forge test passed all 32 tests. Only launch.json changed for submission.

Review complete. The findings file is written at .imd-findings.json with one low finding and eight coverage rows, and no repository file was changed.

Outcome in my area (Access Control, Trust Gap, Asymmetry): no defects. The token is a 13-line subclass of OpenZeppelin 5.1.0 ERC20 with no overrides, and the vendored OpenZeppelin files are byte-identical to upstream. The compiled ABI exposes exactly the nine standard ERC-20 selectors, with no constructor arguments, fallback, receive, owner, pause, blacklist or minter slot in storage, and the runtime has no DELEGATECALL, CALLCODE or SELFDESTRUCT. There is no role, modifier, initializer or branch keyed on the caller, so every holder class (factory, distributor, PoolManager, trader) takes the same transfer path and every launch flow moves exactly what it says. The deployer cannot pull a holder's balance without allowance. The only trust assumption is that the factory, which holds the whole supply after construction, performs the split off-token, which is the launch design rather than a token defect. All 32 existing unit, fuzz and invariant tests pass.

One low finding, outside my area but reproducible. DEPENDENCIES.md says the vendored libraries are unmodified and tells the reader to prove it with the checksum file. That command fails on seven forge-std files. The checksum file records the real upstream v1.9.4 hashes, but the seven local files were re-wrapped by the formatter. I confirmed the differences are whitespace only, so the assertion library is intact and test results stand. The fix is to restore the upstream bytes or regenerate the sums and reword the claim, and to keep lib out of forge fmt.

Not reached: the network's protected harness (pool initialization, seeding and swaps against a real Uniswap v4 PoolManager) cannot run in this tree because its dependencies and environment are not present. It is recorded as unreached in the coverage record.

The review found no defect in the token's control flow and one low-severity defect in the vendored test library. The report is in .imd-findings.json at the repository root, with one finding and eight coverage rows. No tracked file was changed.

The finding (low). DEPENDENCIES.md line 11 says the vendored files are unmodified and tells the reader to confirm it with a checksum command. That command fails for forge-std:

sha256sum --check lib/forge-std/SHA256SUMS
sha256sum: WARNING: 7 computed checksums did NOT match

The listed hashes are upstream's, so the committed files are what changed. I fetched the seven upstream files and compared them with whitespace stripped. The differences are whitespace only, so tests and production bytecode are unaffected. The defect is that the stated provenance guarantee does not verify on this commit.

Coverage of the three entry points. All three hold.

• approve writes only the caller's own allowance, rejects a zero spender, and makes no external call.
• transfer always debits the caller, rejects a zero recipient so the burn branch is unreachable, and moves the exact amount with no fee.
• transferFrom checks and decrements the allowance before moving funds. Only the maximum value is treated as infinite, and only the owner can set it. A later revert restores the allowance.

Other rows I recorded.

• Constructor: mints exactly 10^27 units once to the caller and hands out no roles or approvals.
• Supply: total supply is constant and cannot grow, because the mint function has no caller outside the constructor.
• Runtime code: it contains no external call, delegatecall, create or selfdestruct opcodes. It does use PUSH0 and MCOPY, so the target chain must support Cancun, which Uniswap v4 already requires.
• OpenZeppelin: the five vendored files are byte-identical to upstream v5.1.0 at the pinned commit.

How I verified.

• The existing suite passes: 32 tests, including the invariant run.
• A temporary scratch test with nine extra cases also passed and was then deleted. It covered aliased sender, recipient and spender, the allowance sentinel boundary, malformed calldata, and value sent with a call.
• The finding's snippet was checked against the tree and matches.

Not done.

• I did not run the protected launch harness, because it needs the network's factory and Uniswap v4 sources, which are not in this tree. The seed and swap flows were assessed by reading the token code only.
• No launch manifest exists yet, so constructor arguments and pool fields in it were not reviewed.
• Math precision, economics and access-control guides were outside my assigned area and received only incidental coverage.

The review is complete and written to .imd-findings.json. The token's math holds; the only reproducible defect is a documentation claim outside my area.

Outcome of the math, boundary and numerical-gap audit

The contract is a single OpenZeppelin v5.1.0 ERC-20 with one constructor mint and no overrides, so there is no division, scaling, fee or cast arithmetic to go wrong. I traced each of the three entry points through the vendored OpenZeppelin code and exercised the boundaries with a scratch Foundry suite that I then removed:

• Supply constant is exactly 10^27, matches the manifest's minor-unit string, and divides evenly by 10^18. Decimals default to 18.
• Launch splits of 10%, 88% and 2% in basis points are exact with zero remainder, and the 2%/8% sub-splits of the swarm share are too.
• Opening price from a 10 ETH cap over one billion tokens derives exactly to a sqrt price of 10^4 times 2^96, inside Uniswap v4's bounds, and matches the README's stated per-token price.
• Transfer and transferFrom behave correctly at every edge I fed them: whole supply in one call, supply plus one, max uint, zero amount, self-transfer, allowance of max minus one versus max, and allowance exactly equal to amount. Balance sums stay at 10^27 under fuzzing.
• Boundary surface is empty: no external calls, no payable paths, no bytes decoding, so no boundary corner case applies.

One info-level finding, outside my area. The dependencies document says the vendored forge-std files are unmodified and tells readers to verify with the shipped checksum file, but that check fails for seven files. I fetched the pinned upstream commit and confirmed the differences are whitespace-only reflows from the project's formatter. This has no effect on the token or its bytecode, since forge-std is test-only, and the OpenZeppelin checksums all pass. The fix is either to restore upstream bytes or regenerate the checksum file and reword the claim.

Coverage. All three listed entry points are marked holds, plus five invariant rows covering supply, splits, price derivation, boundary surface and numerical-gap seams. Nothing was left unreached. The existing suite of 32 tests and the invariant run pass, and forge fmt --check is clean.

The review is complete and the findings file is written.

Outcome. The token's economics hold. src/SwarmSticker.sol is a 13-line, unmodified OpenZeppelin v5.1.0 ERC-20 that mints the full supply once to the deployer. I found no defect in the Economic Security, Invariant or Flow Gap areas. One low-severity provenance defect outside my area is reported.

What I checked in the assigned area

• Conservation and supply growth. The only mint is in the constructor. No public path reaches _mint, _burn or _update. The existing stateful invariant suite plus a scratch fuzz confirmed sum of balances equals total supply after any sequence.
• Launch flows arrive whole. Transfers move exactly the stated amount with no fee, burn, hook or callback. I modelled the PoolManager's sync-and-settle pattern in a scratch harness. The factory-to-distributor, distributor-to-claimant, factory-to-pool, pool-to-trader and trader-to-pool legs all credited exactly, and the factory ended at zero.
• Split arithmetic. The 10 percent, 88 percent and 2 percent shares of 10^27 minor units divide with no rounding dust.
• Opening price. With ETH as currency0 the implied sqrt price and tick for a 10 ETH cap sit comfortably inside Uniswap v4 bounds, and the single-sided liquidity fits uint128. That derivation is the deployer's, and nothing in the token constrains it.
• Dependency integrity. The five vendored OpenZeppelin files match both their checksum file and the upstream commit byte for byte.

The one finding (low). DEPENDENCIES.md says the vendored forge-std files are unmodified and verifiable with its checksum file, but seven of them fail that check. Diffing against upstream v1.9.4 shows whitespace-only drift from a later forge fmt run. No deployed code is affected since forge-std is test-only, but the documented offline provenance check is broken. The fix is to restore the byte-exact upstream files or regenerate the checksum file and say so.

Leads not reported. The aderyn large-numeric-literal note is style only. The standard ERC-20 approve race is documented in the README and is not a defect.

Coverage. All three listed entry points are marked holds, with nine additional rows for the invariants and economics checks above. The scratch test directory was removed and no project file was changed.

Extended tests under test/ with allowance failure paths, maximum-value cases, fuzz properties, and stateful invariants.

Validation passed:

• forge build
• forge test: 46 passed, 0 failed
• 24,576 invariant handler calls

No defects found. Protected pool integration was not run because its external launch infrastructure is absent.

The review is written to .imd-findings.json: two findings, both documentation-level, and no defect in the token itself. No tracked files were changed.

Findings

1. Low — the documented forge-std checksum check fails (DEPENDENCIES.md:12). All four specialists reported this; I merged them into one finding and reproduced it. sha256sum --check lib/forge-std/SHA256SUMS fails on 7 files. The recorded hashes match upstream at the pinned commit, so the committed files were changed, and the changes are whitespace-only. This affects test tooling only; the OpenZeppelin files the token compiles from are byte-identical to upstream v5.1.0.
2. Info — README is stale against the tree (README.md:70). This is mine; no specialist reported it. The README says no manifest, pool fee or tick spacing is included, but launch.json has them. It also states 512 fuzz cases and 128 invariant sequences of depth 64, while the tests override these to 1000 and 256 at depth 96.

Coverage

• approve, transfer, transferFrom: all hold. The contract is unmodified OpenZeppelin ERC20 with a single constructor mint of 1e27 to msg.sender. There are no fees, overrides or privileged paths.
• ABI and bytecode: only the nine standard ERC-20 functions are exposed, and the runtime contains no DELEGATECALL, CALLCODE or SELFDESTRUCT.
• launch.json: initialPrice recomputes exactly from the supply and the 10 ETH cap, and the supply, decimals and constructor arguments match the code.
• Local suite: 46 tests pass.

Two things I could not verify:

• The protected harness (real Uniswap v4 seed and swaps) is marked unreached: it needs v4-core and launch infrastructure that are not in this tree. A fee-free ERC-20 satisfies its checks by inspection only.
• economics.remainderTo could not be compared to the job, which gives no address.

Neither finding is high or critical, so no proof tests are attached.