Implemented IMDwindowshopper (WWW) with 18 decimals and exactly 1,000,000,000 tokens minted once to the deployer. No admin or further minting powers.

Dependencies are vendored; deployment and operations are documented in README.md.

Passed forge build, seeded forge test, and forge fmt --check: 26 unit/fuzz tests plus two stateful invariants. External launch/pool integration remains the verifier’s check.

I found no defects in the math area (Math Precision, Boundary and Numerical Gap). .imd-findings.json has an empty findings list and a coverage row for each of the three entry points, plus one for the supply invariant. All are marked holds.

What the code is: src/IMDwindowshopper.sol is a plain OpenZeppelin v5 ERC-20. Its only addition is the constant INITIAL_SUPPLY = 1_000_000_000 * 10 ** 18, which the constructor mints once to msg.sender. It doesn't override any transfer, allowance or update logic, and the vendored OpenZeppelin ERC20.sol matches the clean committed tree.

What I checked:

• Math Precision: The supply constant works out to exactly 10^27 with 18 decimals, so there is no truncation and no narrowing cast. Nothing in the token divides or rounds.
• Boundary: transfer and transferFrom check the balance and allowance before the unchecked subtraction, so a transfer of 10^27 + 1 reverts. Transfers of 0 and of the whole supply deliver exactly. An allowance of type(uint256).max is treated as unlimited and never decreases; max - 1 decreases by exactly the amount spent.
• Numerical Gap: The unchecked addition to a recipient's balance can't overflow, because balances are capped at a fixed total of 10^27, far below 2^256. No function can mint or burn after the constructor.
• Tests: The project's own 27 tests pass. I also ran a temporary boundary test and a 512-run fuzz test showing balances always add up to the full supply; both passed, and I deleted them afterwards. The tree has no changes apart from the findings file.

Static-analysis lead: Aderyn flagged the large number at src/IMDwindowshopper.sol:10 as low severity. That's style only: the value is correct and readable, so I didn't report it as a defect.

