The project is complete and verified.

What was built

• src/MutualFunToken.sol is the token. Contract identifier MutualFunToken (14 characters). It inherits OpenZeppelin ERC20 and its constructor mints the whole supply to msg.sender. Name "The mutual fun", symbol "TMF", 18 decimals, total supply 1,000,000,000 × 10^18. No owner, no mint, burn, pause, blacklist, fee, proxy or ether acceptance. The external surface is the thirteen standard ERC-20 functions plus five public constants.
• foundry.toml pins solc 0.8.26, optimizer on, bytecode_hash = "none", cbor_metadata = false, ffi = false, empty fs_permissions, and remappings for the two vendored libraries.
• lib/forge-std (v1.11.0) and the five OpenZeppelin v5.4.0 files ERC20 needs are vendored as ordinary files. No .git directories or submodules remain.
• script/DeployMutualFunToken.s.sol is a reference script whose deploy() function the tests call directly. It reads no environment.
• README.md documents assumptions, manifest parameters, the 10/80/10 supply split performed by the factory, operational responsibilities, and states there is nothing to configure after launch.

Checks run

Check	Result
forge build	passes
forge test with the verifier's fuzz seed	30 passed, 0 failed
forge test with an empty environment	30 passed
forge test with seed 0x1 and 1000 fuzz runs	30 passed
forge fmt --check	clean

Tests cover metadata and constants, the single mint with its Transfer event, CREATE2 deployment from a factory stand-in landing the supply at the predicted address, exact-amount transfers and allowances, revert paths for insufficient balance, zero address, and missing allowance, the launch flows (swarm share, claim, remainder arriving whole), absence of mint/admin selectors, a runtime opcode scan for DELEGATECALL/CALLCODE/SELFDESTRUCT, and fuzz tests for supply conservation and random calls.

The one issue found while testing was a fuzz test of mine that double-counted when the fuzzer chose the deployer as recipient. The test was corrected. Nothing was left out, and no launch.json was written per the launch rules.

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

What the accepted tree contains. One contract, MutualFunToken, an OpenZeppelin ERC20 with an empty constructor that mints the whole supply to msg.sender. The compiled ABI confirms the constructor takes no inputs. There are no application contracts.

What launch.json says.

• kind is custom_token, token contract MutualFunToken, name "The mutual fun", symbol TMF, 18 decimals, empty constructorArgs.
• totalSupply is 1000000000000000000000000000, which is 1,000,000,000 tokens in minor units and exactly what the constructor mints.
• contracts is an empty list.
• pool is IMD at 0x5f7bb59365ce557c26dbcaa4ee9d39a4b95b7127, fee 12500, tick spacing 60, initialPrice one to one, as the launch reference gives it.
• economics is the job's object copied verbatim.
• notes describe the token's fixed supply, lack of privileged functions and exact-amount transfers, under 800 characters.

Checks. The build compiles cleanly and all 30 existing tests pass with the verifier's fuzz seed. A scripted check confirmed the manifest has only schema keys, the supply string, and the verbatim economics. Git status shows launch.json as the single new file.

The review is complete and the findings file is written. No tracked files were changed. The findings file and the scratch test are both gitignored.

Outcome: no defects in the assigned area. The token is a 35-line wrapper over OpenZeppelin ERC20 v5.4.0 with no roles, modifiers, initializer, proxy, or admin surface. One info-level note was recorded.

What I checked, against the Access Control, Trust Gap and Asymmetry guides:

• Permission model. The compiled ABI exposes only approve, transfer, transferFrom, the view functions and five constant getters. Every storage writer traces to the caller's own balance or allowance. The deployer has no path over a holder's balance.
• Supply. The constructor is the only reachable mint. Burn is unreachable because both transfer routes reject the zero receiver. I confirmed this with a scratch test.
• Vendored library. All five OpenZeppelin files are byte-identical to the upstream v5.4.0 tag fetched from GitHub, so nothing hides in the library.
• Asymmetry pairs. approve versus spend, transfer versus transferFrom, and the mint and burn branches of the update function are all mirror-consistent. Self-spend and third-party spend both require the exact allowance.
• Trust Gap seams. No privileged actor, formula, settable recipient or caller-class branch exists, so no seam has a surface.
• Static-analysis lead. The large-literal warning on line 26 is the brief's supply constant and evaluates to exactly 1e27.

The one recorded item is the standard ERC-20 approve overwrite race. Lowering an allowance from 100 to 50 lets a front-running spender take 150 in total. I reproduced it in a scratch test and filed it as info, since it is inherent to plain ERC-20 and fixing it would widen the agreed surface. The judge can decide whether a README note is wanted.

