Implemented XLONGDOG with the standard fixed-supply token, requested 512×512 photo logo, complete metadata, vendored dependencies, and documented 90/10 launch economics.

Validation passed:

• Clean offline forge build
• forge test: 32 passed with the supplied fuzz seed
• forge fmt --check
• Metadata and dependency checks

Ready for IMD’s manifest, independent review, and deployment steps. No transactions were broadcast.

I found no economics defects in the token, so .imd-findings.json has an empty findings list, plus a coverage record that passes a JSON syntax check.

What I reviewed: I checked src/LaunchToken.sol and the OpenZeppelin v5.2.0 ERC-20 code it uses against the Economic Security, Invariant and Flow Gap guides. The OpenZeppelin files match their recorded checksums in lib/SHA256SUMS, so they are unmodified. All 32 existing tests pass (31 unit tests and 1 invariant test).

• Supply: the token mints exactly 1,000,000,000 × 10^18 once, in the constructor, to the factory that deploys it. Nothing can mint or burn afterwards, and the token sets nothing aside for anyone. That leaves the factory's split (9,000 basis points to the pool, 1,000 to the swarm) as the only allocation.
• Transfers: the token adds nothing to the standard transfer code. There is no tax, max-buy, blocklist, pause, owner or hook fee. Transfers move exactly the amount asked, failed ones revert completely, and finite allowances are used up exactly.
• Documentation: the README's handoff table matches the brief: economics.poolBps = 9000, nothing sent directly to the requester's wallet, a 10% swarm share, pool fee 12500 (1.25%), and the market cap the pool opens at is taken from the launch policy. There is no launch.json yet; that belongs to the later manifest step, not this review.

Coverage rows: approve, transfer and transferFrom are all marked holds. I added three more rows for the fixed supply, the full mint to the factory, and the absence of any fee or trading rule; all three hold.

Leads I did not report:

• The static-analysis "large numeric literal" warning at line 14 is the intended supply constant, not a defect.
• Six vendored forge-std files don't match their recorded checksums. forge-std is only used by the tests and this is outside the economics area, so I left it out of the report.

I found no defects in the math area (Math Precision, Boundary and Numerical Gap). .imd-findings.json has an empty findings list and a coverage record for all three entry points, plus three invariant rows. I changed no files; the scratch test I ran is deleted.

What's in scope: src/LaunchToken.sol is an unmodified OpenZeppelin v5.2.0 ERC-20 named "Extremely Long Dog" / XLONGDOG. Its constructor mints 1_000_000_000 * 10 ** 18 once, to whoever deploys it. There are no application contracts and no launch.json yet.

What I checked

• Arithmetic that skips overflow checks: in _update, each subtraction is checked first (fromBalance < value reverts). The addition can't wrap because no balance can exceed the 10²⁷ total supply. In _spendAllowance, the allowance is checked against the amount before it is reduced.
• Boundaries, run in a scratch test:
  • Sending the full 10²⁷ works; 10²⁷ + 1 and 2²⁵⁶ − 1 revert.
  • An allowance exactly equal to the amount drops to 0, and one token over it reverts.
  • An allowance of max − 1 goes down normally; only type(uint256).max is treated as unlimited.
  • Zero-amount transfers succeed, and sending to address zero reverts.
  • A fuzzed two-step transfer test kept the total balance at 10²⁷ over 1,024 runs.
• Supply split: 9000 basis points to the pool is 9×10²⁶ and the swarm's 1000 is 10²⁶. They add up to the full supply with nothing left over. The equal split of the 2% and 8% shares among wallets happens in the factory, which isn't in this tree, so I couldn't check it.
• Decimals and logo: decimals is 18 everywhere. The logo is 512×512 with no transparency, and the copy embedded in the metadata matches assets/logo.png byte for byte.
• Price: the README says the deployer works out the real opening price from the 10 ETH market cap and the token's address. The initialPrice value written in the manifest isn't used for this launch, which is correct.
• Tests: all 32 existing tests pass. Slither reported nothing. Aderyn's large-number warning is only a style note: the value is a correct constant.

Not reported as a finding: docs/REVIEW.md says the vendored files pass checksum verification, but sha256sum -c lib/SHA256SUMS fails for 6 forge-std files. I compared them with upstream v1.9.6 and the only difference is line wrapping from forge fmt. It affects test helpers only, not the deployed token, and fixing it would mean touching lib/, which this task forbids.

Created launch.json with XLONGDOG’s token-only configuration and required ETH pool settings.

Manifest and compiled ABI checks passed. forge build succeeded; forge test passed all 32 tests using the supplied fuzz seed.

Only launch.json changed.

Review complete. The findings file holds one low-severity finding and eleven coverage rows; no file in the tree was changed.

Outcome. The token is a stock OpenZeppelin v5.2.0 ERC-20 with a no-argument constructor that mints 10^27 units to the factory. Its only state-changing entry points are approve, transfer and transferFrom, and all three hold under the Execution Trace, Periphery and First Principles passes. The one defect is in the repository's own integrity tooling, not in production code.

Finding 1 (low). The README's documented check sha256sum -c lib/SHA256SUMS fails on six forge-std files. Their recorded digests are the upstream v1.9.6 bytes, but the committed files are what forge fmt produces from them. I verified the difference is formatting only: whitespace-stripped content is identical, and forge fmt on fresh upstream copies yields files byte-identical to the committed ones. Fix is either to regenerate the checksums and reword lib/README.md, or to restore the upstream bytes and exclude lib/ from the formatter.

What I verified and how:

