Implemented ImdWindowShopper (IWS) with 18 decimals and exactly 1,000,000,000 tokens minted once to the deployer.

Dependencies are vendored for offline builds. Deployment assumptions and operational responsibilities are documented in README.md.

Validation passed with Solidity 0.8.26:

• Offline build
• All 33 tests, including fuzzing with the required seed and stateful invariants
• forge fmt --check

The full protected launch integration remains for the independent verifier.

I found no exploitable defect in ImdWindowShopper (IWS). The only finding is informational: the dependency integrity check the project documents fails. My findings and coverage are in .imd-findings.json. The full test suite passed (33 tests, including fuzz and invariant tests) and forge fmt --check is clean; I made no other file changes.

What the token is: src/ImdWindowShopper.sol is a plain OpenZeppelin v5.4.0 ERC20. It mints 10^27 units to msg.sender once, in the constructor. It has no overrides, no owner, no assembly and no hooks.

Coverage of my three guides:

• Execution Trace: I traced approve, transfer and transferFrom from entry to final state.
  • No mismatched inputs, fees or callbacks can make a transfer arrive short, so the factory, distributor and PoolManager flows move exactly what they say.
  • An unlimited (max) allowance is never reduced, and a failed call undoes everything, including the allowance change.
  • Allowance left over after a spend is ordinary ERC20 behaviour, and the README already documents it.
• Periphery: I diffed the vendored OpenZeppelin files against the upstream v5.4.0 release; they are byte-identical, so nothing is hidden in the base contract.
• First Principles: I checked every assumption the code makes:
  • The supply can never grow after deployment.
  • decimals() returns 18, and the name and symbol are exact.
  • No privileged call can move or freeze a holder's balance.
  • There is no DELEGATECALL or SELFDESTRUCT.

All three entry points are marked holds, plus three invariant rows.

Finding 1 (info), DEPENDENCIES.md:4: the file says the vendored files are unmodified, but sha256sum --check lib/SHA256SUMS fails on 7 forge-std files. I compared them with the upstream v1.9.7 archive, whose hash matches the one the file records. The changes are whitespace and line-wrapping only, the kind forge fmt makes; with whitespace removed, every file matches upstream. forge-std is used only by tests, so nothing deployed is affected. The fix is to restore the upstream formatting, or regenerate SHA256SUMS and drop the "not modified" claim.

Limits: I had no Uniswap v4 or launch harness, so the protected integration tests did not run here; the token has no transfer hooks that could affect them. Slither and Mythril were not run; the supplied static-analysis output showed only the aderyn large-number-literal note, which is not a defect.

After my run, git status shows untracked dotfiles and folders I did not create, such as .bashrc, .gitconfig, .gitmodules, .mcp.json, .claude/ and .vscode. They look like environment artifacts, so I left them alone. Check them before you submit, since a submission that changes files is rejected.

Created launch.json matching the accepted token, exact supply, empty constructor arguments, and required pool and economics values.

Manifest checks and forge build passed. forge test passed all 33 tests with the supplied fuzz seed. Only launch.json is changed for submission.

I added test/ImdWindowShopper.adversarial.t.sol. The whole suite now passes with the verifier's fuzz seed: 55 tests across 4 suites, 0 failures. forge build is clean, and the only change in the working tree is that new file.

What was already there: the earlier work already had a good unit and fuzz suite, plus one invariant suite. That invariant suite only made calls that were meant to succeed. I kept all of it and added to it.

What the new file adds:

• A second invariant suite, 256 runs of 64 random calls each. The supply starts with a factory-style contract, as it does at launch, and five actors call in random order. Mixed in with normal transfers, approvals (some unlimited) and delegated spends are calls that must fail:

  • spending more than a balance;
  • spending more than an allowance;
  • sending to the zero address;
  • calling admin functions that don't exist (mint, burn, burnFrom, pause, blacklist, transferOwnership).

  Each failing call must revert with the exact ERC-20 error. The invariants are that the total supply never changes, the actors' balances add up to the full supply, and every balance and allowance matches separately tracked expected values.

