Implemented www (WWW): 1,000,000,000 tokens with 18 decimals, minted once to the deployer.

Includes vendored dependencies, success/failure tests, fuzz tests, stateful invariants, and deployment documentation.

Verified with Solidity 0.8.26:

• forge build — passed, including offline build
• forge test — 30 passed with the required seed
• forge fmt --check — passed

I wrote launch.json for the www (WWW) launch. forge build passes, and forge test with the given fuzz seed passes all 30 tests. I couldn't run the two protected checks you supplied: they need v4-core and some launch source files that aren't in this tree, so the verifier will have to run them.

What the manifest contains:

• Token: contract WWWToken, name "www", symbol "WWW", 18 decimals.
• Constructor arguments: an empty list, because the accepted src/WWWToken.sol constructor takes no arguments.
• Supply: "1000000000000000000000000000" (1,000,000,000 × 10^18), which is exactly what the constructor mints to the deployer.
• Application contracts: none, because the accepted code has only the token.
• Pool: pair token 0xd34a99bc0f67ae1bbd63c660e6d0b0dd03e263b7, fee 12500, tick spacing 60, starting price "79228162514264337593543950336" (one to one; recorded for reference only).
• Economics: copied verbatim from the brief.
• Notes: 650 characters, describing only the token: a plain ERC-20 with a fixed supply, no owner, no fees or burns, and no minting after deployment.

I also deployed the token in a throwaway test and confirmed that its supply, the deployer's balance, decimals, name and symbol all match the manifest. That test lives in test/scratch/, which gets deleted before submission. launch.json is the only change in the working tree, and I haven't committed it.

The review is complete. No defects found. The findings file is written with an empty list and ten coverage rows.

What was audited. The token in src/WWWToken.sol is a bare OpenZeppelin v5.0.2 ERC20 with a constructor that mints the full supply to the deployer. I checked it against the Access Control, Trust Gap and Asymmetry guides, plus the senior-auditor mindset and validation gates.

Access control. The compiled ABI exposes only approve, transfer and transferFrom as state-changing functions. There is no owner, minter, pauser, blacklist, initializer, receive or fallback. Storage holds only the five standard ERC20 slots. The mint and burn helpers are internal and unreachable after construction, so supply cannot grow.

Trust gap. No admin setter, fee recipient, oracle or pricing formula exists, so there is no seam where a permitted actor extracts value or where value flows differently by caller class. All launch economics live in the factory.

Asymmetry. Both transfer paths converge on the same internal update with identical zero-address, balance and event behavior. The only difference is allowance consumption, which is the intended guard.

Independent verification done.

• All five vendored OpenZeppelin files hash-match upstream v5.0.2 byte for byte.
• The existing 30 unit, fuzz and invariant tests pass.
• A scratch test using the protected floor's opcode walk found no DELEGATECALL, CALLCODE, SELFDESTRUCT or any CALL in the reachable runtime. The scratch directory has been removed.
• The CREATE2 factory-deployment story holds: the factory receives the whole supply and the triggering account gets no balance or allowance.

Static analysis leads. Slither reported nothing. Aderyn's large-numeric-literal note is a readability remark on an underscore-separated constant, not a defect.

Not covered. The protected launch test that seeds a Uniswap v4 pool could not be run here because its v4-core and LaunchLiquidity dependencies are not in this tree. Its token-side preconditions were checked manually and hold. No launch.json exists yet, so manifest review was not applicable.

Review complete. No defects found in the assigned area, and the findings file is written with an empty list and nine coverage rows.

What was reviewed. The token is a single 18-line contract inheriting the vendored OpenZeppelin v5.0.2 ERC20 and minting the fixed supply once to msg.sender. I traced each of the three state-changing entry points through the Execution Trace, Periphery and First Principles checklists.

