Implemented WindowShopper (WWW) with 18 decimals and 1,000,000,000 tokens minted once to the deployer. No later minting or administrative powers.

Validation passed: forge build, seeded forge test, forge fmt --check, and a fresh offline build. Tests include 35 unit/fuzz tests and three stateful invariants.

Dependencies are vendored. Deployment parameters, assumptions, and operational responsibilities are documented in README.md.

I found no math defects in WindowShopper (WWW), so .imd-findings.json has an empty findings list plus a coverage row for each of the three entry points and one for the supply invariant. I changed no project files.

What the code is: src/WindowShopper.sol is a plain OpenZeppelin v5 ERC20. Its only addition is a constant, INITIAL_SUPPLY = 1_000_000_000 * 10 ** 18, which the constructor mints once to msg.sender. There is no fee, burn, tax, rounding, narrowing cast or custom arithmetic.

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

• Supply constant: it is computed exactly at compile time as 10^27 (1e27), far below 2^256. decimals() returns 18, so the supply is exactly 1 billion WWW.
• transfer and transferFrom: a transfer reverts if the amount is more than the sender's balance, before any subtraction happens. The unchecked addition to the recipient can't overflow because no balance can exceed the total supply. Sending zero, sending your whole balance and sending to yourself each move exactly the amount asked.
• Allowances: transferFrom reverts if the allowance is too small, before reducing it. An allowance of type(uint256).max is never reduced, which is the standard "unlimited" behaviour, not a bug.
• approve: it reverts for the zero address as owner or spender, stores the value exactly, and does no arithmetic.
• Supply can't change: nothing after the constructor can mint or burn, so the total supply stays at 1e27.
• Launch flows: the factory's transfers, the distributor's claims and pool swaps all move exact amounts, since nothing is taken on transfer.

Static analysis lead: aderyn flagged a large numeric literal at src/WindowShopper.sol:10. It's a style note: the number is written with digit separators and is exactly right, so I didn't report it.

Tests: forge test passes all 36 tests, including the invariant suite (8,192 calls, no reverts). I didn't write any new tests.

Not covered: I didn't go through the other nine specialty guides in depth because they belong to the other reviewers. In passing I saw no owner, pause, blacklist or mint function.

Created launch.json matching WindowShopper’s constructor, supply, and required pool/economics values. Only the manifest changed.

Validation passed: manifest fields and compiled ABI match; forge build succeeded; all 36 tests passed with the supplied fuzz seed.

Review complete. The findings file is written at the repository root and the working tree is otherwise untouched.

Outcome. The WindowShopper token has no control-flow defect. It is the OpenZeppelin v5.1.0 ERC20 with a single constructor mint of 10^27 base units to msg.sender, no constructor arguments, no owner, no hooks, no external calls and no receive or fallback. I found one low-severity provenance defect in the vendored test library.

What I checked in my area.

• Execution Trace: traced approve, transfer and transferFrom through the OZ base to final state, including the zero-address, insufficient-balance, insufficient-allowance, max-allowance, self-transfer and zero-value paths. Every failure path reverts with full rollback and every success path moves exactly the requested amount.
• Periphery: all five vendored OpenZeppelin files are byte-identical to the upstream v5.1.0 tag. Context returns plain msg.sender, so there is no forwarder path.
• First Principles: the only assumption is that the deploying caller is the factory, which launchCustom guarantees. The supply cannot grow afterwards because _mint is internal and unreachable. The compiled ABI exposes nothing beyond ERC-20 plus a view constant, and a reachability scan of the runtime and creation bytecode found no DELEGATECALL, CALLCODE or SELFDESTRUCT.
• The project suite passes with the README's seed. The aderyn large-literal lead is a compile-time constant and not a defect.

The one finding (low). Six forge-std files were reformatted after their checksums were recorded, so the check DEPENDENCIES.md prescribes fails and its "unmodified" statement is false. The reproduction is this command from the repository root:

sha256sum -c DEPENDENCIES.sha256

It reports six FAILED lines and exits 1. The recorded hashes are the upstream v1.9.6 hashes, and the diff against upstream is line wrapping only, so test behaviour and the token bytecode are unaffected. The suggested fix is to restore the upstream bytes and keep lib/ out of the formatter, or regenerate the checksum file and amend the claim.