• Edge cases:

  • calls made from the zero address;
  • an owner approving themself;
  • the same transfer or delegated spend made twice;
  • allowances larger than the supply;
  • an allowance of one less than the maximum, which shrinks as it's spent, while the true maximum never does.

• Bad calls: sending ETH to functions that don't accept it, cut-off calldata, and unknown function selectors (also fuzzed) all fail.

• Launch flow: a helper contract deploys the token and splits it to distributor, pool and remainder in a single call, as the factory does in one transaction. A fuzz test checks the amounts come out exact for any pool share up to 90%, and deploying twice with the same salt fails.

Defects: none found, so I didn't write .imd-findings.json. The token is a plain OpenZeppelin v5.4.0 ERC-20 with no owner, mint, burn or transfer fee. During the work one test failed. That was my wrong expected error, not a contract bug: the token checks the allowance before the owner address, which is the library's normal behaviour. I corrected the test.

I couldn't run the protected launch checks here. They need the network's launch harness and Uniswap v4, which only the verifier has. The new file isn't committed.

The review is complete and written to .imd-findings.json. The working tree is otherwise untouched.

Result: no permission defects in the token. ImdWindowShopper is an eleven-line contract inheriting the unmodified OpenZeppelin v5.4.0 ERC-20. It has no owner, roles, initializer, proxy, pause, blacklist, mint, burn or exemption list, so the Access Control, Trust Gap and Asymmetry failure modes have no surface to attach to.

What I verified for each listed entry point:

• approve writes only the caller's own allowance row and rejects a zero spender. No other actor can set a holder's allowance.
• transfer debits only the caller, rejects a zero recipient, and treats the factory, distributor, pool manager and ordinary holders identically. Launch flows arrive whole.
• transferFrom spends allowance before moving tokens, keeps max allowance unreduced, and reverts atomically on short balance or allowance. The deployer has no bypass.

Supporting checks: the constructor mints the full supply once to msg.sender with no arguments. The compiled ABI exposes only the three state-changing ERC-20 functions plus views. An opcode walk of the runtime found no DELEGATECALL, CALLCODE or SELFDESTRUCT. All 33 local tests, the fuzz runs and the invariant suite pass, and forge fmt --check is clean.

One informational finding. DEPENDENCIES.md tells reviewers to confirm vendored files with a hash check, but that check fails for seven forge-std files. The OpenZeppelin files all pass, so production bytecode is unaffected. The fix is to regenerate the sums file from the forge-std release actually vendored.

The coverage record has ten rows: the three entry points and seven invariants, all holds except the dependency-hash note, which points at the finding. No proof test was needed since nothing rose to high or critical.

The review is complete and the findings file is written. Nothing else needs to be requested.

Outcome: the token holds in my area. ImdWindowShopper is the unmodified OpenZeppelin v5.4.0 ERC-20 with one constructor mint of exactly 10^27 units to msg.sender, no further entry points, and no external calls. I found one low-severity defect, outside the economics area, and recorded it with a concrete reproduction.

What I checked, against the Economic Security, Invariant and Flow Gap guides:

• Supply conservation and growth. The only mint is in the constructor. The ABI exposes exactly approve, transfer and transferFrom. The existing stateful invariant suite plus a scratch fuzz test confirmed the sum of balances equals total supply under arbitrary addresses, including the token and factory addresses.
• Launch flows. The ten percent swarm share leaves the factory whole and is claimable whole. Pool round trips move exact amounts for 1 wei and large transfers. No fee, burn, hook or callback exists, so the protected seed and swap checks have nothing to trip on.
• Flow gaps and reentrancy. A reachability scan of the runtime bytecode found no CALL-family, CREATE or SELFDESTRUCT opcodes. There is no receive or fallback, so stray ETH reverts.
• Economic trust assumptions. No owner, pauser, blacklist, minter or upgrade role exists. The only trusted party is the launch factory holding the initial supply, which is the design.
• Dependency integrity. The five OpenZeppelin files are byte-identical to the v5.4.0 archive.

The one finding (low). The dependency notes say the vendored files are unmodified and tell the reader to verify them with the recorded hash list. That check fails on seven forge-std files. The recorded hashes are the genuine upstream v1.9.7 hashes. The vendored copies were reformatted after hashing. With whitespace stripped they are identical to upstream, and forge-std is test-only, so there is no runtime impact. The fix is to restore the byte-exact upstream files or regenerate the hash list and amend the note.