Coverage rows answer all three listed entry points plus seven invariant rows. The existing 30-test suite passes.

The review is complete. .imd-findings.json is written at the repository root with an empty findings list and 11 coverage rows. No tracked file was changed and the scratch test directory is removed.

Result: no defects found. The token is a 35-line wrapper over OpenZeppelin's ERC20 that adds only constants and a constructor minting the full supply to the deployer. Every control-flow path I could reach behaves exactly as the standard specifies.

What I verified

• Vendored library integrity (Periphery). All five files under the OpenZeppelin lib directory are byte-identical to upstream v5.4.0 by sha256. The message sender helper is plain, with no meta-transaction forwarder.
• Entry points (Execution Trace). The compiled ABI has exactly the three state-changing functions the verifier listed, with no receive, fallback or payable surface. I traced approve, transfer and transferFrom through the inherited _update, _approve and _spendAllowance with concrete values: zero-address refusals, one-unit-above-balance revert, residual and infinite allowances, revocation, self-transferFrom without allowance, from equal to the zero address, and supply conservation under fuzzing. Ten scratch tests passed, plus the existing suite of 30.
• Deployment identity (First Principles). The constructor mints to the creating contract under CREATE2, not the transaction origin, takes no arguments, and reads no chain state. The README's manifest values match the code.
• Launch flows. With no transfer override, every hop moves exactly the requested amount, so the swarm share, claims, seed and swaps in the protected harness are satisfied by plain ERC-20 semantics.
• Static-analysis lead. The aderyn large-literal note is the supply constant with digit separators; it equals the brief and cannot overflow.

Two observations recorded as coverage notes, not findings, since neither has a failing input on this tree:

• The approve race and allowance residual are inherent to ERC-20 and documented in the README.
• The TOKEN_DECIMALS constant drives the supply calculation while decimals() is the inherited hardcoded 18. Both agree today. An edit to the constant would silently desynchronise them, which the author may want to guard by overriding decimals() to return the constant.

Nothing in my area was left unreached.

The review is complete and .imd-findings.json is written in the repository root. No source file was changed and the scratch tests were removed.

Outcome: no exploitable defect in the economics of TMF. The token is a 35-line wrapper over OpenZeppelin ERC20 with a single constructor mint, and every Economic Security, Invariant and Flow Gap failure mode I checked holds.

What I verified:

• Library integrity. All five vendored OpenZeppelin files diffed byte-identical to upstream v5.4.0, so there is no hidden fee, skim or allowance tamper in the code that actually runs. I also confirmed the vendored forge-std reports a deliberately failing assertion, so passing tests are meaningful.
• Conservation. A stateful invariant run with random transfer, approve and transferFrom calls across eight actors kept the sum of balances equal to the 1e27 supply throughout. No mint, burn or burnFrom selector exists, so supply can neither grow nor shrink after the constructor.
• Launch flows. Modelled the factory to distributor, distributor to claimant, factory to PoolManager seed, PoolManager to trader buy and sell, and factory to remainder flows using the v4 pull and push pattern. Every hop received exactly what was requested and the 80/10/10 split sums to supply.
• Privilege surface. No owner, roles, pause, blacklist or transfer hook. The deployer cannot move a holder's balance without a standard approval. The runtime has no DELEGATECALL, CALLCODE or SELFDESTRUCT and refuses ether.
• Static analysis leads. Slither reported nothing. The aderyn large-numeric-literal line is the readable underscore literal for the supply and is not a defect.

One item is recorded at info severity only. The contract publishes a TOKEN_DECIMALS constant and derives the supply from it, but never overrides decimals(), which returns OpenZeppelin's hardcoded 18. The two coincide today so nothing fails and no revision is needed. It is a latent coupling gap, and the minimal fix is a one-line override returning the constant.

The coverage record answers all three ABI entry points as holds, plus six invariant and dependency rows. Nothing in the assigned area was left unreached. The opening pool price derivation and the launch manifest itself were outside the token's code and were not reviewed beyond confirming the README's documented split and constructor arguments are consistent.

The review is complete. The findings file is written at the repository root with zero defects and nine coverage rows, and the working tree is otherwise untouched.

Outcome: no math, boundary or numerical-gap defect in src/MutualFunToken.sol. The token adds one compile-time constant and one constructor mint to OpenZeppelin's ERC20, so every value-moving operation is the library's.

What I verified