Coverage. All three listed entry points are marked holds, with additional rows for the constructor, the ABI surface, the bytecode and decimals invariants, the two vendored libraries, the static-analysis lead and the protected floor's expectations. The protected floor test itself needs the verifier's Uniswap v4 harness, which is not vendored here, so it was read and reasoned against rather than run.

The review is complete and .imd-findings.json is written with one informational finding and nine coverage rows. The working tree is clean apart from that findings file.

Outcome for the economics area: no defects. The token is a 15-line wrapper over an unmodified OpenZeppelin v5.1.0 ERC-20 that mints the full supply once to the deployer. I checked it against every failure mode in the Economic Security, Invariant and Flow Gap guides and all three entry points hold.

• Economic Security. The token makes no external calls, so no dependency can block a claim or seed. There is no fee, burn, blacklist, pause, hook or owner, so no flow arrives short and no privileged hand can move or freeze a balance. Transfers and approvals to the zero address revert. Tokens sent to the contract's own address are stranded, but only by the sender's own action, which the README documents.
• Invariant. Only the constructor writes total supply. Probing mint and issue selectors from an outsider and from the factory fails. The project's stateful suite and my own flow model both conserve the sum of balances at exactly one billion tokens.
• Flow Gap. I modeled the launch as the protected test performs it: factory mint, ten percent to the distributor, claim out of the distributor, seed to the pool manager, remainder forwarded, then a buy and a sell through allowance. Every amount arrived exactly.

One informational finding, outside my area. The README and DEPENDENCIES.md tell the reader to verify vendored files with sha256sum -c DEPENDENCIES.sha256, and that command fails on six forge-std files. The differences are whitespace-only reformatting of test-only code, and all five OpenZeppelin production files are byte-identical to the upstream tag. The fix is to regenerate the checksum file or restore the six files.

Verification run. The full project suite passed with the README's fuzz seed, and my four scratch tests passed before I removed them. Static analysis leads were checked: the aderyn large-literal note is the correct supply constant, not a defect. Not run: the protected harness, which needs the verifier's environment, and Slither or Mythril.

The review is complete and the findings file is written. Nothing in the tree was changed apart from the ignored build cache and the findings file itself.

Result: the permission model holds. WindowShopper is an unmodified OpenZeppelin v5.1.0 ERC-20 with a parameterless constructor that mints the full supply to the deploying caller once. There are no roles, no initializer, no hooks, no fallback, and no code path that writes total supply after deployment. I traced all three state-changing entry points through the vendored library and found no access gap, trust seam, or paired-function asymmetry.

What I verified, in my area and around it:

• Access Control: approve writes only the caller's own allowance, transfer moves only the caller's balance, and transferFrom checks the from-to-caller allowance before moving anything. The factory, deployer EOA and strangers cannot pull a holder's tokens without approval. Twenty-two admin selectors from the protected floor all revert from both deployer and stranger.
• Trust Gap: no privileged actor exists, so no admin action can create asymmetry between holders. The factory simply holds the supply it minted, which is the launch design.
• Asymmetry: approve and transferFrom mirror correctly, max allowance is not decremented, failed transferFrom paths revert atomically so allowance is never consumed on failure. Zero-value transferFrom by a stranger succeeds and emits a zero Transfer event, which is standard ERC-20 behaviour and documented in the README.
• Launch floor: supply constant equals exactly ten to the twenty-seventh, decimals are eighteen, CREATE2 deployment from a factory leaves the whole supply with the factory, and the runtime has no DELEGATECALL, CALLCODE or SELFDESTRUCT. I replicated the protected floor's opcode scan in a scratch test and it passed.

One low finding, outside my area but reproducible. The documented integrity check fails. Running sha256sum -c DEPENDENCIES.sha256 reports six forge-std files as mismatched. The recorded digests are upstream v1.9.6's, but the local copies were reformatted by forge fmt after the digests were taken. The five OpenZeppelin production files match upstream byte for byte, so the compiled token is unaffected. The fix is to restore the six test-only files or regenerate the checksum file and drop the "unmodified" claim.

Not reached: the protected harness's live seed and swap path needs v4-core and the verifier's environment, so I could not execute it locally. Since the token has no fee, burn or hook, every transfer delivers the exact amount, which is what that path depends on.

I found no defects in WindowShopper (WWW), so there is no .imd-findings.json. With the verifier's fuzz seed, forge build succeeds and forge test passes 53 tests: the 36 already in the repository plus 17 new ones.

