Implemented IMDwindowshopper (WWW): 1 billion tokens, 18 decimals, minted once to the deployer.

Includes vendored dependencies, success/failure tests, fuzz and invariant tests, and deployment documentation in README.md.

Passed Solidity 0.8.26 checks:

• forge build
• forge test — 34 passed using the required seed
• forge fmt --check

Created launch.json with the exact token supply, empty constructor arguments, no application contracts, and required pool and economics values.

forge build succeeded; all 34 tests passed with the supplied fuzz seed. Manifest fields and compiled constructor ABI were checked. Only launch.json is changed for submission.

The permissions review of IMDwindowshopper found no defects. The findings file is written with an empty findings list and nine coverage rows, and the working tree has no other changes.

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

• Permission model. The token is a 16-line contract inheriting OpenZeppelin ERC20 with a constructor-only mint. The compiled ABI exposes exactly the three listed state-changing functions and no receive, fallback, owner, initializer, pause, blacklist, mint or burn. Every storage slot has a single writer path with a consistent guard: balances move only through _update, allowances only through _approve, and total supply only in the constructor.
• Deployer privilege. A scratch Foundry probe confirmed the deployer cannot spend a holder's tokens without an allowance, a stranger with zero allowance can move at most zero tokens, and allowance replace and sticky-max semantics behave as documented.
• Asymmetry. The transfer and transferFrom paths share identical validation. The mint and burn branches of _update are unreachable after construction because _transfer rejects both zero addresses.
• Trust gap. There is no privileged actor, fee, price, recipient or settable parameter, so no access-times-economics intersection exists. The sole trust assumption is that the constructor caller, the launch factory, receives the whole supply, which is the requested design.
• Supply chain and launch floor. The five vendored OpenZeppelin files hash identically to the upstream v5.4.0 tag. An opcode walk of the runtime bytecode finds no reachable DELEGATECALL, CALLCODE or SELFDESTRUCT. Supply is exactly 10^27 base units with 18 decimals, and the contract identifier is 16 characters.

Leads I dropped. The aderyn large-numeric-literal note is style only, and the literal evaluates to the exact manifest supply. Zero-value transferFrom with no allowance succeeds and emits a Transfer event from any address, which is standard ERC-20 and OpenZeppelin behaviour and moves no balance, so I did not report it.

Coverage. All three entry points are recorded as holds, plus six invariant rows. Nothing in my area was left unreached. The project's own 34 tests pass, including the two stateful invariant suites. The protected Uniswap v4 seed and swap harness cannot run here because v4-core is not vendored, so the real pool flow remains the network's verification stage to confirm.

The economics review is complete and the findings file is written. The token has no economic defects.

Outcome. The IMDwindowshopper token is a bare OpenZeppelin v5.4.0 ERC20 with a single constructor mint of 10^27 base units to msg.sender. Nothing in the Economic Security, Invariant or Flow Gap guides reaches it: there are no external calls, oracles, fees, burns, hooks, callbacks, admin roles or post-deployment mint paths. All three listed entry points hold.

What I verified

• Read the vendored ERC20 in full. Its transfer, approve, transferFrom, _update, _approve and _spendAllowance bodies are the unmodified upstream code, and every OpenZeppelin file matches the project's checksum file.
• Ran the project's own suite with the README's fuzz seed: 34 tests pass, including the two stateful invariants.
• Wrote scratch tests against the compiled bytecode that replicate the protected harness: CREATE2 deployment from a factory, exact 10% / 70% / 20% flows, whole claims, transfers in both swap directions, a deployer attempting transferFrom on a holder without allowance, 14 admin and mint selectors, and the reachable-opcode scan for DELEGATECALL, CALLCODE and SELFDESTRUCT. All pass. The scratch directory was removed afterward.
• Both static-analysis leads were checked. Slither reported nothing. Aderyn's large-numeric-literal line is the supply constant, which is the correct value and is asserted by the tests.

One info-level note recorded. The library README says the vendored sources verify against lib/SHA256SUMS, but running that command on the committed tree reports seven forge-std files that do not match. Those files are test-only and the production ERC20 files all verify, so there is no token impact. It is reported because the provenance claim as written is false and reproducible.

Coverage. Nine rows in .imd-findings.json: all three ABI entry points plus the fixed-supply and balance-sum invariants, the constructor mint, the opcode scan, and one row each for the Economic Security and Flow Gap guide passes, all holds. Nothing was left unreached. I could not fetch upstream OpenZeppelin from GitHub to compare hashes independently because the sandbox denied that host, so library authenticity rests on reading the code and the project's own checksum file.

