The IMDwindowshopper (WWW) token is built, tested and committed on main as da447a3.

What was delivered

• src/WindowShopperToken.sol: a fixed-supply ERC-20 on OpenZeppelin v5.1.0. Name IMDwindowshopper, symbol WWW, 18 decimals. The constructor takes no arguments and mints 1,000,000,000 tokens once to msg.sender. There is no owner, mint, fee, pause, blocklist or upgrade path, so the launch floor's supply, exact-flow and privileged-call checks have nothing to trip on.
• test/WindowShopperToken.t.sol and test/WindowShopperTokenLaunch.t.sol: 42 tests covering metadata, the one-time mint, transfer and allowance success paths, every ERC-20 revert path, fuzzed conservation of supply, rejection of mint and admin selectors from both deployer and strangers, CREATE2 deployment by a factory stand-in with the 10/70/20 launch shares arriving whole, and a reachable-opcode scan for DELEGATECALL, CALLCODE and SELFDESTRUCT.
• script/DeployWindowShopperToken.s.sol: reference deploy script whose deploy() function is tested directly. It reads no environment.
• foundry.toml pins solc = "0.8.26", sets bytecode_hash = "none" and cbor_metadata = false, with no ffi or filesystem access. The built bytecode carries no metadata hash.
• lib/: forge-std v1.9.7 and the OpenZeppelin ERC20 subset vendored as plain files. No submodules, so the offline verifier can build.
• README.md documents behaviour, launch assumptions, manifest values, deployment parameters, and the operational responsibilities that remain with the deployer and requester.

Verification

forge build, forge test and forge fmt --check all pass. Tests were also run with an empty environment and with the verifier's fuzz seed, and all 42 passed. Slither is not on this machine, so it was not run.

Open items for others

Explorer verification and the independent adversarial review happen after the launch step. The token needs no post-launch configuration.

Only launch.json is new; nothing else changed.

Summary

I wrote launch.json — a custom_token manifest for the accepted IMDwindowshopper (WWW) launch.

What I verified against the accepted tree:

• src/WindowShopperToken.sol is the only contract — a minimal fixed-supply OpenZeppelin v5 ERC20. No application contracts exist, so contracts is [].
• The constructor takes no arguments (constructorArgs: []) and mints the whole supply once to msg.sender.
• Total minted = 1_000_000_000 * 10**18 = 1000000000000000000000000000 minor units → token.totalSupply.
• name = IMDwindowshopper, symbol = WWW, decimals = 18, contract identifier WindowShopperToken (≤32 chars).

Manifest fields:

• kind: "custom_token"
• economics: copied verbatim — poolBps: 7000, initialMarketCapWei: "2500000000000000000000", remainderTo: "0xee2aaa315cf7ed169f93148d30d24af9318dbb66".
• pool: pairedCurrency the IMD token 0xd34a99bc0f67ae1bbd63c660e6d0b0dd03e263b7, fee: 12500, tickSpacing: 60, initialPrice the 1:1 sqrtPriceX96 (provenance only).
• notes: 1260 chars (≤4000), describing only the contract actually present.

Checks run: forge build succeeds; forge test with the pinned FOUNDRY_FUZZ_SEED passes all 42 tests (including the protected token/owners checks). JSON validates and git status shows launch.json as the only change.

Review complete. No economic defects found in IMDwindowshopper (WWW). The findings file holds an empty findings list and a 12-row coverage record.

What the token is. A 40-line wrapper over OpenZeppelin v5.1.0 ERC20 that mints one billion tokens with 18 decimals to the deployer in the constructor. It has no owner, no mint, no burn, no fee, no hooks and no external calls.

What I verified for the economics area (Economic Security, Invariant, Flow Gap):

• The five vendored OpenZeppelin files are byte-identical to upstream v5.1.0, so the library is not a hidden attack surface.
• Supply is constant forever. The only mint is in the constructor, no burn path is reachable, and transfers to the zero address revert.
• Sum of balances equals total supply after every step of 1000 fuzzed random transfer and transferFrom sequences among seven actors.
• Every launch flow arrives whole: factory to distributor, pool and remainder wallet, distributor to claimant, and the Uniswap v4 settle balance-delta pattern for any amount up to the supply.
• No privileged selector exists. The only state-changing entry points are approve, transfer and transferFrom, and the runtime has no DELEGATECALL, CALLCODE or SELFDESTRUCT.
• The one static-analysis lead, the large numeric literal, evaluates exactly to the manifest supply and is a style note only.
• The existing 42-test suite passes and the formatter check is clean.

Noted but not reported as defects. The standard ERC-20 approve race exists as in every ERC-20. The DECIMALS constant is not wired into decimals(), but both are 18, so there is no failing input today.

The scratch test I used for the fuzz evidence was removed, so the tree is unchanged apart from the findings file.