The token itself is just OpenZeppelin's ERC-20 (version 5.1.0, vendored in lib/) with the name, symbol and a one-time mint of 10^27 base units (1 billion tokens) to the deployer. There is no owner, fee, pause, mint or burn function that anyone can call. The tests I added found nothing to report.

I left the earlier tests unchanged and added one file, test/WindowShopper.adversarial.t.sol. It isn't committed.

Launch checks, mirroring the protected launch tests:

• Fuzzed launch in one call: a helper deploys the token at a fixed address and splits the supply in the same call: 10% to the distributor, 0–90% to the pool, the rest to the requester. Every share arrives exactly, nothing is left with the factory, and claims out of the distributor arrive exactly down to the last wei.
• Same address, no re-mint: the token lands at the predicted address, and a second deploy with the same salt reverts.
• Bytecode scan: the deployed code contains no reachable DELEGATECALL, CALLCODE or SELFDESTRUCT, and is under the 24,576-byte size limit.
• Admin calls: 22 common admin-style calls (mint, pause, blocklist, freeze, burnFrom, setFee, increaseAllowance, …) fail whether the deployer or a holder sends them. The deployer has no hidden allowance over holders, and holders can still transfer afterwards.

Failure paths and edge cases:

• A fuzz test confirms any function the token doesn't declare reverts and changes nothing, whoever calls it. A call with no data also reverts.
• transferFrom with the zero address as the owner reverts even for 0 tokens.
• Spending an allowance emits only a Transfer event, with no Approval.
• An unlimited allowance still can't move more than the owner holds.
• Also covered: approving yourself as spender, a 1-wei transfer and an overdraft by 1 wei, and tokens sent to the token's own address.
• Fuzz tests cover transfers between any two addresses, overdrafts returning the exact error, and unlimited allowances never going down.

Invariant tests (256 runs of 64 random calls each):

• A handler makes 10 kinds of call. Valid transfers, approvals and transferFrom go to a growing set of fuzzed addresses. Invalid ones are mixed in: overdrafts, overspent allowances, transfers to the zero address, approving the zero address, and mint/burn attempts. Every invalid call must revert with the exact expected error and change nothing.
• After every call the tests check four things: total supply never changes, the tracked holders together hold all of it, every balance and allowance matches the handler's own record, and no balance exceeds the supply.
• All 10 kinds of call ran about 1,600 times each.

The run counts are set inside the test file, since foundry.toml isn't mine to change.

I found one problem, and it is low severity: the documented check on the bundled libraries fails. The token code itself has no defects, and the results are in .imd-findings.json.

The kept finding: DEPENDENCIES.md:15. All three specialists who reported something (flow, economics and permissions) reported this same problem, so I merged their reports into one. It fails like this:

• Running sha256sum -c DEPENDENCIES.sha256 gives 26 OK and 6 FAILED, and exits with status 1.
• The six failing files are all from forge-std: StdAssertions.sol, StdJson.sol, StdToml.sol, Vm.sol, console.sol and interfaces/IMulticall3.sol.
• I downloaded the upstream forge-std v1.9.6 copies. The hashes recorded in the checksum file are upstream's hashes. The local copies differ from upstream only in whitespace, which looks like a forge fmt run over lib/.
• So the statements that the libraries are "unmodified" (DEPENDENCIES.md:15 and README.md:108) are false.

Nothing that gets deployed is affected: forge-std is only used by tests, and the OpenZeppelin ERC20.sol is byte-identical to the v5.1.0 release. I rated it low, not high or critical, so it carries no failing test.

The three entry points all hold:

• approve, transfer and transferFrom are the standard OpenZeppelin v5.1.0 ERC20 functions, with nothing overridden.
• Transfers move exactly the amount asked, with no fee or burn, so the factory, distributor and pool transfers arrive in full.
• There is no owner, mint function, pause, blacklist, DELEGATECALL or SELFDESTRUCT.
• The constructor mints 1,000,000,000 × 10¹⁸ once to the deployer, which matches totalSupply and decimals: 18 in launch.json.
• The constructor takes no arguments, matching constructorArgs: [], and the deployed code is 1,752 bytes, well under the 24,576-byte limit.

Other checks:

• forge build succeeds and forge test passes all 53 tests.
• I dropped the Aderyn "large numeric literal" warning: 1_000_000_000 * 10 ** 18 is written clearly and is correct.
• I could not check that the economics in launch.json match the job's, because the job's figures weren't given to me.

I changed no repository files; the only file I wrote is .imd-findings.json, which git ignores.