Implemented IMD Tools (TOOLS) with 18 decimals and exactly 1,000,000,000 tokens minted once to the deployer. No later minting or administrative powers.

Dependencies are vendored; deployment parameters, assumptions, and operational responsibilities are documented in README.md.

Verified forge build, forge test, and forge fmt --check. All 32 tests passed with the supplied fuzz seed, including a clean offline verification.

Created launch.json matching the accepted IMDTools constructor, supply, metadata, pool settings, and exact economics. No other repository files changed.

forge build succeeded. forge test passed all 32 tests with the supplied fuzz seed. Local manifest and constructor ABI checks passed.

The review is complete and found no defects. The findings file holds an empty list and eight coverage rows, and no tracked file was changed.

What was reviewed. The token is 17 lines over OpenZeppelin ERC20 v5.0.2 with a single constructor mint of 1e27 units to the deployer. I applied the three assigned Pashov guides (Economic Security, Invariant, Flow Gap) plus the Senior Auditor's Mindset, and used the entry-point inventory from the Trail of Bits reference.

Evidence gathered.

• The five vendored OpenZeppelin files are byte-identical to upstream v5.0.2. I compared sha256 hashes against the tagged GitHub sources.
• The compiled ABI exposes only the three listed entry points plus views and the constructor. There is no mint, burn, owner, pause, blacklist or initializer.
• The runtime bytecode contains no CALL, DELEGATECALL, CALLCODE, SELFDESTRUCT or CREATE opcodes, so there are no external dependencies or callbacks to break.
• The repository suite passes with the assigned fuzz seed: 31 unit and fuzz tests plus one invariant suite, and formatting is clean.
• A scratch test modelling the full launch sequence passed: factory deploy through CREATE2, the 10/88/2 split exhausting the factory balance exactly, approve-and-pull settlement as a pool manager does, many exact distributor claims, and the factory failing to pull a holder's balance without allowance.

Guide-by-guide result. Economic Security: no oracle, token misbehaviour, fee, rebase or sentinel path exists, and transfers to or approvals of the zero address revert. Invariant: conservation of supply holds through OpenZeppelin's checked mint and bounded unchecked balance updates, and no path can grow supply after construction. Flow Gap: every flow in the protected launch suite is a plain transfer with no intermediate state the token could leave inconsistent, and decimals and supply match the stated manifest values.

Leads dismissed. The aderyn large-numeric-literal note is a style remark on a compile-time constant equal to exactly 1e27. The ERC-20 approval ordering race and the absence of an Approval event on transferFrom are standard OpenZeppelin v5 behaviour, documented in the README, and fall under the guide's do-not-report list.

Not reached. Nothing within the assigned area was left unreached. Live-chain Uniswap v4 seed and swap behaviour was not executed here because the protected harness depends on the verifier's factory and pool manager fixtures, which are not in this repository.

Review complete. No defects found in the Access Control, Trust Gap or Asymmetry area, and the findings file at the repository root holds an empty findings list with a full coverage record. The working tree is otherwise unchanged.

What the token is. One file, src/IMDTools.sol, inheriting the vendored OpenZeppelin v5.0.2 ERC20 with a constructor that mints 1e27 base units to msg.sender. The compiled ABI exposes exactly the ten ERC-20 selectors plus a constant getter. There is no owner, minter, pauser, initializer, proxy, receive or fallback.

What I verified

• Access control: no roles exist to escalate, no storage variable has two writers with different guards, and the constructor is nonpayable with no arguments. A 1024-run fuzz over unknown selectors reverted for both the deployer and a holder. The deployer and a stranger were shown symmetric: neither can move another holder's balance without an allowance.
• Asymmetry: transfer and transferFrom share the same internal path, with transferFrom only adding the allowance spend. Zero-address, zero-amount, self-transfer and revert paths behave as mirrored pairs, and failed transferFrom calls leave the allowance intact.
• Trust gap: with no privileged actor there is no access-times-economics or access-times-asymmetry seam. The only trust assumption is the intended one, that the factory receives the whole supply.
• Supply chain: the five vendored OpenZeppelin files are byte-identical to upstream v5.0.2. The runtime bytecode contains no CALL, DELEGATECALL, CALLCODE, CREATE or SELFDESTRUCT opcodes, and storage slots beyond the ERC-20 set are zero.
• Checks run: forge build, the seeded project suite (32 passing), forge fmt, a scratch probe suite (4 passing, since deleted), and an opcode scan. Slither and Mythril were not available.

Coverage record. All three listed entry points are marked holds, with four additional invariant rows covering the fixed supply, the absence of privileged roles, the unmodified library, and exact launch flows.

Leads I set aside. The aderyn large-numeric-literal line is the intended supply constant and not a defect. The standard ERC-20 allowance-replacement race is inherent to the specification and already documented in the README, so I did not report it. The README's chain ID and paired-currency address are outside my area and could not be checked because no network file was in the read set.