• Vendored library is genuine. All five OpenZeppelin files under lib/ are byte-identical to the upstream v5.4.0 tag, so the unchecked blocks in the transfer and allowance paths carry upstream's proven bounds.
• Supply constant is exact. The expression evaluates to 10^27, divisible by 10^18 and by 10,000, so the 10/80/10 launch split leaves no dust. The aderyn large-literal lead is correct arithmetic, not a defect.
• Boundaries hold. Transfers of the max uint, the whole balance, one above the balance, zero, and self-transfers of the whole balance all behave correctly. Allowance at max is not decremented and at max minus one is. The zero address cannot reach the mint branch through any public path.
• Conservation holds. A multi-party fuzz over four actors with 2000 runs kept the sum of balances equal to the total supply throughout.
• No external boundaries exist. The token has no external calls, no payable or fallback function, no bytes decoding, and no sentinel other than the library's zero-address guards.
• Seed magnitudes fit. The 80 percent seed and the implied sqrt prices for either currency ordering stay inside Uniswap v4's integer bounds.

One note, not a finding. The decimals() the chain sees is the library default rather than the token's own constant. Both are 18, so there is no failing state today. They agree by duplication rather than by wiring.

Coverage: all three listed entry points are marked holds, with six additional invariant rows. Nothing in my area was left unreached.

Done. The suite now has 66 tests across three files, all passing with the verifier's fuzz seed and with a second seed.

What I added (the existing test/MutualFunToken.t.sol is untouched):

• test/MutualFunToken.invariant.t.sol: a handler with six actors (deployer, holders, a distributor stand-in, the remainderTo address) that drives transfer, transferAll, approve and transferFrom with bounded inputs, plus failure handlers that assert the exact revert for over-balance transfers, transfers to the zero address, pulls above allowance, pulls above balance with infinite allowance, zero-spender approvals, strangers pulling without allowance, ether sends, and undeclared selectors from any caller. Ghost balances and allowances are kept independently. Invariants: fixed total supply, actor balances sum to the supply with nothing at the zero address, token or handler, balances and allowances equal the ghosts, nobody holds more than ever moved, metadata immutable, no ether held. Runs at 256 runs by 64 depth with fail-on-revert on, via inline config.
• test/MutualFunToken.edges.t.sol: 35 edge tests at 1000 fuzz runs. Same call twice for transfer, approve and transferFrom, approve overwrite and revoke, allowance one below infinity is decremented, no Approval event on spend, transferFrom from self needs an allowance, zero address cannot send or approve and cannot be pulled from, max uint256 and supply plus one revert with exact errors, tokens sent to the contract are stuck, short calldata reverts, and fuzzed round-trip, additivity, bystander isolation, per-spender allowances and stranger pulls.

Verification. I ran a deliberately broken ghost copy in test/scratch and the balance invariant caught it, so the invariants are not vacuous. forge fmt --check passes on the new files.

No defects found. The token is a thin wrapper over OpenZeppelin ERC20 v5.4 with constants and a constructor mint. Every failure path behaves as the standard requires, so no findings file was written.

The review is complete. The findings file is valid JSON, both snippets match the tree exactly, and no tracked file changed.

Outcome: no defects in the token. The code is OpenZeppelin ERC20 v5.4.0 with constants and a one-line constructor, and every launch-floor property holds.

Specialist findings, judged:

• The decimals coupling note from the economics specialist reproduced. decimals() is OpenZeppelin's hardcoded 18, independent of the TOKEN_DECIMALS constant that sizes the supply. Both are 18 today, so I kept it at info as a maintenance note, not a defect.
• The approve overwrite race from the permissions specialist reproduced. It is the standard ERC-20 property and not a permission bypass, so it stays at info as a documented trust assumption.
• The flow, math and test-writing specialists reported nothing, and I confirmed nothing was missed in their areas.
• The aderyn large-numeric-literal lead is a style note with no behavioural effect and was dropped.

My own checks, all passing in a scratch test suite: exact-amount transfers with correct revert paths, finite and infinite allowance handling, approve only touching the caller's allowance, mint of exactly 1e27 to the deployer under CREATE2 with no arguments, no admin or mint selectors, no ether acceptance, no DELEGATECALL, CALLCODE or SELFDESTRUCT in the runtime, and bytecode well under the size limits. The manifest matches the constructor, supply and decimals.

Coverage: all three entry points answered as holds, plus three invariant rows. The protected floor tests could not be run locally because they import v4-core and floor files absent from this tree, but each property they assert was checked directly.