The IMDwindowshopper (WWW) token project is complete, verified and committed on main as commit dd50ded.

What was delivered

• src/WindowShopperToken.sol: a plain OpenZeppelin v5 ERC-20 named IMDwindowshopper, symbol WWW, 18 decimals. The constructor mints the full 1,000,000,000 supply once to msg.sender, which at launch is the factory. There is no owner, mint, burn, pause, blacklist, fee, upgrade path, delegatecall or selfdestruct, so it meets every item of the protected floor by construction. The contract name is 18 characters, within the manifest's 32-character limit.
• foundry.toml pins solc 0.8.26, cancun, optimizer on, bytecode_hash = "none", ffi off, no filesystem permissions. remappings.txt points at the vendored libraries.
• lib/forge-std (1.17.0) and lib/openzeppelin-contracts (5.4.0) vendored as ordinary files. No git submodules exist in the tree.
• test/WindowShopperToken.t.sol and test/DeployWindowShopperToken.t.sol: 26 tests covering metadata, supply, single constructor Transfer event, transfer and transferFrom success and revert paths with exact OpenZeppelin errors, rejection of every common admin selector, ETH rejection, a runtime opcode scan, and three fuzz tests.
• script/DeployWindowShopperToken.s.sol: a reference script whose deploy() is tested directly and reads no environment.
• README.md documents assumptions, the manifest values fixed by this source, the "After launch" section (nothing to configure), and operational responsibilities.

Check results

Check	Result
forge build (solc 0.8.26, offline)	pass
forge test with the verifier's fuzz seed	26 passed, 0 failed
forge fmt --check	pass

Not run

The protected floor test could not be executed locally because its helper contracts (LaunchLiquidity, PoolInitializationGuard, HookFlags) and v4-core are not in this workspace. My own tests replicate its token-level properties: whole supply to the deployer, exact transfers, no supply growth, no privileged move or freeze, and no forbidden opcodes. Slither was not available on this worker; the source contains none of the six rejected patterns.

I found no defects in the economics area, so .imd-findings.json has an empty findings list. It also has a coverage row for each of the three listed entry points, all holds, plus three rows for the supply invariants and launch flows I checked.

What the code is: src/WindowShopperToken.sol is a plain ERC-20 built on OpenZeppelin 5.4.0. It adds only constants, a decimals() that returns 18, and a constructor that mints all 1,000,000,000 × 10^18 tokens to msg.sender once. It has no owner, no fee or burn on transfer, no exemptions, no hooks, no mint or burn after deployment, and no upgrade path.

Checks against the Economic Security, Invariant and Flow Gap guides:

• The vendored library is unmodified. I downloaded OpenZeppelin v5.4.0 and compared ERC20.sol, IERC20.sol, IERC20Metadata.sol, Context.sol and draft-IERC6093.sol. All five are identical to the vendored copies, so the transfer and allowance logic is OpenZeppelin's own.
• Supply can't change. The only _mint is in the constructor, and no other path mints or burns. Total supply stays at 10^27 and the constructor's recipient holds all of it at deployment. Decimals match the manifest.
• Launch flows arrive exact. I wrote a throwaway fuzz test (2,000 runs) of the launch split: 10% to the distributor, any pool share up to 90% to the PoolManager, the rest to the requester, then a transferFrom out of the pool address. Every recipient got exactly what was sent, the deployer ended with nothing, and allowances went down exactly. Since there's no tax and no exemption logic, the seed and swaps through the PoolManager can't arrive short.
• Edge cases behave normally. A transferFrom to yourself spends the allowance and leaves the balance unchanged; zero-amount transfers work; spending past the allowance reverts.
• No privileged party can move a holder's balance. There's no owner, and transferFrom needs the holder's own approval.

Tests: the project's existing suite passes, 26 of 26. My throwaway test also passed, and I deleted it afterwards.

Leads I set aside: Slither reported nothing. Aderyn flagged a "large numeric literal" at line 26, but that is just the supply constant and isn't a defect. The standard ERC-20 issue where a spender can front-run a change of allowance applies here as it does to any OpenZeppelin token. I didn't report it because it isn't specific to this code and comes with no failing input.

Coverage: I checked the whole token, since it is the only source file. I couldn't run the launch-floor tests in .imd/reads/protected locally: they need the verifier's environment variables and the floor sources. Instead I checked by reading that the token meets each of their conditions.

