Done. The IMDwindowshopper (WWW) token is implemented, tested, documented, and committed as c406f06.

What was built

• src/WindowShopperToken.sol: a fixed-supply ERC-20 built on vendored OpenZeppelin v5.4.0 (ERC20, ERC20Burnable, ERC20Permit). The constructor takes no arguments and mints 1,000,000,000 WWW with 18 decimals once to msg.sender, which is the launch factory. There is no owner, minter, pause, blocklist, fee, or upgrade path, so the supply can only shrink and every launch flow moves exactly what it says.
• script/DeployWindowShopperToken.s.sol: a local deploy helper whose deploy() function reads nothing from the environment and is what the tests call.
• test/: 40 tests, all passing with the verifier's fuzz seed and a minimal environment. They cover metadata and the one-time mint, transfer, approve, transferFrom, burn, burnFrom and permit with both success and failure cases, plus the launch floor properties from the protected test (exact 10% swarm flow, no call grows supply, no privileged call moves or freezes a holder, no receive or fallback, runtime under EIP-170, and no reachable DELEGATECALL, CALLCODE or SELFDESTRUCT in the bytecode). Four fuzz tests check conservation of supply and balance and allowance bounds.
• README.md: assumptions, manifest values for the launch, operational responsibilities, and the note that this is not an audit.
• foundry.toml: pins solc 0.8.26, bytecode_hash = "none", optimizer on, ffi off, no filesystem permissions, and the verifier's fuzz seed. forge-std v1.11.0 and the ERC20, utils and interfaces parts of OpenZeppelin are vendored under lib/ as plain files with no git submodules.

Checks run

Notes for the requester

• Slither was not available on this machine, so it did not run. The source uses no selfdestruct, delegatecall, encodePacked, or external library calls.
• The sandbox's placeholder dotfiles and the .claude/ directory were left out of the commit since they are not part of the deliverable.
• No launch.json was written. The manifest step owns it.

I've written launch.json for WindowShopperToken, the only contract in the accepted tree. It parses as valid JSON, and forge build and forge test pass with the verifier's fuzz seed (40 tests, 0 failures). No other file changed.

What the manifest says:

• Token: contract is WindowShopperToken, name is "IMDwindowshopper", symbol is "WWW", decimals is 18.
• Constructor arguments: none ([]), because the constructor takes no parameters.
• Total supply: "1000000000000000000000000000". That is 1,000,000,000 tokens with 18 decimals, exactly what the constructor mints once to msg.sender.
• Application contracts: none ([]), because the accepted tree has none.
• Pool: paired with IMD at 0xd34a99bc0f67ae1bbd63c660e6d0b0dd03e263b7, fee 12500, tick spacing 60, initial price "79228162514264337593543950336" (one to one).
• Economics: copied exactly as the job gave it.
• Notes: describe only what the source actually does. It is a fixed-supply ERC-20 that holders can burn from and that supports signature approvals (OpenZeppelin ERC20, ERC20Burnable and ERC20Permit). There is no owner, minting after launch, pause, blocklist or fee. The notes also include the X link.

The schema validator isn't available on this machine, so I checked the keys and types by hand against the example in the brief rather than running a validator.

The review found no defects. The findings file holds an empty list and nine coverage rows, and the working tree is otherwise untouched.

What I checked, in the assigned area

• Math Precision: the only arithmetic in src/WindowShopperToken.sol is the supply constant. The exponent is a uint8 but Solidity evaluates a literal base to a non-literal power in uint256, so it yields exactly one billion times ten to the eighteenth with no wrap. Decimals, the constant and totalSupply() all agree with the manifest values. The inherited ERC-20 arithmetic checks balance and allowance before its unchecked subtractions, and the sum of balances equals total supply under fuzzing.
• Boundary: every entry point was driven with zero, whole-supply, max-uint and off-by-one inputs. Transfers to the zero address revert, max-uint transfers revert with the exact error, infinite allowance is never decremented while max-minus-one is, burning the whole balance drives supply to zero cleanly, and zero-amount transferFrom or burnFrom with no allowance moves nothing. The token has no payable function, external call, sentinel branch or bytes decoding, so those checklist items do not apply.
• Numerical Gap: the permit deadline is inclusive at the exact timestamp and rejects one second later, the nonce is consumed only on success, malleable high-s signatures and a zero owner revert, and the EIP-712 domain separator matches the declared name and version and rebinds on chain-id change.

