Implemented IMDwindowshopper (WWW): 1 billion tokens, 18 decimals, minted once to the deployer, with no admin or additional minting powers.

Validation passed: forge build, offline rebuild, all 32 tests with the specified fuzz seed, and forge fmt --check.

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

I found no defects in the permissions area, so .imd-findings.json has an empty findings list. It also has a coverage row for each of the three entry points, all marked holds, plus two rows for invariants I checked.

What I reviewed: src/IMDwindowshopper.sol is a plain OpenZeppelin v5.0.2 ERC-20. It mints the 1,000,000,000 × 10^18 supply once, to the deployer, in the constructor. It overrides nothing, inherits no owner or role contract, and has no mint, burn, pause, blacklist or upgrade function. The OpenZeppelin files match the project's checksum list, so its transfer, transferFrom and approve are the unmodified library versions.

• Access Control: No roles or extra checks exist beyond OpenZeppelin's own. The constructor takes no arguments and gives out no privileges, so the deployer is just a holder like anyone else. Nothing can mint after deployment. There's no initializer and no delegatecall or proxy.
• Asymmetry: transfer and transferFrom both end in the same balance update, and transferFrom spends the allowance first. Only approve and the allowance spend in transferFrom write allowances, and both apply OpenZeppelin's zero-address checks. An unlimited allowance is deliberately never reduced; that's standard behaviour, not a defect.
• Trust Gap: There are no privileged actors, fees or exemption lists. The factory, pool manager and distributor transfers each move exactly what they say.

Other checks: The project's own tests pass (32 of 32). The static analysers' only lead was the large number for the supply; it's the correct 1e27 written readably, not a bug.

Outside my area:

• Checksums for 7 vendored forge-std files don't match the project's list. Those files are only used by tests, never by the token, so I didn't report it as a finding. It may still be worth re-fetching them.
• I couldn't run the two protected floor tests. They import harness files that aren't in this tree and read the deployment settings from environment variables.

I changed no repository files and created nothing under test/scratch/.

Created launch.json matching the accepted token, constructor, supply, and exact pool/economics settings.

Validation passed against the compiled constructor ABI. forge build succeeded; all 32 tests passed with the supplied fuzz seed.

Only launch.json is included in the submission changes.

The review is complete. The findings file is written at the repository root and the working tree is otherwise unchanged.

Result: no economic defect found in the token. IMDwindowshopper is an unmodified OpenZeppelin v5.0.2 ERC-20 with a single constructor mint of 10^27 base units to the deployer, no owner, no hooks, and no mint, burn, pause or blacklist surface.

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

• Conservation and supply growth. The only writer of total supply is the internal update path, called once from the constructor. The compiled ABI exposes only the standard ERC-20 functions. A scratch fuzz run of 1024 cases and the project's own invariant suite hold the sum-of-balances law.
• Launch flows. Transfers from the factory to the distributor, pool and remainder address, a distributor claim, and a buy/sell round trip through a sync-and-settle balance-delta probe all moved exact amounts. The token has no fee or callback, so Uniswap v4 settle deltas match the amounts paid.
• Sentinel and compliance paths. Transfers and approvals involving the zero address revert, infinite allowance is preserved, finite allowance decreases exactly, and a reverted transferFrom rolls back its allowance spend.
• Privileged hands. All privileged selectors from the protected floor revert when called by the factory, and the holder can still transfer afterwards. The reachable-opcode scan of the runtime finds no DELEGATECALL, CALLCODE or SELFDESTRUCT.
• Dependency integrity. The six OpenZeppelin files production code imports are byte-identical to upstream v5.0.2.

One informational note is recorded, outside my area. The README states every vendored checksum passes, but seven forge-std files fail the project's checksum inventory. The diff against upstream v1.9.7 is line-wrapping only, consistent with the formatter having run over lib after the inventory was written. It has no effect on the token's bytecode.

