Implemented INFER with the exact name, symbol, and 18 decimals. All 1,000,000,000 tokens mint once to the deployer; no later minting or administrative controls.

Dependencies are vendored for offline use. README documents deployment parameters, assumptions, and operational responsibilities.

Verification passed:

• forge build
• forge test: 30 tests, including fuzz and invariant checks
• forge fmt --check

Created launch.json matching INFERToken, its parameterless constructor, exact supply, and required pool and economics.

Validation passed: manifest checks, forge build, and all 30 tests. Only launch.json is a submission change.

I found no defects in how the INFER token's transfers, approvals and supply work, and nothing that would break the launch. The one finding is informational: some test-library hash records are wrong. The review is in .imd-findings.json, and the working tree is unchanged.

What the token is: src/INFERToken.sol is OpenZeppelin v5.0.2's standard ERC20 with nothing added. Its constructor takes no arguments and mints exactly 1,000,000,000 × 10^18 to whoever deploys it — the factory, in the launch.

Execution trace:

• transfer and transferFrom move exactly the amount asked, with no fee, burn or callback, and revert on a short balance, a zero recipient or a short allowance. So the factory's payment to the distributor, distributor claims, and Uniswap pool deposits and swaps all arrive whole.
• approve replaces the allowance and emits Approval. It rejects a zero spender or zero owner.
• Library code: the six OpenZeppelin files match their recorded hashes. These are the files the token compiles from.

Periphery: besides those three entry points, the token's ABI has nothing that changes state. There is no owner, role, pause, blacklist, extra mint or upgrade path. The compiled runtime contains no DELEGATECALL, CALLCODE or SELFDESTRUCT. The aderyn "large numeric literal" warning is just the supply constant, which works out to exactly 10^27; it is not a defect.

First principles: the supply can't grow, nobody can move or freeze a holder's balance, and the factory is an ordinary holder once the launch is done.

Finding 1 (info): DEPENDENCIES.json records the wrong hashes for 7 vendored forge-std files, and the README says those files are unmodified.