Not covered: the deployment manifest (there's no launch.json in the tree yet) and areas outside math. Nothing outside my area looked severe enough to report, and I had time to cover my whole area.

I found no defects in the permissions area: Access Control, Trust Gap and Asymmetry. .imd-findings.json holds an empty findings list and one coverage row for each of the three entry points, plus four rows for invariants I checked. No other files were changed.

What I reviewed: src/IMDwindowshopper.sol and the ERC-20 code it inherits from the vendored OpenZeppelin v5.0.2 (ERC20.sol, Context.sol). I read the Senior Auditor's Mindset and the three assigned guides and checked the code against each, myself; no helpers were used. The existing test suite passes (27/27).

Access Control

• The token has no owner, roles, modifiers, mint or burn entry point, pause, blacklist, upgrade path or initializer. The constructor only mints all 10^27 units to whoever deploys it.
• After deployment the deployer holds tokens but has no special power.
• The token contains no delegatecall, selfdestruct or assembly, so there is no proxy or confused-deputy path.
• approve only sets the caller's own allowance.
• transferFrom always spends the caller's allowance, including when someone moves their own tokens. An unlimited (max uint256) approval is left as is when spent, and a failed transfer undoes the allowance change.

Asymmetry

• approve and the allowance spend inside transferFrom write the same storage with the same checks. The only difference is that spending emits no Approval event, which is standard in this OpenZeppelin version and noted in the README.
• Transfers have no branches by caller type, so the launch flows (factory, Uniswap v4 PoolManager, distributor) move exactly the amounts they state.

Trust Gap

• There is no privileged actor, fee or price formula, or rule that treats one class of holder differently. The ways these three can combine into an exploit don't exist here.

Leads I checked and dropped

• The only static-analysis lead was Aderyn's low-severity "large numeric literal" at line 10. It is the intended supply constant (1,000,000,000 × 10^18), so I did not report it.
• The well-known ERC-20 approve front-running race is standard behaviour, not a defect in this code, so I left it out.

Limits: no proofs were needed because there are no findings. I did not verify the claim that the vendored OpenZeppelin files are byte-for-byte the v5.0.2 release, since the archive hashes can't be checked offline. I read the relevant functions and found them consistent with the standard code. A clean review does not prove the code has no defects.

I found no defects in the IMDwindowshopper (WWW) token from the Economic Security, Invariant and Flow Gap reviews. .imd-findings.json holds an empty findings list and a coverage row for each of the three entry points, all marked holds, plus four rows for the invariants and flows I checked.

What the code is: src/IMDwindowshopper.sol is a standard OpenZeppelin ERC-20 that mints exactly 10^27 units (1,000,000,000 tokens with 18 decimals) once, to the deployer (the launch factory), in its constructor. It has no owner, fee, burn, pause, blacklist or extra mint function. I compared the vendored OpenZeppelin files byte for byte with the upstream v5.0.2 release, and they are identical.

Economic Security:

• There is no fee, rebase or callback that could make an amount arrive short.
• Nothing calls out to another contract, so there is no outside dependency to fail.
• Sending to address(0) reverts, and nothing a holder does can block the pool or the distributor.

Invariants:

• Fixed supply: the sum of all balances always equals the total supply of 10^27. Only the constructor's mint changes the total, and every later move debits and credits the same amount.
• Allowances: a transferFrom reduces a normal allowance by exactly the amount sent, and leaves an unlimited allowance unchanged. A failed call reverts entirely, so nothing is half-done.
• No privileged power: no account can increase the supply or move or freeze someone else's balance.

Flow Gap: the launch moves each amount exactly:

• 10% from the factory to the distributor, then out to claimants
• the pool share to the Uniswap v4 PoolManager, then to and from traders
• the rest to the requester

Checks run:

• The existing tests: 27 passed.
• Two temporary fuzz tests of 2,000 runs each, both passed. One varied the pool share from 0% to 90% and the receiving addresses; the other covered approve/transferFrom with normal and unlimited allowances and sending to yourself. I deleted them afterwards and changed no repository files.

Not reported:

• The aderyn "large numeric literal" warning at line 10 is a style note: the number is exactly 10^27, as intended.
• The general ERC-20 risk that changing an allowance can be front-run applies to every ERC-20, so I didn't count it as a defect here.

Not covered: I didn't run the protected launch tests. They need the factory, PoolManager and launch-number settings that only the verifier provides. With no fee or exemption logic in the token, I don't expect them to fail.

The token takes no constructor arguments, so its manifest entry should have an empty constructorArgs list.

I wrote launch.json for the IMDwindowshopper (WWW) launch. It is valid JSON, forge build succeeds, and forge test passed all 27 tests with the required fuzz seed. Nothing runs the manifest itself against the schema, though, so I checked it by reading it against the schema rules. The only change in the tree is launch.json; I haven't committed it.

• Token: the contract is IMDwindowshopper, with name "IMDwindowshopper", symbol "WWW" and 18 decimals. constructorArgs is empty because the accepted constructor takes no parameters. totalSupply is "1000000000000000000000000000", which is what the constructor mints to msg.sender (1,000,000,000 × 10^18).
• Contracts: none. The accepted tree contains only the token.
• Pool: paired with IMD at 0xd34a99bc0f67ae1bbd63c660e6d0b0dd03e263b7, fee 12500, tick spacing 60, and initial price 79228162514264337593543950336 (one to one, recorded for reference only).
• Economics: copied exactly from the brief.
• Notes: a short description of the token. It is a plain ERC-20 with a fixed supply and no owner, fees, burns, pauses or blacklists, and the launch deploys no other contracts.

The review is complete. The findings file is written with an empty findings list and seven coverage rows, and no project file was changed.

Outcome: no defects found in the control-flow area. IMDwindowshopper is a plain OpenZeppelin v5.0.2 ERC20 with one constructor mint and no added logic, so every entry point resolves to unmodified library code.

What I verified:

• Execution Trace. Traced approve, transfer and transferFrom through the base contract. Every revert path (zero receiver, zero spender, insufficient balance, insufficient allowance, zero sender) fires before any storage write, so no partial state is possible. Finite allowances are decremented before the balance move and both roll back together on failure. Max allowance is never decremented. The launch flows (factory to distributor, distributor to claimant, factory to pool, pool to trader and back) move exact amounts.
• Periphery. The five vendored OpenZeppelin files are byte-identical to the upstream v5.0.2 tag. _update is not overridden, _mint and _burn have no external caller, and decimals() returns 18.
• First Principles. The constructor mints exactly 10^27 units to the immediate msg.sender, confirmed under CREATE2 from a factory stand-in with a different transaction origin. The compiled ABI has only the three listed state-changing functions, no receive or fallback, and the constructor is nonpayable. The reachable-opcode scan from the protected floor finds no DELEGATECALL, CALLCODE or SELFDESTRUCT. The protected floor's privileged-call list all reverts from both deployer and stranger, leaving holder balances intact.

Checks run: forge build, the project's 26 unit/fuzz tests and 2 stateful invariants under the README seed (all pass), forge fmt --check on project files (clean), and a 6-test scratch probe under test/scratch/ (all pass, not kept). Slither and aderyn output had nothing at or above low in my area. The aderyn large-literal note is style only, and the literal evaluates to the intended 10^27.

Not reached: the real Uniswap v4 seed and swap in the protected test, which needs the launch harness and contracts outside this repository. Nothing in the token can tax or block those flows, so I expect it to pass, but I did not execute it.

Added failure-path, boundary, and fuzz tests, and expanded stateful invariants.

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

Only test/ changed. No implementation defects were found.

I found no defects in the IMDwindowshopper (WWW) token. .imd-findings.json holds an empty findings list and a coverage record for all three entry points, each marked holds.

What I checked:

• The token: src/IMDwindowshopper.sol is a plain OpenZeppelin ERC-20 that changes nothing in it. Its only extra code is the constructor, which mints 1_000_000_000 * 10**18 (10^27) once to msg.sender. It has no owner, no way to mint more, and no pause, blacklist, fee or burn. Transfers move exactly the amount sent, so the payout to the distributor, the pool seed and pool swaps all arrive in full.
• The OpenZeppelin library: I downloaded the v5.0.2 release archive. Its SHA-256 matches the one in DEPENDENCIES.md. ERC20.sol and the four files it imports are byte-identical to the release. So approve, transfer and transferFrom behave exactly as upstream: they reject the zero address, revert on a short balance or allowance, and leave an unlimited allowance untouched.
• The manifest: the constructor takes no arguments and constructorArgs is []. The supply, 18 decimals, contract name (16 characters) and empty contracts list all match the code. The economics are in the expected format.
• Tests: forge test passed all 50 existing tests.
• Specialists and static analysis: all four specialists and the tester reported nothing, so there was nothing to reproduce or merge. Aderyn flagged the "large numeric literal" at line 10; that is a style remark, and the value is the correct 10^27, so it is not a defect.

Limits: I did not run the protected floor tests. They need the factory's harness and environment variables, which this tree doesn't have. I reviewed the code they check by hand instead. A clean review is not proof that no defects exist.

git status shows no change to tracked files, so the findings file is probably ignored by git. I wrote no proof tests, since there were no findings to prove.