• Execution Trace. No external calls, no encoding or decoding, no sentinel path that skips validation. The only reads before writes are the balance and allowance reads inside the same internal call, with nothing in between that could make them stale. Reverts are atomic, and the project's own tests confirm allowance restoration on failed transferFrom.
• Periphery. I downloaded the OpenZeppelin v5.0.2 archive from GitHub. Its SHA-256 matches the hash recorded in the vendored README, and all five vendored Solidity files plus the license are byte-identical to upstream.
• First Principles. The supply literal evaluates to exactly 10^27. The compiled ABI exposes only approve, transfer and transferFrom as state-changing functions, with no owner, mint, burn, pause, receive or fallback. A scratch opcode scan mirroring the protected floor test found no DELEGATECALL, CALLCODE, SELFDESTRUCT, CALL or STATICCALL in reachable runtime code.
• Launch flows. A scratch test deployed the token from a CREATE2 factory contract and moved 10 percent, 60 percent via transferFrom and 30 percent with exact amounts and unchanged supply.

Checks run. The project's 30 tests pass, forge fmt passes, and the two scratch tests passed before I deleted them.

Not reached. The protected pool seed and swap test needs v4-core and a LaunchLiquidity source that are not in this tree, so I could not execute it. It is recorded as holds on the strength of the plain ERC20 behaviour, with that limitation stated in the coverage row.

Noted, not reported. The standard ERC-20 approve front-running race exists, as in every OpenZeppelin v5 token, and the README already documents it. The aderyn large-numeric-literal lead is a style note on a correct constant.

The review is complete. The findings file is written and validated, the scratch directory is removed, and git reports no tracked changes (the findings file is ignored by .gitignore, which is expected).

Result: no defects found in the Math Precision, Boundary or Numerical Gap areas. The file .imd-findings.json holds an empty findings list and eight coverage rows.

What the token is. src/WWWToken.sol is a 19-line contract inheriting OpenZeppelin v5.0.2 ERC20 unchanged. Its constructor mints 1_000_000_000 * 10**18 to the deployer once. There are no fees, burns, rebases, owner roles, external calls, receive or fallback functions.

What I verified, with evidence.

• Vendored OpenZeppelin is genuine. All five files are byte-identical to the upstream v5.0.2 archive, whose hash also matches the project's lib README.
• The supply constant is exactly 10^27, evaluated at compile time under checked arithmetic. The aderyn "large numeric literal" lead is not a defect. Whole tokens divide out with zero remainder at 18 decimals.
• No arithmetic can wrap. The only unchecked operations in the ERC20 are guarded by prior checks, and the recipient-balance addition is bounded by a supply far below 2^128.
• Boundary inputs behave correctly: max-uint and supply+1 amounts revert without state change, the infinite-allowance sentinel never decrements while max-1 decrements finitely, exact-N succeeds while N+1 reverts for both balance and allowance across 1,024 fuzz cases, 1-wei transfers deliver exactly 1 wei, and every zero-address path reverts with the expected custom error.
• The 10/60/30 launch split of 10^27 produces no dust, and launch flows move exactly the requested amounts.
• The compiled runtime has no reachable DELEGATECALL, CALLCODE or SELFDESTRUCT and is well under the EIP-170 limit.
• The project's own 30 tests pass with the pinned fuzz seed, and formatting checks pass.

Coverage rows written. All three ABI entry points (approve, transfer, transferFrom) are marked holds, plus rows for the constructor, the supply-conservation invariant, the launch-split invariant, the payable and fallback boundary, and dependency integrity.

Not reached. Nothing within my area was left unverified. The protected launch tests that need the network's Uniswap v4 and factory infrastructure cannot be compiled in this tree and remain with the launch verifier, as the README already states.

The review is complete. .imd-findings.json holds an empty findings list and an 11-row coverage record, and no tracked file was changed.

Result: no substantiated defects in the Economic Security, Invariant or Flow Gap areas. WWWToken is a bare OpenZeppelin ERC-20 with a single constructor mint, and every failure mode the three guides list either has no surface here or was checked and holds.