Coverage: all three listed entry points are marked holds, plus four invariant and economics rows. The one thing not reached locally is a live Uniswap v4 seed and swap, since v4-core is not vendored. That is exercised only by the network's protected harness.

The review is complete and the findings file is written. Nothing further is needed.

Result: no math defects in IMDwindowshopper. The token is a 16-line wrapper over the vendored OpenZeppelin v5.0.2 ERC20 with one constant and one constructor mint. I checked it against every failure mode in the Math Precision, Boundary and Numerical Gap guides, after reading the Senior Auditor's Mindset.

What I verified, in the project's suite and in eleven scratch probes I wrote and ran, then deleted:

• Supply literal. The aderyn "large numeric literal" lead is benign. The constant compiles to exactly 10^27, which is one billion whole tokens at 18 decimals, and the runtime bytecode carries that value. The mint from zero cannot overflow.
• Transfer arithmetic. The balance check reverts at balance plus one and at the maximum uint256. The unchecked subtract and add are bounded by total supply, so a recipient balance cannot wrap. Transfers to the zero address revert, so supply cannot shrink.
• Allowance arithmetic. Allowance equal to value passes and zeroes out, allowance plus one reverts. Only the maximum uint256 is the infinite sentinel; max minus one decrements normally. The balance check still binds under infinite allowance, and a failed transfer rolls back the allowance.
• Boundary surface. No external calls, no payable path, no bytes decoding. The only sentinel branches are the zero-address reverts.
• Conservation. Fuzzed fragmented transfers and the project's invariant run conserve supply to the wei. The 10/80/10 launch split and the 2/8 swarm split divide the supply exactly.

One info-level item recorded, outside the math area: the README claims every vendored checksum passes, but seven forge-std files in this tree fail sha256sum -c lib/checksums.sha256. forge-std is test-only, so this does not affect the token's bytecode or launch flows.

The findings file holds one info finding and six coverage rows. All three ABI entry points are marked holds, plus rows for the constructor constant, the supply-conservation invariant, and the Boundary guide's external-surface enumeration. The working tree is otherwise unchanged.

Added 15 boundary/failure-path tests and expanded stateful invariants under test/.

Clean offline forge build and forge test pass: 47 tests, including 32,768 randomized handler calls, using the required seed.

No implementation defects found. Only test/ files changed.

The review is complete and written to .imd-findings.json.

Outcome: one low finding, no defects in the token itself.

The token is a 16-line wrapper over OpenZeppelin v5.0.2 ERC20 with a no-argument constructor that mints the full supply to msg.sender. I verified the five vendored OpenZeppelin files are byte-identical to upstream v5.0.2, so the production bytecode is exactly stock ERC20. The build succeeds and all 47 tests pass with the README's seed, including the invariant run. Runtime is 1,752 bytes with no link references and no reachable DELEGATECALL, CALLCODE or SELFDESTRUCT. The manifest uses only schema keys, its supply matches the constant, and the paired currency has code on chain 1 and returns the symbol IMD.

The specialists' findings. All three reported the same root cause, which I merged into a single low finding and reproduced:

• Running the checksum command from the README fails for seven forge-std files, while every OpenZeppelin entry passes.
• The drift is whitespace-only. Upstream v1.9.7 Vm.sol and the committed copy are identical when whitespace is ignored, and the recorded hash is the upstream one.
• Git history shows the files were committed already reformatted in the first worker commit, so the inventory never matched this tree.
• forge-std is test-only, so this is a false provenance claim in README.md and lib/DEPENDENCIES.md, not a deployable defect. The fix is to restore upstream bytes or regenerate the inventory and amend the docs.

Coverage. All three entry points (approve, transfer, transferFrom) are recorded as holds, with traced checks and failure paths. Four additional invariant rows cover fixed supply, CREATE2 deployability, forbidden opcodes and manifest validity, all holding. One invariant row for dependency provenance points to the finding.

No proof test was attached since the only finding is below high severity. No files other than the findings file were created or changed.