Supply-chain check: every Solidity file under the vendored OpenZeppelin directory is byte-identical to the upstream v5.4.0 release archive, so the inherited code is the audited library's, not a modified copy.

Outside my area: no owner, mint, pause, blocklist, receive, fallback, DELEGATECALL or SELFDESTRUCT exists, and the project's own 40 tests pass with the pinned fuzz seed. The aderyn large-literal note is cosmetic. The one trust assumption worth recording for the judge is that whoever deploys receives the whole supply, which is the launch factory by design.

The review is complete. .imd-findings.json holds an empty findings list and a ten-row coverage record. The working tree is clean apart from the findings file and my scratch test, which is git-ignored.

Result: no reproducible defect in the economics area. The token is OpenZeppelin ERC20 + ERC20Burnable + ERC20Permit with a constructor that mints one billion WWW to the deployer. It has no custom transfer logic, no owner, and no mint path after construction.

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

• Supply conservation and monotonicity. A stateful invariant run of 256 sequences times 500 random transfer, transferFrom, approve, burn and burnFrom calls kept sum of balances equal to totalSupply and totalSupply equal to the initial supply minus burns. Zero reverts.
• Launch flows. The 10/60/30 split of the supply is exact with no dust, and every flow the factory, distributor, pool manager and traders perform moves exactly the asked amount. There is no fee, hook or exemption list to get wrong.
• Allowance coupling. burnFrom and transferFrom are bounded by the allowance identically, and the factory cannot move or burn a holder's balance without approval.
• Permit. Deadline, nonce, EIP-712 domain and low-s signature checks all hold. The domain separator rebuilds on a chain-id change, so no cross-chain replay. A third party submitting someone's permit first sets exactly the signed allowance, which is a known ERC-2612 property and not a value-misrouting defect.
• Dependency integrity. Every vendored file under OpenZeppelin and forge-std is byte-identical to upstream tags v5.4.0 and v1.11.0. The compiled ABI exposes only the expected selectors.
• Static-analysis lead. The aderyn large-literal note on line 28 evaluates to exactly 1e27 and is not a defect.

All six listed entry points are marked holds. One row is unreached: no launch.json exists in the tree yet, so the manifest could not be compared against the code. The README's intended manifest values are consistent with the source.

Tools run: forge build, the project's 40 tests, forge fmt check, and my scratch test file under test/scratch with seven passing checks.

The review is complete and .imd-findings.json is written. No tracked file was changed; test/scratch/ is gitignored and holds only my verification test.

Result: no defect found in the token. The contract is a constructor plus three unmodified OpenZeppelin mixins, and every entry point traced as intended.

What I checked, per the Execution Trace, Periphery and First Principles guides:

• Periphery. All 119 vendored OpenZeppelin files are byte-identical to the npm 5.4.0 release, so no tampered ERC20.sol hides behind the clean src/. GitHub was blocked by the proxy, so forge-std could not be diffed, but it affects only tests, not the deployed bytecode.
• Execution trace. Each of the six state-changing entry points was traced through checks, state writes and revert paths. Scratch tests confirmed the edge paths the project suite skips: permit with a zero owner, high-s signatures, burnFrom with an infinite allowance, atomic revert of transferFrom to the zero address, and domain separator rebuilding on a chain fork.
• First principles. The constructor mints the whole supply once to the deployer with no arguments, the ABI exposes no mint, owner, pause or upgrade path, the storage layout has no extra slots, and the launch flows move exact amounts. The README deployment parameters match the compiled constants.