What I verified

• Supply and conservation. The constructor mints exactly 1e27 units once to the deployer. No public mint, burn, fallback or receive exists, so the sum of balances equals total supply permanently. The project's invariant suite and my own 1024-run fuzz both confirm this.
• Launch flows arrive whole. There is no transfer hook, tax, rebase, pause or blacklist, so the factory to distributor transfer, distributor claims, the pool seed, and swaps each way all move exactly the stated amount. I reproduced the 10/60/30 split and a pool round trip in a scratch test.
• ERC-20 compliance and sentinels. Transfers and approvals involving the zero address revert, finite allowances are consumed exactly, the maximum allowance stays sticky, and failed calls leave balances and allowances untouched.
• Dependency integrity. I re-downloaded the OpenZeppelin v5.0.2 archive. Its hash matches the one in lib/README.md, and all six vendored files are byte-identical to upstream.
• Bytecode floor. A reachability scan using the protected test's own algorithm finds no reachable DELEGATECALL, CALLCODE or SELFDESTRUCT in the runtime code.
• Static analysis lead. The aderyn large-literal note at src/WWWToken.sol:11 is a style remark. The expression evaluates to exactly 1e27 at compile time.

Not reached. The manifest's economics values could not be checked because no launch.json exists yet. That step runs after acceptance, and the token imposes nothing that could contradict those values.

All three verifier-listed entry points are marked holds, along with rows for the constructor, the supply invariant, launch-flow exactness, metadata, dependency integrity and the bytecode floor. The scratch test directory was removed after use.

Added failure-path, boundary, and fuzz tests; strengthened invariants across four actors.

Validation passed:

• forge build --offline
• forge test with the required seed: 50 passed
• 32,768 randomized invariant calls
• Formatting and diff checks

Only test/ files changed. No implementation defects found.

I found no defects, so .imd-findings.json has an empty findings list plus a coverage record for all three entry points.

What the code is: src/WWWToken.sol is 18 lines. It is a stock OpenZeppelin v5.0.0 ERC-20, named "www" with symbol "WWW", and overrides nothing. Its constructor takes no arguments and mints INITIAL_SUPPLY = 1_000_000_000 * 10 ** 18 (1e27) once to msg.sender, which is the factory. It has no owner, no mint after deployment, and no fee, burn, pause or blocklist. I read the bundled library's transfer, approval and allowance code directly and it is unmodified.

Specialist findings: All four specialists and the test writer reported nothing, so there was nothing to reproduce or merge.

Static analysis: Aderyn's only warning was "large numeric literal" at src/WWWToken.sol:11. That is a style note: the number is already written with underscores and is correct. Slither reported nothing.

Coverage (all holds):

• approve: sets the caller's allowance to exactly the amount given, rejects a zero spender and emits the event.
• transfer: moves exactly the amount sent. With no fee, burn or blocklist, the payouts to the distributor and claimants, the pool seed and trades all arrive in full.
• transferFrom: reduces the allowance before moving funds and reverts if the allowance is too small. A maximum allowance is treated as unlimited. No privileged path can spend a holder's balance.

I also added two rows on the overall setup, both holds:

• Supply: it is fixed and equals the manifest's "1000000000000000000000000000".
• Manifest and deployment:
  • Every token field in launch.json matches the code, including the empty constructor arguments, 18 decimals, name and symbol.
  • The contract is well inside the size limits: 1,752 bytes deployed and 2,631 bytes to create.
  • Nothing needs a mined address or extra setup.

Checks run: forge build --sizes and forge test (50 passed, 0 failed). I could not run the official launch test files locally because they depend on the network's own launch code and settings, which aren't in this repository. I traced each of their checks by hand against the token instead.

Files: The only file I wrote is .imd-findings.json; I confirmed it is valid JSON. I deleted the out/ and cache/ build folders afterwards, and no other files changed.