I changed no repository files apart from writing .imd-findings.json.

Done. The manifest is written and verified, and it is the only new or changed file in the tree.

What launch.json describes

• Token: WindowShopperToken, name IMDwindowshopper, symbol WWW, 18 decimals, empty constructor arguments. The compiled ABI confirms the constructor takes no parameters.
• Supply: 1000000000000000000000000000 minor units, exactly what the constructor mints once to msg.sender.
• Contracts: none. The accepted tree has only the token, so no application contracts are named.
• Pool and economics: copied verbatim from the launch terms. IMD as the paired currency, fee 12500, tick spacing 60, the one-to-one provenance price, and the requester's economics object unchanged.
• Notes: a plain description of the token's behaviour and the launch flows, well under the 4000 character limit.

Checks run

• forge build compiled cleanly with the pinned solc 0.8.26.
• forge test with the verifier's fuzz seed passed all 26 tests across both suites.
• A JSON check confirmed the schema keys, the supply string, the empty constructor arguments and the verbatim pool and economics objects.
• git status shows launch.json as the only addition. No configuration file was touched.

The review is complete. No defects were found in the assigned area, and the findings file is written with an empty findings list and a full coverage record.

What was reviewed. The token is a single contract, src/WindowShopperToken.sol, which inherits OpenZeppelin 5.4.0 ERC20 and adds four constants plus a constructor mint. I checked it against the Math Precision, Boundary and Numerical Gap guides, then the Mindset, and traced the three entry points through the inherited _update, _approve and _spendAllowance code.

What held, with the inputs tried.

• The supply constant evaluates to exactly 1e27 at compile time. The cast from the 8-bit decimals constant is widening, so the aderyn "large numeric literal" lead is not a defect.
• Transfers of the whole supply, supply plus one, and max uint256 behave correctly. The over-balance cases revert with the exact OpenZeppelin error rather than wrapping. A 2000-run fuzz over four holders kept the sum of balances equal to total supply.
• Allowances overwrite rather than accumulate. Exact allowances spend to zero, max-minus-one allowances decrement normally, and max allowances stay infinite. An allowance larger than the balance reverts on balance and mints nothing.
• The token has no division, fee, fixed-point scale, external call, payable path, sentinel branch, bytes decoding or narrowing cast, so the three checklists have no value path to attack.
• The five vendored OpenZeppelin files the token imports are byte-identical to upstream v5.4.0, ruling out a tampered library.

Checks run. The project builds, and all 26 existing tests pass. My scratch boundary suite of 9 tests passed and was removed afterwards. The static analysis lines were reproduced and dismissed as described above.

Coverage record. Each of the three listed entry points has a holds row, plus three invariant rows covering the fixed supply, the supply constant and the absence of arithmetic on the value path. Nothing in my area was left unreached.

The permissions review of IMDwindowshopper (WWW) is complete and found no defects. The findings file at the repository root holds an empty findings list and a nine-row coverage record, and no tracked file was changed.

What was reviewed. The token at src/WindowShopperToken.sol is a 37-line fixed-supply ERC-20 inheriting unmodified OpenZeppelin v5.4.0. It has no owner, roles, modifiers, pause, blacklist, mint, burn, permit, hooks, proxy or initializer. The whole supply is minted once to the constructor's caller.

Coverage verdicts, all holds:

• approve: writes only the caller's own allowance slot. Zero spender reverts. The only other writer of that slot is the allowance spend inside the caller's own transferFrom.
• transfer: sender is always the caller, debit and credit are exactly equal, zero recipient reverts, so the burn branch of _update is unreachable.
• transferFrom: needs an allowance the holder granted. The factory and the holder themselves have no bypass. Amounts moved mirror transfer exactly.
• Invariants checked: no privileged role in the compiled ABI or storage layout, supply fixed at 1e27 and minted only in the constructor, no DELEGATECALL, CALLCODE or SELFDESTRUCT opcodes, no receive or fallback.
• Trust assumption recorded: the launch factory holds 100 percent of supply at construction by design and has no power over holders afterwards.
• Trust Gap seams: no admin setter, fee, recipient or oracle exists, so no seam can form.

Evidence gathered. The vendored OpenZeppelin ERC20, IERC20, IERC20Metadata, Context and IERC6093 files are byte-identical to upstream v5.4.0. The existing 26 tests pass. A scratch probe suite of seven extra access-control and symmetry checks passed and was then deleted. The two static-analysis leads were a clean Slither run and an aderyn large-literal style note, which is not a defect.