Coverage record. All three entry points are marked holds, with six additional rows for the invariants and flows I traced. The scratch test was removed, and the working tree contains only the findings file and the pinned inputs.

The review is complete and .imd-findings.json is written with one low finding and eight coverage rows. Git status is clean because .gitignore excludes the findings file and the scratch test, and no tracked file was changed.

Outcome for the assigned area (Math Precision, Boundary, Numerical Gap): no defects. The token is a 17-line fixed-supply OpenZeppelin v5.4.0 ERC-20. It contains no division, no narrowing casts, no scale conversion, no external calls, no payable path and no bytes decoding, so most failure modes in the three guides have no surface here. What does exist was traced and tested:

• Supply constant 1_000_000_000 * 10 ** 18 evaluates to exactly 1e27, the 28-digit manifest literal, and decimals() is 18. The aderyn large-literal lead is not a defect.
• Launch split of 10%/80%/10% divides 1e27 with zero remainder, so the swarm share, pool seed and remainder are exact. 1e27 is far below the int128 bound of Uniswap v4's delta accounting.
• Transfer arithmetic in OpenZeppelin's _update checks balance before the unchecked subtraction. The unchecked addition is bounded by total supply. Amount 0, full balance, self-transfer, max uint, zero recipient and zero sender all behave as the README documents.
• Allowance arithmetic checks before the unchecked decrement, keeps the max-uint sentinel, treats max-minus-one as finite, and restores the allowance on every revert path.
• Invariants of constant supply and sum-of-balances held across the project's 256x64 invariant runs, its 1024-run fuzz tests and my scratch fuzz. The full project suite passes (33 tests) and forge fmt --check is clean.

One low finding, outside the area: DEPENDENCIES.md tells the operator to verify vendored files with sha256sum --check lib/SHA256SUMS, but in the committed tree that check fails for seven forge-std files, including Vm.sol. All six OpenZeppelin files match, so the production dependency and bytecode are unaffected. The mismatch may come from the verifier's toolchain swapping forge-std, and contributors cannot edit lib/, so the fix is documentation-side. The finding carries the exact command and expected-versus-actual output.

Coverage: all three ABI entry points (approve, transfer, transferFrom) are marked holds, plus five invariant and boundary rows. Nothing was left unreached. Slither and Mythril were not run beyond the supplied static-analysis output.

The review is complete and .imd-findings.json is written at the repository root. No source files were changed.

Outcome: one low-severity finding, merged from the four specialists, who all reported the same root cause. The token itself is clean.

What I verified

• The token is an unmodified OpenZeppelin v5.4.0 ERC20 with a parameterless constructor that mints 1e27 units to msg.sender. No owner, mint, burn, pause or blacklist path exists, and the ABI exposes only the three listed entry points plus views.
• The five vendored OpenZeppelin files compiled into the token are byte-identical to the upstream v5.4.0 archive, which I re-downloaded and checked against the archive hash DEPENDENCIES.md records.
• The build succeeds and all 55 project tests pass, including the invariant suites. Creation and runtime bytecode are far under the protocol size limits.
• launch.json uses only schema keys, lowercase addresses, an empty constructorArgs list matching the zero-parameter constructor, and a totalSupply equal to what the constructor mints.
• The aderyn large-numeric-literal lead is a compile-time constant with no defect.

The kept finding (low): DEPENDENCIES.md states the vendored files are unmodified and directs the reader to sha256sum --check lib/SHA256SUMS. That command fails on seven forge-std files. The recorded hashes are the genuine upstream v1.9.7 hashes. The vendored copies differ only in whitespace, which I confirmed by comparing whitespace-stripped hashes against the extracted archive. forge-std is test-only, so there is no effect on deployed bytecode, only a false provenance claim. The fix is to restore the seven files byte-for-byte or to regenerate the sums and reword the claim.

Coverage: all three entry points answered as holds, with extra rows for the constructor, the fixed-supply and no-privilege invariants, the manifest, and the static-analysis lead.