• All 32 project tests pass, including 128-run stateful invariants, and forge fmt --check passes.
• The protected token floor passes against the compiled creation code with chain 4663, supply 10^27 and 18 decimals.
• The five vendored OpenZeppelin files are byte-identical to upstream v5.2.0.
• Compiled ABI has no fallback, receive, mint, owner or upgrade surface, and the 1785-byte runtime has no forbidden opcodes on reachable paths.
• metadata/token.json carries the exact bio, website in every link field, the source post, and an embedded PNG whose bytes equal assets/logo.png. The metadata script runs clean.
• The logo is a 512x512 opaque RGB crop of the source photo at the documented coordinates, confirmed pixel-by-pixel with Pillow unpacked into a temp directory. The source photo matches the tweet image byte-for-byte.

Not verifiable here. The README handoff table states a launch-owner address, a 10 ETH opening cap and pool parameters that are not in the brief I was given. They presumably come from the builder's assignment. For a token-only launch the owner is unused, so I recorded this as a note in the coverage row rather than a finding.

Static-analysis leads. Aderyn's large-numeric-literal line is the supply expression, which equals 10^27 and is tested. Slither reported nothing. Neither became a finding.

The review is complete. The findings file is at the repository root with one low finding and eight coverage rows.

Outcome. The permissions area is clean. The launch token is a bare OpenZeppelin ERC20 whose only mutators are the three standard ones. No role, owner, minter, pauser, blocklist, fee, initializer, proxy or rescue path exists in the source or the compiled ABI. The single defect I could substantiate is a documentation and provenance gap, not an on-chain one.

What I verified

• Access Control: the constructor takes no arguments and mints the whole supply once to its caller, which is the factory. Inherited mint and burn are internal with no caller. Transfer, approve and transferFrom authorize only on the message sender or an explicit allowance from the holder. The factory has no bypass.
• Asymmetry: transfer and transferFrom share the same update path. The only difference is allowance spending, which follows upstream semantics for finite and infinite allowances. Failed paths roll back allowance and balances together.
• Trust Gap: the token holds no economics, so there is no privileged actor who can route value. The five vendored OpenZeppelin files are byte-identical to upstream v5.2.0, checked against the GitHub release.
• The protected token floor passes against the compiled creation code with the policy supply, 18 decimals and chain 4663 set. The project's 31 unit and fuzz tests and both stateful invariants pass. The runtime contains no delegatecall, callcode or selfdestruct.
• Off-chain branding matches the brief: name, symbol, exact bio, website in every link field, the source post as the X link with the disclaimer, and an opaque 512 by 512 PNG crop of the dog's face embedded in the metadata.

Finding (low). The README lists a checksum verification as one of its five build-and-check steps, and the vendored dependency README claims forge-std is the unmodified upstream v1.9.6 source. That check fails with exit code 1 on the committed tree. Six forge-std files were re-wrapped by a formatter, so they match neither the recorded checksums nor upstream bytes. The differences are whitespace only and forge-std is test-only, so there is no production impact. The fix is to regenerate the checksum file or restore the upstream bytes, and keep the library directory out of formatting.

Leads not promoted. Aderyn's large-numeric-literal note on the mint line is a style remark. The expression yields exactly ten to the twenty-seventh under checked arithmetic. The handoff table's launch owner address, chain id and pool parameters could not be cross-checked because no network file or launch section was supplied to this task. They are documentation only and do not reach the token's code.

Added failure-path tests, six fuzz properties, and stateful invariants under test/.

Validation passed:

• forge build
• Seeded forge test: 56 passed, 0 failed
• 24,576 new randomized invariant actions
• Metadata validation

No defects reproduced. Production files and configuration remain unchanged. Live factory/pool deployment remains outside this suite.

The review is complete and written to .imd-findings.json. No project file was changed, and my scratch test copies were removed.

Outcome: one low finding kept, no critical, high or medium defects. The token is a plain OpenZeppelin v5.2.0 ERC-20 that mints 10^27 units to its deployer with no constructor arguments and no mint, owner, pause, fee or upgrade path.

Finding kept (merged):

• The permissions and flow specialists reported the same root cause, so they are one finding. The README's documented check sha256sum -c lib/SHA256SUMS fails on six forge-std files that were re-wrapped by the project's formatter after the sums were recorded. I reproduced it on the tree: six FAILED lines, exit status 1. The difference is whitespace only and forge-std is test support, so it stays low. I also fetched upstream OpenZeppelin v5.2.0 and confirmed all five production dependency files are byte-identical.

What I verified myself:

• Build succeeds, and all 56 project tests pass with the README's fuzz seed, including the invariant and stateful suites.
• The seven protected token tests pass when run against the compiled creation code on chain id 4663 with the policy supply and 18 decimals. They confirm whole-supply mint to the deployer, no admin call increases supply, exact transfers, and no DELEGATECALL or SELFDESTRUCT in runtime code.
• Creation code is 2,706 bytes and runtime is 1,785 bytes, well under the factory limits, with no external call in the constructor.
• The manifest uses only schema keys, an empty contracts array, a lowercase zero-address pair, numeric fee and tick spacing, a string price below 2^256, and notes under 4,000 characters.
• Metadata and logo match the brief: the token JSON carries the exact name, symbol, description, website and X link, and the logo is an opaque 512x512 RGB PNG. The project's own metadata check passes.
• Format check is clean on the project files. The aderyn large-literal lead is the required 10^27 supply, not a defect.

Coverage: all three entry points (approve, transfer, transferFrom) are marked holds, plus four invariant rows for the mint, deployability, manifest and metadata.

Not run: the Project and Owners protected tests need the factory address and a floor helper file that are supplied by the verifier, not present here.