I've built the IMDwindowshopper (WWW) token and committed it as bcce140. On a fresh clone of that commit, forge build, forge test (22 passing, run with the verifier's fuzz seed) and forge fmt --check all pass with solc 0.8.26.

The token (src/WindowShopperToken.sol, contract WindowShopperToken):

• It is a standard OpenZeppelin v5.1.0 ERC-20 with name IMDwindowshopper, symbol WWW and 18 decimals.
• The constructor mints the whole supply of 1,000,000,000 tokens once, to the deployer. It takes no arguments.
• There is no owner and no admin: no mint, pause, blacklist, burnFrom or upgrade. Transfers have no fee or tax, so every launch flow moves exactly the amount it names.
• It has no DELEGATECALL, CALLCODE or SELFDESTRUCT; I scanned the built bytecode the same way the protected test does.
• I treated "Stop window shopping. See everything first." as a tagline, not as something the contract should do. That assumption is written in the README.

Tests (test/WindowShopperToken.t.sol) cover:

• name, symbol, decimals and the single mint to the deployer;
• that no mint or admin functions exist;
• that the contract rejects ETH;
• transfers and allowances, both successful and every failure case;
• two fuzz tests: transfers keep the total supply unchanged, and allowances are spent correctly.

I also ran a throwaway test that sets up a Uniswap v4 pool, seeds it with the token, and has a trader buy and then sell everything back. It passed, but it isn't part of the submission. I couldn't run the two protected test files themselves: they import harness files (OwnerChecks.sol, LaunchLiquidity.sol and others) that aren't in this repo, so I'm assuming the verifier supplies them.

Setup:

• foundry.toml pins solc 0.8.26 with bytecode_hash = "none", the optimizer on, and no ffi or filesystem access.
• forge-std, OpenZeppelin, v4-core and solmate are committed as plain files under lib/ (no submodules). v4-core and solmate are there only so the protected tests can compile.
• The sandbox wouldn't let me delete the .gitmodules files inside the cloned libraries, so .gitignore excludes them and none are committed.