The findings file is valid JSON, the quoted snippet matches line 26 of the source, and no tracked files were changed. Only .imd-findings.json and test/scratch/MathProbe.t.sol were written, both within the review's allowed output.

Result

No substantiated math defect. The IMDwindowshopper token is an unchanged OpenZeppelin v5.1.0 ERC20 plus one constant and one constructor mint. Across the Math Precision, Boundary and Numerical Gap guides, every failure mode either has no surface in this code or was probed and held.

What I verified

• Library provenance. All five vendored OpenZeppelin files diffed byte-identical against the upstream v5.1.0 tag, so the unchecked blocks under review are the audited ones.
• Transfer and allowance arithmetic. Balance and allowance underflow are guarded before each unchecked subtract. The infinite-allowance sentinel fires only at exactly max uint and does not bypass the balance check. Max-uint transfer, whole-balance self-transfer, self-transferFrom with max allowance, and one-wei transfers all behave exactly.
• Supply conservation. A Foundry invariant with five actors and 128,000 mixed in-range and out-of-range calls never broke sum of balances equals total supply equals 1e27.
• Constant and launch split. The supply constant folds to exactly 1e27 with no truncation. The 10/70/20 split divides with no dust, and 7e26 fits Uniswap v4's int128 delta type. The aderyn large-literal lint is stylistic only.
• Boundary enumeration. No external calls, no payable or receive paths, no bytes decoding. The only sentinel branches are the zero-address rejections, all of which revert rather than silently no-op.

One info note recorded. The DECIMALS constant drives the supply scale but is not wired to decimals(), which returns OpenZeppelin's own literal 18. Both are 18 today so nothing fails and it should not block release. It is flagged because editing one without the other would desynchronise the minted scale from the reported decimals and the manifest. The one-line fix is an override returning the constant.

Coverage. All three ABI entry points (approve, transfer, transferFrom) are holds, plus six invariant rows covering supply conservation, constant exactness, launch-share divisibility, boundary surfaces, library identity and the numerical-gap seams. Nothing was left unreached. The protected harness test could not be run locally because it depends on v4-core and launch environment variables that are not in this repository, but nothing in my area depends on it.

Review complete. The findings file is written and validated, and no repository file was changed.

Outcome: no defects in the permissions area. The token is OpenZeppelin v5.1.0 ERC20 with a constructor mint and nothing else, so the permission surface is the three standard writers plus the constructor. The file .imd-findings.json holds one info-level note and nine coverage rows.

What I verified

• Access Control. The compiled runtime's dispatcher contains exactly the eleven ABI selectors. Every other PUSH4 constant in the bytecode is an OpenZeppelin error selector, the Panic selector, or the literal 1e9, so there is no hidden function, receive, or fallback. Random-selector fuzzing reverts, and fourteen admin, mint, freeze and upgrade signatures revert from the deployer and from strangers. No caller class, including the factory and the token itself, can move a holder's balance without allowance.
• Trust Gap. The vendored OpenZeppelin files hash byte-for-byte to upstream v5.1.0, so the claim "ERC20 unchanged" is true. The constructor hands out no role and mints only to the creating address, which under the launch is the factory.
• Asymmetry. The approve and transferFrom pair mirrors correctly: fuzzing over allowance and amount shows the decrement equals the amount moved, the infinite-allowance path is the only non-decrement path, and a spender cannot self-grant another holder's allowance.

The one recorded item is the standard ERC-20 approve overwrite race, inherited from OpenZeppelin and reported as info with a concrete sequence. It requires a holder to have already trusted the spender, so it is a documentation point for integrators and not a code change.

Coverage rows mark all three listed entry points as holds, plus rows for the constructor, supply fixity, library provenance, forbidden opcodes and ether, and the reference deploy script. Nothing in my area was left unreached. The static-analysis lead about a large numeric literal is the supply constant and is not a defect.

Scratch tests live under test/scratch/Permissions.t.sol, which is gitignored and not submitted.

The review is complete and the findings file is written. No tracked files were modified.

Result: no defects found in the control-flow area for src/WindowShopperToken.sol. The findings file holds an empty list and eight coverage rows, all holds.

What I checked, per guide:

• Execution Trace. Traced approve, transfer and transferFrom from entry to final state through the stock OpenZeppelin _approve, _spendAllowance, _transfer and _update. Every path either reverts cleanly or moves exactly the requested amount, with no partial state left behind on revert. There are no sentinel branches, no external calls, no hooks, and no mid-operation configuration to mutate. The constructor mints the whole supply once to the creator, which is the factory under CREATE2.
• Periphery. The five vendored OpenZeppelin files hash byte-for-byte to the upstream v5.1.0 tag, so the base contract is unmodified. forge-std is used only by tests and the reference script.
• First Principles. The runtime contains no CALL, STATICCALL, DELEGATECALL, CALLCODE, CREATE, CREATE2 or SELFDESTRUCT in reachable code, so there is no reentrancy or callback surface. Name, symbol, decimals, supply and the 18-character contract identifier match the brief and the manifest limits. The compiled ABI has no state-changing function beyond the three listed and no receive or fallback.