Not covered. Nothing in my area was left unreached. The launch manifest does not exist yet, which is expected at this stage, and the deploy script is reference-only and outside the launch path.

The control-flow review of IMDwindowshopper (WWW) is complete. It found no defects. The findings file at the repository root holds an empty findings list and seven coverage rows, and no tracked file was changed.

What the token is. src/WindowShopperToken.sol inherits OpenZeppelin 5.4.0 ERC-20 unchanged and adds only four public constants, a constructor that mints the whole supply to the deployer, and a pure decimals() returning 18. The three listed entry points are the library's own.

What I checked, by guide

• Execution Trace. Traced approve, transfer and transferFrom through _approve, _spendAllowance, _transfer and _update. Zero-address sentinels revert on every path. Allowance is checked before balance. Partial spends leave an exact, usable residual. The max allowance never decrements and max minus one does. Self-transfer and spender-equals-owner paths conserve balance. There are no hooks or external calls, so no callback or reentrancy surface. Supply is conserved under fuzzed interleavings of all three entry points.
• Periphery. Every vendored OpenZeppelin file the token compiles is byte-identical with the published 5.4.0 npm package. No vendored Solidity file differs from upstream. The vendored forge-std matches release 1.17.0.
• First Principles. The constructor mints to the constructor's caller under both CREATE and CREATE2, and the CREATE2 address prediction matches. The deployer gets no privileged path and cannot pull a holder's balance. Storage holds only the five ERC-20 slots. Every state-changing call rejects ETH, and mint, burn, permit, pause, blacklist, upgrade and initialize selectors all revert. The runtime bytecode contains no CALL, DELEGATECALL, CALLCODE, CREATE or SELFDESTRUCT.

Evidence. The project's 26 tests pass with the verifier's fuzz seed. Eleven scratch tests I wrote under test/scratch/ for the paths above also pass. The two static-analysis leads were a clean Slither run and an aderyn style note on the supply literal, whose folded value the tests confirm.

Not covered. The protected launch floor test could not run here because it imports v4-core and launch helpers that are not in this tree. The token has no transfer exemptions, so its flows to the distributor and pool manager are plain transfers, and nothing in the token's control flow depends on those helpers. No launch.json exists at the repository root, so there was no manifest to check.

Added failure-path and boundary tests, nine fuzz properties, and four stateful invariants under test/.

Offline forge build and forge test passed with the specified seed: 60 tests passed, including 16,384 randomized handler calls with zero handler reverts or discards.

No confirmed defects found. Only test/ paths changed.

The review is complete. The findings file is written with no defects and full coverage, and no repository file was changed.

Outcome: the IMDwindowshopper (WWW) token is a clean, fixed-supply ERC-20 and I found no defect to report. All five specialists reported nothing, so there was nothing to merge or drop, and my own pass confirmed their result.

What I verified

• Source and dependency. The token at src/WindowShopperToken.sol only inherits OpenZeppelin ERC20 and overrides decimals. The five vendored OpenZeppelin files it depends on are byte-identical to the upstream 5.4.0 release.
• Entry points. I ran my own scratch test over approve, transfer and transferFrom. Exact amounts move, zero-address receiver and spender revert, insufficient balance and allowance revert with the standard errors, the infinite allowance is preserved, and self-transfer does not inflate. The project's own 60 tests also pass.
• Protected floor. The constructor mints the whole supply to the deployer with no arguments and no external calls. No mint, burn, owner, pause or blacklist selector exists. Runtime code has no reachable DELEGATECALL, CALLCODE or SELFDESTRUCT, and creation and runtime sizes are far below the protocol limits. I could not run the protected test itself because it imports Uniswap v4 and launch sources absent from this tree, so I traced each of its assertions against the code instead.
• Manifest. The launch manifest uses only schema keys, with correct types, lowercase addresses, an empty constructor argument list matching the no-arg constructor, and the exact supply.
• Static analysis lead. The aderyn large-numeric-literal note is a style remark on an exact compile-time constant and is not a defect.

The findings file holds an empty findings list and nine coverage rows, one for each of the three listed entry points plus the constructor, the supply and flow invariants, deployability, the manifest and the aderyn lead. The scratch test directory was removed, so the working tree is unchanged apart from the findings file.