Docs: README.md covers how the token behaves, the assumptions, the deployment and launch values (IMD pair, 1.25% fee, tick spacing 60, the requester's economics), and operational duties. There are none: no settings to change after launch and no keys needed. I didn't write a launch.json, a deploy script, or any transactions.

The commit is authored under your email.

Done. launch.json is written and verified, and it is the only file added or changed in the tree.

What the manifest says

• Kind custom_token, token contract WindowShopperToken with name IMDwindowshopper, symbol WWW, 18 decimals.
• Empty constructorArgs. The compiled ABI confirms the constructor takes no parameters.
• totalSupply is one billion tokens in minor units, exactly what the constructor mints to msg.sender.
• No application contracts, since the accepted tree contains only the token.
• pool and economics copied verbatim from the launch reference: IMD pair address, fee 12500, tick spacing 60, the one-to-one provenance price, and the requester's economics object.
• Notes describe only the token that exists: fixed supply, no admin or mint path, exact transfers, no DELEGATECALL or SELFDESTRUCT.

Checks run

• forge build compiled cleanly.
• forge test with the verifier's fuzz seed: 22 passed, 0 failed.
• A JSON check confirmed only the schema's six top-level keys, the exact economics object, the supply value, the lowercase pair address, and notes well under the 4000 character limit.
• The protected test cannot run locally because it needs the floor harness and launch environment variables, but the token meets every condition it checks: whole supply minted to the deployer, decimals 18, plain transfers, no mutating functions beyond approve, transfer and transferFrom.

I found no defects in WindowShopperToken. .imd-findings.json has an empty findings list and a coverage row for each of the three entry points, plus four rows for the supply rules, launch flows and the static-analysis lead. The file is valid JSON and nothing in the repository was changed.

What the code is: src/WindowShopperToken.sol is a 22-line contract built on OpenZeppelin v5.1.0 ERC20. It takes no constructor arguments, mints 1_000_000_000 * 10 ** 18 (1e27) to msg.sender once in the constructor, and overrides nothing. So every entry point runs the library code as written. I read the vendored ERC20.sol and Context.sol code; it matches upstream v5.1.0.

Coverage by guide:

• Execution Trace:
  • Mismatched inputs and special values: zero sender/receiver/spender are rejected. A maximum allowance is never reduced, and a smaller one drops by exactly the amount spent.
  • Partial updates: in transferFrom, the allowance is spent before the transfer and the whole call reverts together, so no half-finished state survives.
  • Leaks, stale reads, outside calls: nothing deducts a fee, nothing is read and then reused after a change, and the contract makes no outside calls.
  • Approval residuals: these are the standard ERC-20 approve race, which the README already documents, so I didn't report it.
• Periphery: the inherited base is the only helper code. Its one unchecked subtraction comes after a balance check. Its unchecked additions can't overflow because the supply is fixed at 1e27, far below 2^256.
• First Principles:
  • Supply: it can't grow, because the mint function is only called in the constructor and there is no mint, burn or owner function.
  • Edge cases: self-transfer, self-transferFrom, zero amounts and whole-balance moves all hold.
  • Launch requirements: decimals are 18.

Checks run:

• The project's 22 tests pass.
• I wrote a temporary fuzz test (256 runs, since deleted) of the launch flows from a factory-like deployer: a share to the distributor, a transferFrom on a maximum allowance, and a self-transferFrom on a limited allowance. Every amount arrived exactly and the supply stayed the same.
• A scan of the deployed bytecode found no CALL, DELEGATECALL, CALLCODE, STATICCALL, CREATE or SELFDESTRUCT opcodes.

Static analysis: Slither reported nothing. Aderyn's large-numeric-literal note on line 17 is only about style: the value is 1e27, which matches the README and the stated supply.

Not covered: I couldn't run the protected launch test (Token.protected.t.sol). It depends on harness files and environment variables that aren't in this tree, so I checked the same properties with my own fuzz test instead. No launch.json exists yet, so there was no manifest to review.

I wrote the missing tests for the IMDwindowshopper (WWW) token. forge test passes: all 39 tests, run with the verifier's fuzz seed. I found no defects in the token, so I didn't write .imd-findings.json.

The commit failed. This machine has no git name or email set, so git refused to commit. I didn't set one, because that's machine configuration I'm not allowed to change. Both new test files are staged and ready; the commit needs to be made by whatever does the upload.

The token is a plain fixed-supply ERC-20 built on OpenZeppelin's standard code. It has no owner, no way to mint more, no fees and no pause. The earlier contributor's tests already covered the basics: name, symbol, supply, transfers, approvals and the main ways a call can fail. I added two files:

• test/WindowShopperToken.invariant.t.sol — random call sequences, which the acceptance criteria require because the token keeps balances. A helper contract has five accounts make random transfers, approvals and spends of approvals, plus calls involving the zero address. It keeps its own record of what every balance and approval should be. After each call it checks that:

  • total supply stays at 1,000,000,000 × 10¹⁸;
  • the balances add up to the supply, and the zero address holds nothing;
  • every balance and approval matches the helper's record;
  • every call that should fail does, with the exact expected error, and every call that should succeed does;
  • name, symbol and decimals never change.

  It ran 256 sequences of 64 calls each (16,384 calls), and every one passed.

• test/WindowShopperToken.edges.t.sol — 16 more tests for edge cases and failure paths, including:

  • transferring to or from the zero address through an approval;
  • transferring one unit more than the supply, or the largest possible number;
  • a new approval replacing the old one rather than adding to it;
  • an approval used up exactly, after which spending fails;
  • zero-amount transfers needing no approval, and holders needing an approval to spend their own tokens through one;
  • three randomised tests covering approvals, onward transfers, and which check a spend through an approval hits first, the approval or the balance.

The review is complete. The findings file is valid JSON and no tracked file changed. Nothing further is needed.

Result: no defects in the math area. The findings file at .imd-findings.json holds an empty findings list and nine coverage rows, one for each of the three entry points plus six invariant and boundary rows.

What the token is. A verbatim OpenZeppelin v5.1.0 ERC20 with one constant and a single constructor mint. The vendored library files are byte-identical to upstream v5.1.0, so the audited arithmetic is the real one.

What I checked against the Math Precision, Boundary and Numerical Gap guides:

• The only arithmetic the token adds is the compile-time constant for the supply. It equals exactly 1e27, which also answers the aderyn large-literal lead.
• The unchecked blocks in OpenZeppelin's transfer and allowance paths are each preceded by the guard that makes them safe, and the fixed supply bounds every balance.
• Max-uint transfers, supply-plus-one, exact-balance, zero-value, self-transfers, exact allowance drain, and an allowance of max-minus-one all behave correctly. Only exactly max is treated as infinite.
• Supply is conserved under a fuzzed fan-out and fan-in across accounts.
• The launch splits of 10%, 50%, 40%, 2% and 8% of the supply divide with no remainder, and the share arithmetic cannot overflow.
• The supply fits Uniswap v4's int128 deltas, and the opening price derived from 900 IMD for the whole supply lies well inside TickMath's bounds for either currency ordering, with single-sided liquidity fitting uint128.
• There are no external calls, payable paths, decoded bytes, or sentinel branches beyond OpenZeppelin's zero-address reverts.

Not reached. The protected launch harness itself could not be run, because its helper sources and environment are not in this tree. My price and liquidity bound checks reproduce its arithmetic independently in a scratch test, which passed along with the project's 22 existing tests.

Review complete. No defects found in the assigned area, and the findings file is written at .imd-findings.json with an empty findings list and a coverage row for each of the three entry points plus five checked invariants.

What was reviewed

• The token is a 22-line wrapper over OpenZeppelin v5.1.0 ERC20 in src/WindowShopperToken.sol. The vendored OpenZeppelin files are byte-identical to upstream v5.1.0.
• The constructor is the only privileged moment. It mints the full supply once to the deployer and hands out no role, owner, initializer or settable parameter.
• The compiled ABI holds exactly three state-changing functions and no receive or fallback. ETH and unknown selectors revert. The runtime has no reachable DELEGATECALL, CALLCODE or SELFDESTRUCT.

Access control. Every entry point is public by design, guarded only by the caller's own balance or an allowance the holder granted. The deployer cannot pull a holder's balance, nobody can set another holder's allowance, and the zero address cannot be used as a source to mint.

Asymmetry. Both movers route through the same internal update. The only difference is the allowance check, including self-transferFrom needing a self-allowance, which is the standard shape. The burn branch is unreachable because both transfer paths reject the zero receiver, so the supply is fixed.

Trust gap. No privileged actor survives deployment, and there is no fee, recipient, setter or price formula, so the access times economics times asymmetry seams have no code to live in.

Verification run. The 22 existing tests pass, and a scratch suite of 8 probes with 2,000 fuzz runs passed covering factory powers, allowance accounting, zero-address paths, supply conservation and the exact launch flows. The scratch directory was removed afterwards. The protected launch test could not be executed locally because its harness files and environment variables are not in this tree, but every behaviour it asserts was checked directly.

The well-known ERC-20 approve front-running caveat is present, documented in the README, and standard behaviour, so it is noted in coverage rather than reported as a defect. The aderyn large-numeric-literal lead on line 17 is a style note with no behavioural effect.

The review is complete. No defects found in the economics area, and the findings file is written with full coverage.

What was reviewed. The token is a 20-line wrapper around OpenZeppelin ERC20 that mints the whole supply once to the deployer. I checked it against the Economic Security, Invariant and Flow Gap guides from the Pashov reference and the Senior Auditor's Mindset.

What I verified

• Vendored OpenZeppelin files (ERC20, IERC20, IERC20Metadata, Context, IERC6093) are byte-identical to upstream v5.1.0, so the token's whole behaviour is the audited library's.
• The compiled ABI exposes exactly the three listed state-changing entry points, with no receive or fallback, no mint, burn, owner or initializer.
• A scratch test with a real Uniswap v4 PoolManager at fee 12500 and tick spacing 60 reproduced the launch flows: factory to distributor, claim, single-sided seed, remainder forward, and a buy and sell by an unexempted trader. Every amount arrived whole and supply stayed at 1e27.
• A stateful invariant run over random transfers, approvals and transferFroms never broke sum of balances equals totalSupply.
• Runtime code contains no DELEGATECALL, CALLCODE or SELFDESTRUCT. The contract rejects ETH.
• The aderyn large-numeric-literal lead is style only. The literal evaluates to exactly 1e27.

Result. The findings file holds an empty findings list and eight coverage rows: one per entry point, plus the invariants and flows checked, all marked holds. The existing 22 project tests pass. Scratch tests were removed, so the tree is unchanged apart from the findings file.

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

What was checked. The token at src/WindowShopperToken.sol is a plain OpenZeppelin v5.1.0 ERC20 with no owner, no mint, no fee, no hooks, and no constructor arguments. The vendored ERC20 implementation is stock and unmodified. I traced all three state-changing entry points (approve, transfer, transferFrom) through the inherited code and confirmed each guard, state change and revert path with a scratch Foundry test, which passed and was then removed. The repository's own 39 tests, including a 16,384-call invariant run, also pass.

Panel reconciliation. All five specialists reported no findings. Nothing was dropped or merged because there was nothing to reproduce. The aderyn "large numeric literal" lead is style only: the constant is folded at compile time to exactly 1e27, matching the manifest.

Launch floor. The constructor mints exactly the manifest's supply to msg.sender, decimals are 18, the reachable runtime has no DELEGATECALL, CALLCODE, SELFDESTRUCT or any external call, and the creation code is far below the size limits. launch.json uses only schema keys, an empty constructorArgs list that matches the no-arg constructor, lowercase addresses and a contract name within 32 characters.

Output. .imd-findings.json holds an empty findings list and eight coverage rows: the three entry points marked holds, plus rows for the supply, privilege, opcode, static-analysis lead and manifest invariants. No repository files were changed.