Implemented IMDwindowshopper (WWW) with 18 decimals and 1,000,000,000 tokens minted once to the deployer.

Vendored dependencies and documented deployment assumptions and operational responsibilities.

Validation passed with Solidity 0.8.26: forge build, all 33 tests using the supplied fuzz seed, and forge fmt --check.

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

forge build succeeded. All 33 tests passed with the supplied fuzz seed. Only launch.json is changed for submission.

The review is complete. The findings file is written and the scratch test directory is removed, leaving the tree unchanged apart from the ignored .imd-findings.json.

Outcome. The token is a plain OpenZeppelin 5.0.2 ERC-20 that mints exactly 1e27 units to the deployer once, with no other entry points. Tracing all three state-changing functions through the Execution Trace, Periphery and First Principles guides found no defect in the token's control flow. One low-severity provenance defect was found in the vendored library's documentation.

What I verified

• approve, transfer and transferFrom inherit the standard OZ paths. Zero-address sender, recipient and spender revert, insufficient balance or allowance reverts, the unlimited allowance is never decremented, and a failed step rolls back the whole call. Each is marked holds in the coverage record.
• The compiled ABI exposes only the ERC-20 methods plus the supply constant. There is no receive or fallback, so ETH and unknown selectors revert. The runtime has no reachable DELEGATECALL, CALLCODE or SELFDESTRUCT, checked with a scratch replica of the protected opcode scan.
• The project's 33 tests pass with the README's fuzz seed, and forge fmt --check is clean.
• The aderyn large-numeric-literal lead is not a defect. The constant evaluates to exactly 1e27 at compile time and the tests assert it independently.

The one finding (low). The vendored OpenZeppelin README claims the Solidity files are unmodified upstream copies and lists upstream SHA-256 checksums. Two shipped files, ERC20.sol and draft-IERC6093.sol, do not match those hashes. I downloaded the v5.0.2 tag files and diffed them. The only differences are whitespace re-wraps of one long line in each file, so behaviour is identical, but anyone checking provenance by the documented hashes gets a mismatch. The fix is to restore the byte-exact upstream files or correct the listed hashes.

Not reached. The protected launch-flow harness needs v4-core and the floor's LaunchLiquidity contract, which are not in this tree, so I could not execute it. By inspection a fee-free, hook-free ERC-20 satisfies every assertion in it. This is recorded as unreached in the coverage.

The review is complete and the findings file is written. No math defects were found in the token.

Scope covered: the Math Precision, Boundary and Numerical Gap guides applied to src/IMDwindowshopper.sol and the inherited OpenZeppelin 5.0.2 ERC20 paths it executes, plus a check that the vendored library is really upstream.

What holds

• The supply constant is compile-time exact at 10^27 and is minted once with a checked add. The aderyn large-literal lead is benign.
• Every unchecked block in _update and _spendAllowance is guarded by a strict less-than check on the same values first. Max-uint, exact-balance, balance plus one, allowance of max and max minus one, self-transfers and delegated self-transfers all behave correctly. A 2000-run fuzz over balance, amount and allowance triples found no wrap and exact pass/fail boundaries.
• Sum of balances equals total supply on every path, and the launch splits of 10, 70 and 20 percent divide 10^27 with no remainder.
• The token has no external calls, no payable or fallback entry, no bytes decoding, and the only sentinel branch is the zero address, which reverts everywhere. The compiled runtime passes the protected floor's forbidden-opcode scan.
• All 33 project tests pass with the pinned fuzz seed.

One info finding, outside the math area The vendored library README says its Solidity files are unmodified upstream copies and lists SHA-256 checksums, but ERC20.sol and draft-IERC6093.sol were reformatted with line wrapping, so their hashes no longer match. I confirmed against the upstream v5.0.2 files that the difference is whitespace only, with no behavioral effect. The fix is to restore the byte-exact files or update the README.

Output: .imd-findings.json holds 1 finding and 9 coverage rows, one per listed entry point plus the constructor, invariants, boundary surface, library integrity and opcode floor. Scratch tests were removed, so the working tree is otherwise unchanged.

The review is complete and .imd-findings.json is written with one informational finding and six coverage rows. No source or test file was changed.

What the token is. src/IMDwindowshopper.sol is a 16-line contract over OpenZeppelin 5.0.2 ERC20. The constructor takes no arguments and mints 10^27 units to the caller, which is the factory on launch. The compiled ABI exposes only approve, transfer and transferFrom as state changers plus the standard views. There is no owner, role, initializer, receive or fallback, and no payable function.

Access Control. There is no permission model to break. The caller identity comes from msg.sender through an unmodified Context, with no tx.origin or meta-transaction path. The deployer holds no right over other holders, and the inherited mint and burn helpers are internal and reachable only from the constructor. A reachable-opcode scan of the runtime found no DELEGATECALL, CALLCODE or SELFDESTRUCT.

Trust Gap. With no privileged actor and no economics beyond plain transfers, the only trusted component is the vendored library. I fetched the upstream v5.0.2 files and diffed them. Four files match byte for byte. The ERC20 implementation and the ERC-6093 error interface differ only by two re-wrapped declarations, so behaviour is identical. However the vendored README claims the files are unmodified and lists checksums that two files do not match. That is the one finding, filed as info with the exact hashes as reproduction.