• Repro: sha256sum lib/forge-std/src/Vm.sol prints a1b1c829…, but DEPENDENCIES.json:112 records 9068805b….
• Cause: I diffed them against the recorded upstream archive. The only differences are whitespace and line wrapping, consistent with the formatter having run over lib/.
• Impact: only a provenance check against that record fails; the files are test-only and the deployed token is unaffected.
• Fix (author's): restore the upstream bytes, or update the recorded hashes and the README sentence.

Coverage: approve, transfer and transferFrom are each marked holds. Two invariants are also marked holds: the supply is fixed, and no privileged hand can move a balance.

Not checked:

• I couldn't run the launch's protected test locally, because the pool contracts it imports aren't in this repo. My conclusion about the pool steps comes from reading the code, not from running them.
• The 30 local tests (unit, fuzz and invariant) all pass.

The review is complete and .imd-findings.json holds the result. No source files were changed.

Outcome: no economic, invariant or flow defect in the token. The one substantiated item is an informational provenance discrepancy in the vendored test library.

What the token is. src/INFERToken.sol is 16 lines: an unmodified OpenZeppelin v5.0.2 ERC20 whose constructor mints exactly 10^27 minor units to msg.sender and nothing else. The vendored ERC20 matches its recorded upstream hash byte for byte. The compiled ABI exposes only approve, transfer and transferFrom as state changers.

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

• Every launch leg moves exactly what it says. A scratch Foundry test deployed the token via CREATE2 from a factory stand-in and ran the swarm transfer, pool pull via transferFrom, remainder transfer, a distributor claim, and a buy-then-sell round trip. All balances landed whole and the holder sum equalled supply.
• Supply cannot grow. A fuzz over arbitrary selectors left total supply and the factory balance unchanged, and the project's own stateful invariant suite passes.
• Allowance accounting is exact, including the max-uint256 infinite case.
• The runtime contains no DELEGATECALL, CALLCODE, SELFDESTRUCT, CALL or CREATE, and no receive or fallback, so there are no periphery seams or reentrancy paths.
• Constructor takes no arguments, so the manifest's constructorArgs will be an empty list and no exemptions are needed.
• The aderyn large-literal lead is a correct value and was recorded as holding, not reported.

The one finding (info): README.md states vendored sources are unmodified and DEPENDENCIES.json records per-file hashes, but seven forge-std files differ from their recorded hashes. Compared to the upstream v1.9.7 archive the differences are line-wrapping only and the files are identical once whitespace is stripped. forge-std is test-only, so there is no effect on deployed bytecode, but an offline hash check against DEPENDENCIES.json fails. The reproduction command is in the finding.

Coverage: all three listed entry points are marked holds with reasons, plus five invariant rows covering the constructor, supply conservation, launch flow exactness, runtime opcodes and dependency integrity.

Not verified: the README names Ethereum chain ID 1 as the launch chain while the paired currency is the IMD token. I could not confirm which chain IMD lives on, and chain is not a manifest or token field, so this is noted here rather than reported. The protected launch test itself could not be run locally because its v4-core and LaunchLiquidity dependencies are not in this tree.

The findings file is in place at the repository root, and the harness's own exclude rule keeps it out of git, which is expected. The review is complete.

Result: no defects in the assigned area. The token is a 16-line wrapper over OpenZeppelin ERC20 v5.0.2 with no overrides, so the entire math surface is the supply constant and OZ's _update and _spendAllowance arithmetic. I traced each against the Math Precision, Boundary and Numerical Gap guides and confirmed every item with executed tests.

What I verified, with evidence:

• Supply constant. The literal expression compiles to exactly 10^27. That hex constant appears in both creation and runtime bytecode, and the artifact ABI reports 18 decimals. The supply divides the 10/80/10 launch split with no remainder.
• Transfer arithmetic. The checked balance guard runs before the unchecked subtraction, and the unchecked addition cannot wrap because the balance sum equals the fixed supply. I exercised 1 wei, exact balance, balance plus one, max uint256, and a self-transfer of the whole supply.
• Allowance arithmetic. The max-uint sentinel is never decremented, max minus one decrements correctly, and an allowance survives a transfer that reverts on balance.
• Boundaries. No external calls, no payable functions, no receive or fallback, no bytes decoding. The only sentinel branch is the zero address, and both sides revert cleanly.
• Numerical gap seams. There is no division, multiplication, scaling or casting anywhere in the token or its base, so no seam exists.
• Dependency integrity. All six vendored OpenZeppelin files match their recorded SHA-256 hashes, and the ERC20 source matches upstream.

One informational finding, outside my area. DEPENDENCIES.json records hashes for seven forge-std files that do not match the vendored copies, and the README states vendored sources are unmodified. I fetched the upstream archive at the recorded commit and diffed. Every difference is whitespace from a forge fmt pass, so the semantics are identical and nothing reaches the deployed bytecode. The record is still wrong as written, so I reported it with the exact file, line, hashes and reproduction command.

The findings file carries that one finding plus eight coverage rows: holds for all three entry points, and holds for five invariants I checked. The existing 30-test suite passes, the committed files pass the format check, and I removed my scratch tests so the tree is unchanged apart from the findings file.

Review complete. The findings file is written, the snippets match the tree line for line, the scratch test is removed, and the working tree has no tracked changes.

Outcome: no exploitable defect in the assigned area. INFERToken is a bare OpenZeppelin v5.0.2 ERC20 whose constructor mints the full supply once to msg.sender. It has no owner, roles, modifiers, initializer, proxy, external calls, or forbidden opcodes. The only state-changing entry points are approve, transfer and transferFrom, and each behaves as the standard specifies. All 30 project tests pass.

What I reported in .imd-findings.json:

• Low, provenance drift. Seven forge-std files in lib/ do not match the SHA-256 values recorded in DEPENDENCIES.json. I diffed them against the pinned upstream archive and the differences are formatting only. The six OpenZeppelin files that reach deployed bytecode match exactly. The README's statement that vendored sources are unmodified is therefore inaccurate for those test-only files.
• Info, approve race. A spender can front-run an allowance reduction and spend both the old and the new allowance. This is standard ERC-20 behaviour the README already discloses, recorded as a holder trust assumption.
• Info, zero-value transferFrom. Anyone can call transferFrom with value 0 on any holder and emit a Transfer event in that holder's name. No balance moves. This is standard OpenZeppelin behaviour and the project's own tests treat it as intended.

Coverage. All three listed entry points are marked holds, with the two informational notes referenced. I added rows for the constructor, the permission model, trust-gap seams, asymmetry pairs, the opcode scan, dependency integrity, and the protected floor. The manifest row is unreached because no launch.json exists yet, which the README says is expected at this stage.

Not executed locally. The Uniswap v4 seed and swap in the protected test need v4-core, which is not vendored here. I traced those flows by reading instead. A fee-free OpenZeppelin transfer cannot short them.

Added 11 tests and strengthened invariants for balance conservation, allowance isolation, authorization failures, and rollback.

forge build and forge test pass offline: 40 unit/fuzz tests plus 32,768 invariant handler calls.

Only test/ changed. No implementation defects found.

The review is complete. The findings file is written at the repository root and nothing else in the tree changed.

Outcome. The token is a bare OpenZeppelin v5.0.2 ERC20 whose parameterless constructor mints 10^27 units once to the deployer. I kept one finding, at low severity, and dropped or recorded the rest as trust assumptions.

What I verified

• All three entry points hold. The inherited approve, transfer and transferFrom have no override, no owner, no hook, no external call, and no mint, burn, pause or freeze path.
• Build, all 41 project tests, and the formatter check pass.
• The manifest in launch.json matches the code: empty constructor arguments, supply equal to the minted amount, 18 decimals, only schema keys, lowercase addresses, and bytecode far under the size limits.
• The six vendored OpenZeppelin files, the only vendored code that reaches deployed bytecode, are byte-identical to the pinned upstream archive. I downloaded the archive and compared it directly.

The one finding kept (low). All four specialists reported the same root cause, so I merged them. Seven forge-std files in lib/ are whitespace-reformatted relative to the hashes DEPENDENCIES.json records, and the README's claim that vendored sources are unmodified is therefore false. I reproduced it independently: the recorded archive hash matches upstream, the recorded per-file hashes are the upstream hashes, and each drifted file equals upstream once whitespace is stripped. forge-std is test-only, so deployed bytecode is unaffected. The fix belongs to the author: restore the seven files from the pinned archive, or re-record their hashes and amend the README sentence.

Dropped as non-defects. The approve race and the zero-value transferFrom event are standard ERC-20 behaviour that the README and tests already document. I noted both in the coverage rows as trust assumptions rather than findings. One stale sentence in the README says the project does not include a launch.json, though the manifest step has since added one. I left that out of the findings as it has no effect on deployment.