The review is complete and found no defects. The findings file holds an empty list and a coverage row for every entry point, and the working tree is unchanged apart from that file.

What I checked

• Execution Trace. I traced approve, transfer and transferFrom through the vendored OpenZeppelin code to their final storage writes. Amounts move exactly, zero addresses revert, self-transfers read fresh storage, and a failed transferFrom leaves the allowance intact. The approve race condition is the only residual and the README documents it.
• Periphery. The five vendored OpenZeppelin files are byte-identical by SHA-256 to upstream v5.0.2. The context helper returns the plain caller, with no forwarder. Decimals are hardcoded to 18 and match the manifest.
• First Principles. The constructor takes no arguments, is nonpayable, and mints the whole supply once to its caller. A scratch test deploying via CREATE2 from a factory address with existing code confirmed the factory receives all of it, with no allowance granted to anyone. Unknown selectors and plain ETH revert, since there is no receive or fallback function.
• Static-analysis lead. The Aderyn large-literal warning is stylistic. I confirmed the constant evaluates to exactly 10^27 base units.
• Tooling. The build, the 32 repository tests with the README's fuzz seed, formatting of the tracked files, and my four scratch tests all passed. I removed the scratch directory afterwards.

Coverage. All three listed entry points plus the constructor are marked holds, with additional rows for fixed supply, absence of privileged roles, the vendored library, and the forbidden-opcode scan. Nothing was left unreached.

Out of scope. The launch manifest is not present in the tree yet, which is expected before the manifest step. No live-chain or Uniswap v4 pool test was run, since the protected suite is the verifier's.

The review is complete and written to .imd-findings.json. No substantiated defects in the Math Precision, Boundary or Numerical Gap areas.

What was reviewed. The token is 17 lines over an unmodified OpenZeppelin v5.0.2 ERC-20, with one constant mint of 1e27 base units to the deployer and no overrides. I checked every failure mode in the three assigned guides against it and against the inherited arithmetic in _update and _spendAllowance, then confirmed the edge cases with a scratch Foundry suite instead of trusting the read.

Why each guide came up clean.

• Math Precision: the only arithmetic is the constant-folded literal and OpenZeppelin's checked-then-unchecked balance and allowance updates. There is no division, downcast, fixed-point scaling or decimals mismatch. The literal is exactly 1e27 and fits int128, so the aderyn large-literal lead is style only.
• Boundary: no external calls, no payable, receive or fallback, no bytes decoding. The only sentinel branches are the zero-address checks, which reject from and to zero in every path, including zero-value transferFrom from the zero address.
• Numerical Gap: supply conservation held across a 1,024-run multi-actor fuzz plus self-transfer, max-uint and zero-value paths. The launch split in basis points is exact with no dust, and every share is a whole number of wei.

Supporting checks. The existing 32 project tests pass under the pinned fuzz seed. All five vendored OpenZeppelin files are byte-identical to the upstream v5.0.2 tag, so the reviewed arithmetic is what deploys.

Coverage record. All three ABI entry points are marked as holding, with five additional invariant rows covering the constant's value and width, launch-split exactness, decimals, the absence of a payable or external-call surface, and vendored-library integrity. The scratch test directory was removed since no finding needed it as proof, so the tree holds only the findings file.

Added 10 boundary and failure-path tests and expanded the invariant suite to 11 randomized actions.

Verified forge build and forge test with the supplied seed: 42 tests passed, including 24,576 invariant calls.

Only test/ files changed. No reproducible defects found.

I found no defects in IMD Tools (TOOLS). .imd-findings.json has an empty findings list and a coverage row for each of the three entry points, all marked "holds".

What I checked:

• The token code: src/IMDTools.sol is a plain ERC-20 built on OpenZeppelin v5.0.0. Its constructor takes no arguments and mints the full supply of 1,000,000,000 tokens (18 decimals) once to the deployer. It has no later mint or burn, no owner, no pause or blacklist, and no transfer fee.
• The library code: I compared the vendored OpenZeppelin approve, transfer, transferFrom, the allowance check, the balance update and _msgSender against standard v5.0.0. None of it has been modified.
• Launch flows: transfers move exactly the amount requested. So the factory's seed, the distributor's claims and pool swaps all arrive in full.
• Deployability: the bytecode is about 2.7 KB to create and 1.8 KB deployed, far under the 49,152 and 24,576 byte limits. It needs no linked libraries and no particular address. launch.json has an empty argument list to match the constructor, and its supply, decimals and contract name match the code.
• The test suite: all 42 existing tests pass (forge test).

Specialists and static analysis:

• None of the four specialists or the test writer reported anything, so there was nothing to reproduce or merge.
• Slither reported nothing.
• Aderyn's one "large numeric literal" warning is only about how the supply number is written, not a defect.

The allowance front-running race is a known property of every ERC-20 approve, so I didn't count it as a finding. I couldn't check economics against the original job description, which wasn't available to me. It matches the example values given in the task.