Review complete. The findings file is written at .imd-findings.json with one low finding and seven coverage rows, and the working tree is otherwise unchanged.

Outcome. The token itself is clean within my area. IMDwindowshopper is a 16-line contract that inherits the unmodified OpenZeppelin v5.4.0 ERC20 and mints exactly 10^27 base units to the constructor's caller once. No defect was found in any of the three state-changing entry points.

What I covered, by guide.

• Execution Trace. Traced approve, transfer and transferFrom from entry to final state through the inherited _approve, _transfer, _update and _spendAllowance. Sentinel inputs (zero sender, zero receiver, zero spender, max allowance, max minus one), partial-update atomicity across the allowance and balance legs, self-transfers, and value sent to nonpayable functions all behave as specified. The launch flows (10 percent to a distributor, a whole claim, 70 percent to a pool manager, buys and sells both ways) move exactly the requested amounts.
• Periphery. All five vendored OpenZeppelin files are byte-identical to upstream v5.4.0, verified by download and hash. The compiled ABI exposes only the three nonpayable functions plus views, with no receive or fallback. I re-ran the protected harness's reachable-opcode scan on the compiled runtime in a scratch test, and it passes. The one defect is here: seven forge-std files differ from the hashes recorded in lib/SHA256SUMS, so the README's own integrity command fails. I confirmed against upstream v1.9.7 that the differences are whitespace only and test-only, so this is rated low.
• First Principles. Deployment via raw CREATE2 from a contract address assigns the supply to that contract, never to the origin. No role, owner or initializer exists, so there is nothing for a first outside caller to seize. The project's own 34 tests plus my 8 scratch tests all pass.

Not reached. Nothing within the assigned area was left untraced. I did not assess the README's stated launch chain or paired-currency address, since no network table was supplied and those are outside my guides.

The math audit of IMDwindowshopper found no defects in the token. The only finding is an info-level provenance problem in lib/, which doesn't affect the deployed token. Findings and coverage are in .imd-findings.json, all three entry points answer holds, and no tracked file changed.

Finding: lib/README.md:8 (info, outside the math area)

• What fails: the README says the vendored sources are unmodified, but its own check, sha256sum --check lib/SHA256SUMS, fails on 7 forge-std files.
• Impact: the differences are whitespace only, and forge-std is used only by tests.
• Deployed code: all 5 OpenZeppelin files that compile into the token match the v5.4.0 tag byte for byte.

Why the guides found nothing else: the token adds only a constant and one constructor mint to unmodified OpenZeppelin ERC20.

• Math Precision: there are no divisions, casts, scale conversions or shares. The only arithmetic is the constant, which is exactly 10^27 in the bytecode, plus balance and allowance updates. The unchecked additions can't overflow because balances sum to 10^27.
• Boundary:
  • External surface: the token has no external calls, payable functions or bytes inputs.
  • Rejected input: amounts of balance+1 and uint256 max revert without wrapping, including on self-transfers. A zero from or to, dirty address bits, short calldata and attached ETH also revert.
  • Allowances: max-1 decrements and max stays unlimited. A failed spend leaves the allowance unchanged.
• Numerical Gap: zero-value paths break no invariant, and the launch split of 1e26, 7e26 and 2e26 sums to the supply exactly.

Checks run:

• The project's own suite passes 34 of 34.
• My differential fuzz (512 runs of 120 operations, using edge amounts) matched a plain model after every operation. Its actors included the caller, the token and the zero address.
• WWW also seeded and swapped both ways on a real v4 PoolManager at this launch's numbers, in both currency orders. The tick was about ±131230, liquidity about 9.93e23, and supply stayed fixed.
• A bytecode walk found no reachable DELEGATECALL, CALLCODE, SELFDESTRUCT, CALL or CREATE.

Static analysis leads: Slither reported nothing. Aderyn's large-numeric-literal line is style only, because the value is correct, so I left it out.

Known behaviour, not reported: the approve race and zero-value transferFrom without allowance are standard ERC-20 behaviour the README documents. A 1-wei buy returning 0 tokens comes from v4's fee rounding, not from this token.

Not covered:

