Added adversarial tests and stateful balance/allowance invariants under test/.

• Offline forge build and forge test passed: 42 tests.
• Nine fuzz properties ran 1,000 cases each.
• Invariants passed 32,768 randomized calls.

No confirmed implementation defects found. Live mainnet and Uniswap integration remain unverified.

Updated launch.json notes and verified the manifest matches the accepted token, constructor, supply, pool settings, and exact economics.

Validation passed: supplied JSON schema, compiled constructor ABI, forge build, and all 42 Foundry tests.

Only launch.json changed.

The review is complete. No defects found in the assigned math, boundary and numerical-gap area, and the findings file records that with full coverage.

Outcome. .imd-findings.json holds an empty findings list and eight coverage rows: the three listed entry points plus five invariants I checked, all holds. No file in the tree was changed. The scratch test directory was removed after use.

What I checked, against the three guides:

• Math Precision. The contract has no division, scaling, fixed-point conversion, or narrowing cast. The only arithmetic is a guarded subtraction and a credit bounded by the fixed supply, so no rounding, truncation, or overflow path exists. The aderyn lead on the large literal is closed: the constant folds to exactly one billion times ten to the eighteenth, matching the manifest.
• Boundary. No external calls, no payable entry, no bytes decoding. The only sentinel branches are the zero-address guards, and both sides revert as intended, including on zero-value calls.
• Numerical Gap. The zero-value fast path in transferFrom writes nothing and still enforces the guards. The launch split of ten and ninety percent is exact with no remainder and fits Uniswap v4's int128 and uint128 widths. The manifest's provenance sqrtPrice reproduces the 2500 IMD cap to within one part in a billion.

Evidence. The existing suite of 42 tests passes, including the 256-run invariant campaign. My scratch probes exercised 1 wei, full supply, supply plus one, max uint, self-transfer at full supply, allowance of max and max minus one, exact-allowance consumption, and atomic rollback of the allowance write when the balance check fails. All seven passed.

Not reached. Nothing in the assigned area was left unverified. The live Uniswap v4 seed and swap were not executed locally, since the protected harness owns that and the token has no code that could affect pool math.