One info-level item is recorded: permit can be submitted by any third party first, so a signer's bundled permit-then-act transaction reverts. This is inherent to EIP-2612 and needs no code change, only awareness from integrators.

Coverage record: six entry points answered, all holds except permit, which points at the info item. Five extra rows cover the constructor, library integrity, the opcode floor and manifest consistency, with forge-std marked unreached.

The review is complete. The findings file is written and the working tree is unchanged apart from it.

Result: no defects in the permission model. .imd-findings.json holds an empty findings list and ten coverage rows, one per listed entry point plus four invariants, all holds.

What I checked, from the Access Control, Trust Gap and Asymmetry guides:

• Permission map. The token has no owner, role, minter, pauser, initializer, proxy, receive or fallback. The ABI's only state-changing entries are the six listed functions and a no-argument constructor. Storage holds only balances, allowances, supply, name, symbol, EIP-712 fallbacks and nonces.
• Deployer power. The factory receives the whole supply but has no power over a holder beyond any stranger's. Its calls to transferFrom and burnFrom against a holder revert on allowance, as the protected floor test requires.
• Permit. Deadline, nonce, chain-bound domain, low-s and zero-recover checks all hold. I probed zero owner, wrong chain, malleated s and replay. Each reverts and sets no allowance.
• Asymmetry. approve and permit end in the same _approve. transferFrom and burnFrom both spend allowance before _update. There is no admin variant of any user function, and no fee or exemption branch exists on the transfer path.
• Library integrity. All twenty compiled OpenZeppelin dependencies are byte-identical to the upstream v5.4.0 tag, so no backdoor hides in the vendored code.

Trust note, not a finding. Anyone may submit a holder's valid permit signature before the holder's own bundled transaction, which then reverts on the nonce. This is standard ERC-2612 behaviour and grants exactly what was signed, so I recorded it in the permit coverage row rather than as a defect.

Static-analysis lead. The aderyn large-literal note at line 28 is not a defect. The constant evaluates to exactly 1e27 and the existing supply test confirms it.

Tools run. forge build, the project's 40 tests, and nine scratch probe tests of my own, all passing. The scratch file is deleted. Slither and Mythril were not run.

Added failure-path, boundary, permit-security, and four-actor invariant tests under test/.

Verification passed offline with the required seed: 76 tests passed, 0 failed, including 32,768 randomized handler calls. forge build and formatting checks passed.

No contract defects were identified. All changes are confined to test/.

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

Outcome: the token is clean. It is three unmodified OpenZeppelin 5.4.0 mixins plus an argument-less constructor that mints the whole supply to the deployer. I kept one informational observation and found no defects of my own.

What I verified

• Vendored library is genuine. Every one of the 119 Solidity files under lib/openzeppelin-contracts is byte-identical to the npm 5.4.0 tarball. Only five README.adoc files are extra, and they are not compiled.
• Build and tests. All 76 project tests pass with the pinned fuzz seed, and the formatter check passes.
• ABI and bytecode. No mint, owner, pause, blocklist, receive or fallback is exposed. No link references, no DELEGATECALL, CALLCODE or SELFDESTRUCT. Runtime is 4,321 bytes and creation code 6,084 bytes, well under the factory's limits.
• Manifest. Only schema keys, constructor arguments empty to match the constructor, total supply equals what the constructor mints, decimals match, addresses lowercase, notes short.
• Static analysis lead. The aderyn large-literal note is the supply constant, which evaluates to exactly 1e27 as the manifest requires. Not a defect.

Specialist findings

• The only one, from audit_flow, is that a third party can submit a permit signature first, making the signer's own permit-then-act bundle revert. I reproduced it with a scratch Foundry test. It is inherent to EIP-2612 and creates no allowance beyond what was signed, so it stays at info with an explicit "no code change required" note.
• The other four areas reported nothing, and nothing needed merging.

Coverage. All six entry points are answered: five hold, and permit carries the info finding. Three extra rows record the fixed-supply invariant, the dependency authenticity check and the manifest check.