Implemented WMT with exactly 1,000,000,000 tokens, 18 decimals, minted once to the deployer.

Vendored dependencies and documented deployment assumptions and responsibilities in README.md.

Validation passed:

• forge build
• forge test — 34 passing with the supplied fuzz seed
• forge fmt --check

I found no defects in WMT. .imd-findings.json has an empty findings list and a coverage row for each of the three entry points, all marked holds. I changed no other files.

What I reviewed: src/WMT.sol is an unmodified OpenZeppelin v5.2.0 ERC20 with no overrides. Its constructor mints INITIAL_SUPPLY (1e9 × 1e18) once to msg.sender, which is the factory in a launch. The vendored OpenZeppelin files' SHA-256 hashes match DEPENDENCIES.json. I didn't check them against the upstream v5.2.0 release because that needed a network download, but the code reads as the standard release.

The three guides:

• Execution Trace:
  • transfer and transferFrom go straight to the unmodified _update. Zero addresses revert, the sender's balance is checked before the debit, and the recipient gets exactly the amount sent, with no fee or burn.
  • That means the launch flows (factory to distributor, the pool seed through the PoolManager, and swaps) arrive whole.
  • transferFrom takes the allowance before moving tokens and leaves an unlimited (max) allowance unchanged, which is standard. A failed call reverts entirely, so no partial state is left behind.
• Periphery: The only dependencies are the vendored ERC20, Context and the error interfaces. There are no external calls, callbacks or hooks, so nothing can re-enter mid-transfer.
• First Principles:
  • The supply can't grow after launch, because the only mint is in the constructor and there is no owner, role, pause, blacklist or burn function.
  • decimals() returns 18.
  • I scanned the deployed bytecode for DELEGATECALL, CALLCODE and SELFDESTRUCT and found none.

Leads I dropped:

• Aderyn's "large numeric literal" flag at src/WMT.sol:10 is just how the supply constant is written, not a defect.
• The usual front-running risk when changing an approve amount is standard ERC20 behaviour, not something specific to this code.

Tests: The existing suite passes (34 tests, including an invariant run of 16,384 calls with no reverts). I didn't run the protected launch tests: they import launch contracts (src/LaunchLiquidity.sol and two others) that aren't in this tree.

Created launch.json matching WMT’s constructor, exact supply, and required pool and economics values.

Manifest and ABI checks passed. forge build succeeded; forge test passed all 34 tests with the supplied fuzz seed.

Only launch.json changed.

The review is complete and the findings file is written. The git tree shows no changes other than the ignored review output.

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

What was reviewed

• The token is a 17-line contract inheriting unmodified OpenZeppelin ERC20 v5.2.0. The vendored files hash-match the dependency record and the ERC20 body matches upstream.
• The supply constant evaluates at compile time to exactly 10^27, which equals the manifest value and fits in uint256. The aderyn large-literal lead is stylistic only.
• All three entry points were traced through the inherited code. Balance subtraction is checked before the unchecked branch, recipient addition cannot wrap because balances sum to the fixed supply, and the allowance path treats max-uint as infinite while max-minus-one is finite and decremented.
• The token has no external calls, no payable functions, no receive or fallback, and no bytes decoding, so the Boundary guide's call-site and payable cases do not apply. The only sentinel branches are the zero-address reverts, and both sides were walked.
• The launch split of 10%, 88% and 2% of the supply is exact with no remainder and no overflow in the intermediate products.

Checks run

• The project's own suite: 34 tests passed, including the invariant suite at 256 runs of depth 64 with reverts treated as failures.
• A scratch probe suite of 9 tests covering exact-balance, exact-allowance, max-uint, zero-value, zero-address, self-transfer of the whole supply, ETH rejection and a balance-add fuzz. All passed and the scratch directory was removed afterwards.

Not covered. Nothing in my area was left unreached. The protected Uniswap v4 launch harness needs environment variables and the v4 sources, which are not in this tree, so the real pool seed and swap were not executed here. The project test only simulates pool accounts with plain transfers.

The review is complete. The findings file is valid JSON, the working tree is clean, and no scratch files remain.

Result: no defects found in the Economic Security, Invariant and Flow Gap areas. The findings list is empty and every entry point has a coverage row.

What I checked:

• The token source. src/WMT.sol is a 17-line contract that inherits the unmodified OpenZeppelin v5.2.0 ERC20 and mints one billion tokens with 18 decimals to the constructor caller. The vendored library files hash-match the recorded dependency manifest, and the compiled ABI exposes only approve, transfer and transferFrom as state-changing functions, with no receive, fallback, mint, burn or admin path.
• Economic Security guide. No external dependencies, no fee or rebase behaviour, no sentinel-address special cases, no privileged powers. Transfers and approvals to the zero address revert. ETH sent to the token reverts.
• Invariant guide. Total supply is fixed at deployment and cannot grow or shrink afterwards, and the sum of balances always equals it. The project's own invariant suite and fuzz tests pass under the pinned seed.
• Flow Gap guide. The launch legs (factory to distributor, distributor to claimant, factory seed into the pool manager, trader buy and sell) all move exactly the stated amount. I ran a scratch test confirming the 10/88/2 split of the supply is dust-free and that a balance-delta settlement sees exactly what was sent. It passed and has been deleted.
• Static analysis lead. The aderyn large-literal note is a style remark only. The constant evaluates to exactly the manifest supply.

Not reached: nothing in my area. The protected launch suite against a real Uniswap v4 PoolManager depends on v4-core, which this repository does not vendor, so I did not execute it locally. The token's lack of any transfer customisation means there is no mechanism by which that path could behave differently from the local exact-transfer tests.

Review complete. The findings file is written and validated, and the working tree contains only my scratch test and the findings file.

Outcome: the WMT token has no access-control, trust-gap or asymmetry defects. The contract is a 17-line wrapper over the unmodified OpenZeppelin v5.2.0 ERC20 with a single constructor mint, and every failure mode in my three guides needs a privileged actor, a setter, a paired admin variant, or a second economic formula. None of these exist.

What I verified, with concrete checks:

• Permission map is empty by construction. The compiled ABI has only the constructor, the three listed state-changing functions, seven views, two events and six ERC-6093 errors. Storage is the five OpenZeppelin slots. There is no receive or fallback.
• Deployer and factory have no privilege. A scratch suite under test/scratch/ replays the protected harness: CREATE2 deployment from a probe with a different origin gives the probe the whole supply, 22 admin, mint, pause, blacklist and upgrade selectors revert from the probe, the origin and a stranger, and the factory cannot pull a holder's balance without allowance.
• approve and transferFrom mirror exactly. A fuzz test over allowance, amount and spender confirms the allowance decrement equals the amount moved, reverts leave the allowance intact, and no caller can set another owner's allowance.
• Supply is fixed. The literal aderyn flagged evaluates to exactly the manifest's supply. No mint or burn path survives the constructor. The project's own 34 tests and the 16,384-call invariant run pass with the README's seed.
• Vendored OpenZeppelin is byte-identical to v5.2.0. All six files match their recorded hashes.

One informational finding is recorded, outside my area. DEPENDENCIES.json records upstream forge-std v1.9.7 hashes, but seven vendored forge-std files were re-wrapped by the formatter and no longer match them, contradicting the README's "unmodified" claim. I confirmed against the downloaded upstream archive that every difference is whitespace only, so it does not affect the deployable bytecode. The reproduction is a one-line hash check given in the finding.

Coverage: all three entry points plus the constructor are marked holds, with six invariant rows. Nothing was left unreached. The real PoolManager seed and swap path was not executed locally and is left to the protected suite, which I noted in the coverage row.

The review is complete and .imd-findings.json is written. No repository file was changed.

Outcome: the WMT token is sound. It is an unmodified OpenZeppelin v5.2.0 ERC-20 with a parameterless constructor that mints exactly the manifest supply to the factory. All three entry points hold, and the only finding is an info-level provenance inaccuracy.

What I verified

• Build and the project's 50 tests pass under the pinned fuzz seed, and forge fmt --check is clean.
• The six vendored OpenZeppelin files are byte-identical to the upstream v5.2.0 archive, whose hash matches the one recorded in DEPENDENCIES.json.
• The deployed bytecode contains no DELEGATECALL, CALLCODE, SELFDESTRUCT or any CALL-family opcode, has no payable or fallback paths, and is far below size limits. Deployment through the factory's CREATE2 needs no arguments or address bits.
• launch.json uses only schema keys, matches the token's name, symbol, decimals and supply, and matches this launch's pool and economics values from the reference.
• The protected suite could not run here because it imports v4-core and floor files not in this tree, but every check it makes was traced directly against the code and holds.

Specialist findings

• The permissions specialist's hash mismatch reproduces exactly. Seven forge-std files differ from the recorded upstream hashes, and I confirmed the differences are whitespace-only reformatting. Kept at info, since forge-std is test-only and the deployable bytecode does not depend on it. The fix is to re-vendor those files byte-for-byte or regenerate the hashes and soften the "unmodified" wording.
• The aderyn large-numeric-literal lead is the correct supply constant and was dropped.
• Math, flow, economics and the test writer reported nothing, and my own pass found nothing they missed.

Coverage: all three entry points answered as holds, plus five invariant rows covering supply, deployability, opcodes, manifest validity and dependency provenance.