Asymmetry. The approve and transferFrom pair is symmetric: set versus decrement unless unlimited, with revert paths rolling back both allowance and balances. The transfer and transferFrom pair share one _transfer path. In _update, the burn branch is unreachable because _transfer rejects a zero recipient.

Checks run. The suite's 33 tests pass under the default seed and under a second seed with 2000 fuzz runs. The build and format check pass. The aderyn large-literal lead resolves to exactly the brief's supply. Slither reported nothing and I found nothing it missed.

Coverage. All three listed entry points hold, plus rows for the constructor, the hidden-entry-point invariant and the custom-token floor. Nothing was left unreached.

The review is complete. The findings file is written at the repository root, the scratch tests are removed, and no project file was changed.

Outcome: the token's economics hold. IMDwindowshopper is an unmodified OpenZeppelin 5.0.2 ERC-20 with a single constructor mint of exactly 10^27 base units to msg.sender, no fee, burn, hook, owner, pause, mint or upgrade path. I found no defect in the assigned area and one low-severity provenance defect outside it.

What I checked, with tests run locally

• Launch flows move exactly what they say. A factory stand-in deployed the token, sent 10% to a distributor and on to a claimant, seeded 70% both by push transfer and by allowance pull, and sent the 20% remainder. Every balance was exact and the factory ended at zero.
• Conservation held. A fuzz test ran 256 random 64-step sequences mixing transfer, approve and transferFrom among four accounts. The sum of balances stayed at 10^27 on every step.
• The supply cannot change after construction. No public mint or burn exists, and the protected floor's admin-call probes have nothing to hit.
• The aderyn large-literal lead is benign. The constant equals 10^27 under three independent spellings.
• The existing suite of 33 tests passes with the README's fuzz seed, and the committed files pass the formatter check.

Findings written

1. Low, provenance. The vendored ERC20.sol and draft-IERC6093.sol were reformatted after vendoring, so they are not byte-identical to upstream v5.0.2 even though the library README says they are unmodified and lists the genuine upstream checksums. I fetched upstream and confirmed the content is identical once whitespace is stripped, so behaviour and bytecode are unaffected. The README's hashes simply do not match the tree.
2. Info. The inherent ERC-20 allowance race, where a spender front-runs an allowance change and spends both the old and the new amount. This is standard behaviour the README already documents, and I recorded it with concrete numbers only because it is the one path where an unprivileged actor can take more than a holder intended.

Coverage record: all three entry points are marked holds, plus nine invariant and flow rows. Nothing was left unreached.

Added failure-path and edge-case tests, six fuzz properties, and four-actor stateful invariants under test/.

Offline forge build and forge test pass with the required seed: 50 tests passed, including 32,768 invariant calls.

No implementation defects found. Existing files remain unchanged.

I kept one low-severity finding and the token itself checks out clean. The findings and coverage record are in .imd-findings.json, and no tracked file in the repo was changed.

Kept, low: the vendored library's provenance note is wrong (lib/openzeppelin-contracts/README.md:8)

• Merged: four specialists (economics, math, permissions, flow) reported this same issue, so it is one finding.
• The claim: the README says the OpenZeppelin files are "unmodified upstream copies" and lists their checksums.
• The mismatch: two files have different checksums from the listed ones: ERC20.sol (4a1db79b…, README says 2d874da1…) and draft-IERC6093.sol (94e5638b…, README says 4aea8724…).
• Cause: I downloaded the v5.0.2 files from GitHub; they hash to exactly the README's values. A diff shows the only change is one long line re-wrapped in each file: ERC20.sol line 284 and draft-IERC6093.sol line 121. With whitespace removed, both files are identical to upstream.
• Impact: the token behaves exactly as upstream, so there is no on-chain effect. But anyone checking the library against the published checksums gets a mismatch and can't tell a harmless reformat from a tampered base without redoing the diff.
• Fix: restore the two files byte-for-byte from upstream, or list the actual checksums and drop the word "unmodified".

Dropped, the allowance race (economics, info): I dropped this one. It reproduces, but it is standard ERC-20 approve behaviour inherited unchanged from OpenZeppelin, and the brief asks for a standard token, so it isn't a defect in this code.

My own pass found nothing new:

• The token: src/IMDwindowshopper.sol is a plain OpenZeppelin ERC-20. It mints the full supply once, in the constructor, to the deployer. It has no owner, no mint after launch, and no fee, burn or hook on transfer, so the launch's transfers move exact amounts.
• The manifest: launch.json matches the code: no constructor arguments, 18 decimals, total supply 1000000000000000000000000000, and the right name and symbol.
• Deployability: the contract is 1,752 bytes deployed and 2,644 bytes of creation code, far under the 24,576 and 49,152 limits.
• Static analysis: slither reported nothing. The aderyn note about a large number literal is only 1_000_000_000 * 10 ** 18, which is correct.
• Tests: all 50 of the project's Foundry tests pass.

Coverage: approve, transfer and transferFrom are all marked holds, and I added two invariant rows: the fixed supply, and the match between the manifest, the constructor and deployability.

No finding is critical or high, so none needed a test proof.