Implemented Infer (INFER): 1,000,000,000 tokens with 18 decimals, minted once to the deployer.

Added vendored dependencies, deployment documentation, and 29 success, failure, and fuzz tests.

Verified:

• forge build
• forge test
• forge fmt --check
• Clean offline tests with an empty environment

All passed. The separate launch-system pool/swap harness was not run locally.

The review is complete. No defects were found in the Math Precision, Boundary or Numerical Gap areas, and .imd-findings.json holds an empty findings list with six coverage rows.

What was reviewed

• src/Infer.sol is a stock OpenZeppelin v5.0.2 ERC20 with one constructor mint and no custom arithmetic. The six vendored library files match their recorded checksums.
• The mint constant is a compile-time literal of 10^27, far below the uint256 ceiling, and the only checked addition in the mint path starts from zero. The aderyn "large numeric literal" lead is cosmetic.
• Every unchecked block in the vendored transfer and allowance code is bounded by a preceding explicit check against balance or allowance, so no edge input can wrap.
• There are no external calls, payable functions, sentinel-address branches, bytes decoding, or decimal conversions, so the Boundary guide's enumeration is empty. The runtime contains no DELEGATECALL, CALLCODE or SELFDESTRUCT.
• The Numerical Gap seams need a rounding or scaling step to exist. The token has none, and the supply-equals-sum-of-balances invariant held across the fuzzed 64-step transfer sequence.

What ran

• The existing suite of 29 tests passed, including five fuzz tests at 512 runs each.
• A scratch boundary test covering 1 wei, full supply, supply plus one, allowance at max and max minus one, and self-transfer with infinite allowance passed. The scratch directory was removed afterwards, and the working tree is unchanged apart from the findings file.

Coverage record

All three ABI entry points are marked holds: approve, transfer and transferFrom. Three additional invariant rows cover the exact mint, the constant supply, and the absence of external boundaries. Nothing in the assigned area was left unreached.

The review is complete with no defects found. The findings file is written, and no source files were changed.

What I checked, following the Execution Trace, Periphery and First Principles guides:

• Execution flow of all three entry points. Each was traced through the vendored OpenZeppelin v5.0.2 code to its storage writes and every revert path. There are no external calls, callbacks, sentinel bypasses, or partial state updates. The one sentinel, the unlimited allowance that is never decremented, is standard ERC-20 behaviour and the README documents it. Spending from the zero address is rejected even for a zero amount, so no mint path exists through transferFrom.
• Periphery. The vendored library is byte-identical to the upstream v5.0.2 raw files, confirmed by an independent fetch, and matches the committed checksum list. No submodule is present and the remapping resolves locally.
• First principles. The minted literal evaluates to exactly 10^27, which matches the README's supply figure, so aderyn's large-literal lead is benign. Supply is bounded, so the unchecked recipient credit cannot overflow. The constructor mints to msg.sender, so a CREATE2 factory receives the whole supply.
• Launch floor. The compiled ABI exposes only approve, transfer and transferFrom as state-changing functions, with no receive or fallback. An independent opcode scan of both creation and runtime code found no DELEGATECALL, CALLCODE, SELFDESTRUCT or CREATE. The existing 29-test suite passes and forge fmt --check is clean.

One limit on coverage. The protected test's Uniswap v4 seed-and-swap flow was not executed locally, because v4-core is not vendored. I judged it by source trace: the token has no transfer hooks, fees or exemptions, so pool interactions are plain ERC-20 transfers that move exact amounts.

The coverage record in .imd-findings.json marks all three listed entry points as holding, with five additional invariant rows covering the constructor, constant supply, launch flows, the vendored library and the bytecode scan.

Created launch.json with Infer’s exact supply, empty constructor arguments, required economics and paired token, and a 0.3% pool fee.

Manifest checks and forge build passed; all 29 local tests passed. Only launch.json changed.

The review is complete. The findings file at .imd-findings.json holds an empty findings list and nine coverage rows. The working tree has no tracked changes.

Result: no defects found in the assigned area. The token is a 13-line wrapper over OpenZeppelin ERC20 v5.0.2. The vendored library files are byte-identical to the upstream release, verified both by the shipped checksums and by a direct diff against GitHub.

What I checked against the three guides:

• Access Control. The compiled ABI exposes only approve, transfer and transferFrom as state-changing calls, with no receive or fallback. There are no roles, owner, initializer, proxy or delegatecall. Every write to balances, allowances or supply is scoped by msg.sender or by an allowance the owner granted. A factory deploying via CREATE2 receives the whole supply and gains no power over later holders.
• Trust Gap. No privileged actor, setter, fee recipient or pricing formula exists in the token, so no access-times-economics or access-times-asymmetry seam can form.
• Asymmetry. The approve/transferFrom and transfer/transferFrom pairs end in mirrored state. The internal mint and burn branches are reachable only from the constructor. The missing Approval event on allowance spend is OpenZeppelin v5 behaviour and is documented in the README.

Leads from static analysis. The aderyn large-literal note was checked: the constant evaluates to exactly 10^27, matching the stated supply. Slither reported nothing.