Two properties were confirmed and deliberately not reported as defects, since both are standard ERC-20 behaviour the README already documents: approve uses overwrite semantics, and tokens sent to the token contract are irrecoverable. One maintenance note is recorded in the coverage row rather than as a finding: the DECIMALS constant is not wired to decimals(), so they agree only by coincidence today and no failing input exists on the current code.

Verification run: build succeeded, the existing 42 tests and my 5 scratch checks passed, and forge fmt --check was clean. The scratch test directory was removed afterwards.

I added two test files, and the full suite passes: forge build succeeds and forge test with the verifier's seed runs 57 tests, all passing. I found no defects, so there is no .imd-findings.json.

What's under test. src/WindowShopperToken.sol is OpenZeppelin v5.1.0's standard ERC-20 plus a one-time mint of the full 1,000,000,000 WWW to whoever deploys it. I compared the bundled OpenZeppelin files with the official v5.1.0 release and they are byte-identical. The earlier contributors' 42 tests are unchanged.

test/WindowShopperTokenInvariant.t.sol (the invariant tests the task asks for)

• A handler makes random calls from five accounts and also targets the token's own address. It keeps its own record of what every balance and allowance should be.
• It mixes valid transfers, approvals and transferFrom calls with calls that must fail: sending more than the balance, sending to the zero address, spending more than the allowance, spending more than the owner holds, and approving the zero address.
• A failing call must revert with the exact OpenZeppelin error and leave balances and allowances unchanged.
• Checked after every call:
  • total supply never changes;
  • balances add up to the supply;
  • every balance and allowance matches the handler's own record;
  • no spender moves more than it was approved for;
  • the token never holds ETH, and the zero address never holds tokens.
• One run is 256 sequences, about 128,000 calls, and takes about 70 seconds.
• To show these checks can actually fail, I ran the same handler against a throwaway copy of the token that burns 1 wei per transfer. Both invariants failed straight away. That check was in test/scratch/ and is not submitted.

test/WindowShopperTokenEdges.t.sol (14 tests covering cases the first suite missed)

• Sending 0 tokens to the zero address still reverts.
• transferFrom from the zero address reverts, whatever the amount.
• transferFrom of 0 succeeds even with no allowance, and moves nothing.
• Spending an allowance emits only the Transfer event.
• A revoked allowance can't be spent, and an allowance one below the maximum still goes down when used.
• Tokens sent to the token contract itself are stuck there for good, as the README says.
• Fuzz tests cover approvals and spending past the allowance or the owner's balance.

One of my own expectations was wrong at first: transferFrom(address(0), …, 0) reverts with OpenZeppelin's ERC20InvalidApprover error, not ERC20InvalidSender. That's normal OpenZeppelin behaviour, not a token bug, so I corrected the test. I also added a separate test that forces past the allowance step to confirm the sender check fires too.

I haven't committed anything. The other untracked files in the repo root (.bashrc, .claude/, etc.) were already there and aren't part of this work.

The review is complete and the report is written to .imd-findings.json. Nothing blocks this launch.

Outcome. The token is a 40-line subclass of OpenZeppelin v5.1.0 ERC20 with no overrides beyond name, symbol and a fixed one-time mint. I found no defect. Both specialist findings reproduce exactly as described, and both are correctly rated info: neither is a defect in the shipped code, so neither reopens the author's work.

What I verified

• Build and the project's own 57 tests pass, including a 128,000-call invariant run with zero reverts.
• The vendored OpenZeppelin files are byte-identical to upstream v5.1.0, confirmed by fetching the tagged sources and comparing. The permissions specialist's hash claim holds.
• The ABI has no mint, burn, owner, pause, blocklist, freeze or upgrade path. Creation and runtime bytecode are a few kilobytes, far under the deployment limits, with no DELEGATECALL, CALLCODE or SELFDESTRUCT.
• The manifest matches the contract: no constructor arguments, decimals 18, supply 1e27, schema keys only, lowercase addresses.
• A scratch test I wrote reproduces both specialist behaviours and confirms the factory cannot move a holder's balance without an allowance. It lives under test/scratch and is not kept.

Findings kept, both info

1. The DECIMALS constant drives the supply scale but decimals() still returns OpenZeppelin's own literal 18. They agree today, so nothing fails. It is a maintenance hazard only, with a one-line optional fix.
2. The standard ERC-20 approve overwrite race, inherited unchanged. It needs a spender the holder already trusted, so it is a documented trust assumption for integrators, not a token defect.

Coverage. All three listed entry points are marked holds, each with the trace behind it. I added rows for the constructor and the manifest, which I also checked. No row is unreached.