• Protected test harness: I couldn't run it because src/LaunchLiquidity.sol and the related contracts aren't supplied. The v4 run used my own seed and swap code against upstream v4-core main, without the launch's hook, and its price and ticks are my own calculation rather than the deployer's.
• Not in this tree: the per-wallet distributor split and the deployer's price derivation.
• Manifest: there is no launch.json yet, so none was checked.

Scratch tests, build output and temp downloads are removed.

The test suite for IMDwindowshopper (WWW) is finished: forge build succeeds and forge test passes all 94 tests on the verifier seed. I found no defects in the token. Nothing is committed: the three new test files are untracked in the working tree, and the accepted tests and src/ are unchanged.

New test files

File	Tests	What it adds
test/IMDwindowshopper.edges.t.sol	45 unit tests	zero-address caller and from, the order errors are checked in, truncated or malformed calldata, the max - 1 allowance, absence of events and storage writes, the compiled bytecode's external surface and banned opcodes
test/IMDwindowshopper.properties.t.sol	13 fuzz tests, 1,000 runs each	inverses, splitting a transfer or spend, repeated approvals, aliased parties, any selector outside the ABI, the launch flows in one transaction across 0–90% pool share
test/IMDwindowshopper.ledger.invariant.t.sol	9 invariants, 1 reachability test	14 handler actions over 256 runs of 128 calls; balances are tracked by two independent ledgers, one from the operations and one from emitted logs, and recipients can be any address, including the token itself

How it was checked

• Mutation testing: I ran 27 deliberately broken versions of the token in throwaway copies (fees, hidden mint or rescue, callbacks, time locks and similar), and all 27 were caught. Eleven of them were caught only by the new files. A no-op control passed, as it should.
• Deep campaign: on a different seed, 20,000 fuzz runs per test and about 230,000 invariant calls all passed. That run also confirmed the inline run counts take effect.
• Vendored OpenZeppelin: the five files the token compiles against match the v5.4.0 tag byte for byte, and the token source is plain ASCII.

Reported in .imd-findings.json (one info item): sha256sum --check lib/SHA256SUMS fails on seven forge-std files, which contradicts lib/README.md, line 8, "Sources are unmodified". The differences are formatting only, forge-std is test-only, and it never reaches the deployed token. lib/ is outside the paths I may change, so I reported it rather than fixed it.

Limits of these tests

• Pool flows: these are simulated with plain transfers, so a real Uniswap v4 seed and swap is still left to the protected harness, which needs files this repo doesn't have.
• Hidden triggers: the bytecode checks would not catch a backdoor set off by one specific amount with no new selector. The token rules that out by its source (16 lines plus unmodified OpenZeppelin), not by these tests.
• README: its test counts ("Five fuzz tests", "Two stateful invariants") are now out of date, and it's outside the paths I may change.

The review is complete and the findings file is written. The working tree is otherwise clean, so nothing else needs to be requested.

Outcome. The IMDwindowshopper token is a plain OpenZeppelin v5.4.0 ERC-20 with a one-time constructor mint and no admin surface. I found no defect in the Solidity code. One low-severity documentation finding is kept, merged from the four specialists' identical reports.

What I verified against the code and tree:

• All five vendored OpenZeppelin files are byte-identical to the upstream v5.4.0 tag. The three entry points approve, transfer and transferFrom are the unmodified library bodies, traced through _approve, _update and _spendAllowance.
• The constructor mints exactly 10^27 units to msg.sender once. The ABI exposes no mint, burn, owner, pause or blacklist function.
• Runtime bytecode is 1753 bytes with no DELEGATECALL, CALLCODE, SELFDESTRUCT, CALL, STATICCALL or CREATE opcodes. CREATE2 deployment from a factory assigns the supply to the factory.
• The manifest launch.json uses only schema keys, an empty constructorArgs list matching the zero-parameter constructor, and the correct supply and decimals.
• The project builds and all 94 tests pass with the README's fuzz seed. The aderyn large-literal lead is a compile-time constant and was dropped.

Kept finding (low). The lib/README.md says vendored sources are unmodified and verifiable with the checksum file, but that command fails on seven forge-std files. I reproduced the cause: the recorded hashes equal upstream v1.9.7, and the committed files differ from upstream only by whitespace. The token's compiled code is unaffected, since forge-std is test-only. The fix is to restore the upstream bytes or regenerate the sums and reword the claim.

Output. The findings file holds one finding and seven coverage rows, with all three verifier-listed entry points marked as holding. No critical or high finding exists, so no proof test was needed, and the scratch directory was left empty.