The review is complete. The findings file is valid JSON, the scratch test directory is removed, and the working tree has no stray files (the findings file is excluded via the repo's own git exclude list, as the harness expects).

Result: no defects found in the Access Control, Asymmetry or Trust Gap areas. The findings list is empty and the coverage record answers all three entry points plus five invariants.

What I checked, against each guide:

• Access Control. The token has no roles, modifiers, initializer, proxy, fallback or receive. The constructor credits only its caller, and under CREATE2 from the factory that caller is the factory. Every admin-shaped selector the protected floor tries reverts whether sent by the factory or a stranger. The factory cannot move a holder's balance through transferFrom without an approval.
• Asymmetry. Both transfer paths funnel into the same private helper, so the zero-recipient, zero-sender and balance checks are identical. The finite and unlimited allowance branches diverge only in whether the allowance is decremented, which matches OpenZeppelin v5 semantics and is documented. Self-transfer preserves the balance because the credit is read after the debit.
• Trust Gap. There is no privileged actor and no economic formula inside the token, so no seam exists between authorization, economics and asymmetry. The launch economics in launch.json match the brief, and the provenance sqrtPrice recomputes from the market cap and supply to within one part per million.

I also confirmed with a throwaway Foundry test that the compiled runtime contains no DELEGATECALL, CALLCODE or SELFDESTRUCT under the protected test's exact scan, that supply equals the manifest's 1e27, and that the swarm, pool, claim, trade and remainder flows each deliver the exact amount requested.

One note for the judge rather than a finding: the standard ERC-20 approve race exists because there are no increase/decrease allowance helpers. The README documents this and it is by design for a plain ERC-20, so I did not report it.

The review is complete. No defect was substantiated, and the findings file at the repository root holds an empty findings list with nine coverage rows.

What I checked, in the assigned area

• Execution Trace. Every state-changing path in src/SIMDTESTToken.sol was traced with concrete values. The debit-then-credit order keeps self-transfers balance-neutral. A revert on balance or zero recipient also discards the allowance write in transferFrom, so there is no partial state. The max-allowance sentinel skips only the decrement, not the balance check. There are no external calls, so no stale reads or reentrancy windows exist.
• Periphery. The project vendors no libraries or helpers. The only shared file is a test-only cheatcode shim that is not compiled into the token.
• First Principles. The one identity assumption, that the constructor's caller is the factory, holds under CREATE2 from a factory contract. The supply is a compile-time constant, so no code path can change it. The balance sum cannot overflow at 1e27 units.

Verification I ran

• The existing suite of 42 tests passes, including the invariant handler.
• Eight scratch traces passed, covering the launch flow amounts, a Uniswap v4 style sync/settle/take accounting round trip, allowance edge cases, zero-address paths, ether rejection and truncated or dirty calldata. The scratch directory was removed afterwards.
• An opcode scan of the compiled runtime and creation code found no DELEGATECALL, CALLCODE, SELFDESTRUCT or any CALL-family opcode.
• The manifest's initialPrice equals the sqrtPriceX96 derived exactly from the 2500 IMD cap over the fixed supply with SIMDTEST as currency0, and every other manifest field matches the brief.

Leads I looked at and did not report. The approve-replace race and the ability to emit a zero-value Transfer from any address via transferFrom are inherent ERC-20 behaviours that OpenZeppelin shares, and the brief asks for a plain ERC-20. The aderyn large-literal note is stylistic. Currency ordering against the IMD address depends on the deployed token address and is the deployer's responsibility, as the manifest notes state.

The review is complete. The findings file is written, the scratch tests are removed, and the working tree is unchanged apart from the excluded findings file.

Result: no defects found. .imd-findings.json holds an empty findings list and 12 coverage rows, all holds, covering the three verifier-listed entry points, the constructor, two invariants, the three launch flows, both economics checks, the manifest and build settings, and the aderyn lead.

What I checked, against the Economic Security, Invariant and Flow Gap guides:

• Supply conservation. The supply is a compile-time constant of exactly 1e27, matching the manifest. Only one private function writes balances, and it debits before crediting, so self-transfers conserve. The ABI exposes exactly three non-view functions, so no mint, burn or admin path exists.
• Allowance coupling. Finite allowances decrement before the balance move and unwind on any revert. Unlimited allowances are never decremented. The deployer cannot move a holder's balance without approval.
• Launch flows. Factory to distributor, distributor to claimant, factory to PoolManager, and PoolManager to trader all move exactly the requested amount in both directions, which is what Uniswap v4's sync and settle balance deltas rely on. No hook, callback, pause or exemption can make a seed or swap revert.
• Economics. 90% pool plus the swarm's 10% sums to the whole supply, so the nominal remainder to the dead address is zero. The manifest's provenance sqrt price matches the 2500 IMD market cap for SIMDTEST as currency0, and both it and its currency1 inverse fall inside v4's price bounds.
• Build. Compiled metadata confirms solc 0.8.26, Cancun, optimizer on, and no bytecode hash. The runtime has no DELEGATECALL, CALLCODE or SELFDESTRUCT.

Known ERC-20 behaviours I reproduced but did not report as defects: the approve replace race, where a spender can consume the old and the new allowance, and zero-value transferFrom without an allowance emitting a Transfer event. Both match OpenZeppelin v5 exactly and the first is documented in the README. They are noted in the coverage rows for the judge.

Not reached: a live Uniswap v4 swap. The v4-core library is not vendored and lib/ is off limits, so the pool math itself was not executed locally. The protected harness runs that check. Everything else in the assigned area was covered.

The existing 42-test suite passes, including the 256-run invariant campaign, and forge fmt --check is clean.

The review is complete. The findings file parses (0 findings, 6 coverage rows, all holds) and git status is clean, so .imd-findings.json is the only output and nothing else in the tree was touched. There is nothing further to request.

Result: no defects found

.imd-findings.json holds {"findings": []} plus a coverage record answering all three verifier-listed entry points and three invariants.

What I reproduced myself rather than taking from the specialists:

• Entry points (src/SIMDTESTToken.sol): approve only writes the caller's allowance and rejects a zero spender; transfer/transferFrom go through one _transfer that rejects from==0/to==0, reverts on insufficient balance, and debits before crediting so a self-transfer preserves the balance. transferFrom with no allowance (the floor's "factory tries transferFrom(HOLDER, factory, 1)" case) reverts ERC20InsufficientAllowance and moves nothing. No sender/recipient special-casing anywhere, so the factory→distributor, claim, seed and both swap directions move exactly the stated amounts.
• Supply: totalSupply is a constant 1_000_000_000 * 10**18 = 1000000000000000000000000000, matching launch.json; minted once to msg.sender in a no-arg constructor (constructorArgs: [] matches). No mint/burn/owner/admin function exists.
• Forbidden opcodes: walked the compiled deployedBytecode (1416 bytes, skipping PUSH immediates exactly as the protected test does) — zero DELEGATECALL/CALLCODE/SELFDESTRUCT. The bytecode trailer is only the 10-byte solc CBOR entry, consistent with bytecode_hash = "none".
• Toolchain/manifest: foundry.toml is solc 0.8.26, cancun, optimizer on, bytecode_hash = "none"; economics copied verbatim (poolBps 9000, 2500e18, 0x…dead); initialPrice squares to 2.5e-6 paired/token minor unit = 2500 IMD / 1e9 tokens, so the provenance value is internally consistent.
• Local suite: forge build and forge test pass under forge 1.8.3 — 42 tests across 3 suites including the invariant handler (~8k calls per selector, 0 reverts).

Static-analysis leads settled: slither reported nothing; aderyn's large-numeric-literal at line 11 is the supply constant written with underscores and 10 ** 18 — a style note, not a defect.

Not run here: the pinned protected test itself, since it imports forge-std and v4-core, neither of which is vendored (lib/ doesn't exist) and installing is out of scope for a review. I replicated its opcode walk and traced its supply/privileged-hand/flow assertions against the source instead.