Verification run. The existing 29 tests pass, including the fuzz suites. I added a scratch probe covering factory privilege, cross-owner approval, transfer mirroring, the standard approve race, an opcode scan for any external-call or CREATE opcode, and the literal value. All six passed and the scratch file is removed.

Not reachable here. The protected harness's pool seed and swap path needs v4-core and forge-std, which are not in this tree. I traced it by reading instead. The token has no transfer hook, fee or exemption logic, so nothing in it can make that path revert or arrive short.

Added 11 failure-path and fuzz tests plus three stateful invariants under test/.

Offline forge build and forge test pass: 41 tests, including 32,768 randomized handler calls. No implementation defects found. No dependencies or configuration changes added.

Review complete. The findings file is written and validates, and the working tree holds no other changes.

Scope

Files read: src/Infer.sol (13 lines), the vendored lib/openzeppelin-contracts ERC20 subset (ERC20.sol, IERC20, IERC20Metadata, Context, draft-IERC6093), test/Infer.t.sol, test/support/TestBase.sol, README.md, foundry.toml, and the protected harness. Guides applied: Senior Auditor's Mindset, Economic Security, Invariant, Flow Gap, and the four validation gates.

Severity counts: 0 Critical · 0 High · 0 Medium · 0 Low

No defect survived the verification gate. .imd-findings.json holds an empty findings list and eight coverage rows, all holds.

What was checked and concluded correct

• Supply and mint. The constructor mints exactly 10^27 minor units to msg.sender once. Under CREATE2 from a factory, the factory holds everything and the transaction origin holds nothing. No external path reaches mint or burn. Twenty-four admin, mint and burn selectors revert against a contract with no fallback.
• Conservation. Only the OpenZeppelin _update writes balances or supply. Transfers to the zero address revert, so the supply can neither grow nor shrink after construction.
• Exact flows. There are no hooks, fees, limits, exemptions or callbacks, so factory to distributor, distributor to claimant, factory to PoolManager seed, and trader buy and sell each move exactly their stated amount. The token takes no constructor arguments, so nothing in the manifest can mis-wire an exemption.
• Entry points. approve, transfer and transferFrom are the unmodified OpenZeppelin v5.0.2 bodies. I diffed the vendored files against independent v5.1 and v5.4 copies on this machine, and only comment lines differ.
• Bytecode. An independent opcode scan of the compiled runtime found no DELEGATECALL, CALLCODE, SELFDESTRUCT or CREATE. Metadata hash is disabled. Decimals return 18.
• Tests. The project's 29 tests, including five fuzz suites, pass under the pinned 0.8.26 Cancun build.

Observations, not defects

• Approvals replace rather than increment, so a spender can front-run an allowance change and spend old plus new. This is the standard ERC-20 property the README documents as chosen behavior.
• Tokens sent to the token's own address are unrecoverable, as the README states. There is no admin to recover them, which is the intended design.
• The static-analysis lead about a large numeric literal is the compile-time constant 10^27, which fits comfortably in uint256.

Not reached

The protected pool and swap harness cannot run here, since v4-core and LaunchLiquidity are not vendored. I reasoned about those flows from the token's plain transfer semantics instead of executing them.

The review is complete. No defects found. The findings file is written with an empty list and a six-row coverage record, and no tracked file was changed.

What I checked

• Specialist input. All four specialists and the test writer reported nothing, so there was nothing to reproduce or merge. I re-read the code myself rather than relying on their holds.
• The token itself. src/Infer.sol is a three-line wrapper over OpenZeppelin ERC20 that mints 1e27 minor units once to the deployer. The compiled ABI exposes only the nine standard ERC-20 selectors, with no fallback, receive, owner, mint, burn or pause surface.
• Dependency integrity. The vendored library is ordinary files, not a submodule. I fetched the same five Solidity files and LICENSE from the upstream v5.0.2 tag and they are byte-identical, so the inherited transfer, approve and allowance logic is the audited upstream code.
• Launch floor. I ran a scratch test mirroring the protected harness's non-Uniswap checks: CREATE2 deployment from a factory, factory holding the whole supply, exact ten percent transfer and re-claim, 22 admin selectors reverting from both deployer and stranger, deployer unable to pull a holder's balance, and the harness's opcode walk finding no DELEGATECALL, CALLCODE or SELFDESTRUCT. It passed and was deleted afterwards.
• Manifest. Total supply and decimals in launch.json match the constructor and the OpenZeppelin default. The recorded sqrtPriceX96 is consistent with the stated market cap over the supply. I could not verify that economics and the paired currency are copied verbatim from the job, since the job text is not in the tree, and that is not a code defect.
• Static analysis lead. The aderyn large-numeric-literal note points at the compile-time constant for the supply. It is a style lint with no overflow or runtime effect, so it was dropped.

Existing project tests

Suite	Result
Unit, fuzz and property tests	40 passed
Invariant suite (256 runs, 32768 calls)	1 passed

Coverage record

Every one of the three listed entry points is marked holds, with three extra rows for the supply invariant, the privileged surface, and dependency integrity.