Implemented EARLY TEST (EARLY) with 1,000,000,000 tokens, 18 decimals, minted once to the deployer. The Telegram URL is exposed as a public community link.

Dependencies are vendored, and deployment assumptions and responsibilities are documented.

Verified with Solidity 0.8.26:

• forge build passed.
• forge test passed: 30 tests using the required fuzz seed.
• forge fmt --check passed.

The network’s protected launch integration remains a separate verification step.

I found no defects, so .imd-findings.json has an empty findings list. Its coverage record marks all three entry points as holds, along with three extra rows for the supply invariant, the bytecode and decimals rules, and the constructor.

What I checked

• The contract: src/EarlyToken.sol is OpenZeppelin v5.2.0's standard ERC20 with nothing changed. It adds two constants (INITIAL_SUPPLY and TELEGRAM_URL), and its constructor mints 1e27 base units once to whoever deploys it. It has no other functions, no owner or admin roles, no fees or burns, no assembly and no external calls.
• Execution trace:
  • transfer and transferFrom move exactly the amount asked. They revert on an insufficient balance or allowance, or a zero address.
  • An unlimited allowance is not reduced when spent.
  • approve has no callbacks, so nothing can re-enter the contract.
  • The only way to mint runs in the constructor, so supply can never grow after deployment.
• Periphery: The launch flows (factory to distributor, to the PoolManager and to the remainder address, then claims and swaps) need no exemptions because nothing is taken from a transfer. No privileged call can move or freeze anyone's balance. There is no DELEGATECALL, CALLCODE or SELFDESTRUCT, and decimals() returns 18.
• First principles: Total supply equals the sum of balances and is fixed. The one ERC-20 quirk left, where changing an existing allowance can be front-run, is built into the standard and isn't a defect here.

Dependencies and tests

• The vendored OpenZeppelin files match dependencies.sha256.
• Seven forge-std files fail that hash check. I compared them with the upstream v1.9.7 archive (whose hash matches DEPENDENCIES.md), and the only differences are whitespace from reformatting. forge-std is used only by tests, but the hash file is now out of date.
• All 30 project tests pass (forge test).

Static analysis: The one aderyn line, a large number literal at src/EarlyToken.sol:12, is the intended 1_000_000_000 * 10 ** 18 and isn't a defect.

Note for the manifest step: the constructor takes no arguments, so token.constructorArgs must be [] and token.totalSupply must be "1000000000000000000000000000".

Not run: I didn't run the protected launch tests. They import contracts this tree doesn't contain (LaunchLiquidity, PoolInitializationGuard, HookFlags) and v4-core, so they can't build here. A clean review is not proof that no defects exist.

I found no defects in the economics area for EarlyToken, so .imd-findings.json has an empty findings list plus a coverage record. The file is valid JSON, and git status shows no changes to tracked files.

What the code is: src/EarlyToken.sol is an OpenZeppelin v5.2 ERC20 with no overrides. Its constructor mints 1_000_000_000 * 10**18 to msg.sender (the factory at launch) and it has one constant, TELEGRAM_URL. The vendored OpenZeppelin files match their pinned hashes in dependencies.sha256, so the library hasn't been modified.

What I checked, guide by guide:

• Economic Security:
  • There are no fees, taxes, rebasing, blacklist, pause, owner, oracle, hook or callback.
  • Nobody can mint or burn after deployment.
  • There's no DELEGATECALL or SELFDESTRUCT.
  • The Telegram link is a stored string and has no effect on chain.
  • With none of these, there's nothing to extract or freeze.
• Invariant:
  • Total supply stays at 1e27 forever: the only mint is in the constructor.
  • The sum of all balances always equals total supply: every transfer debits and credits the same amount.
  • Allowances drop by exactly the amount moved (an unlimited allowance isn't reduced).
  • decimals is 18, matching the brief.
  • The existing invariant suite passes (128 runs, 8,192 calls, no reverts), as do the other 29 tests.
• Flow Gap: the factory → distributor, factory → PoolManager pool seed, and trader buy/sell paths all move exactly the amount stated, because no transfer is altered. Nothing in a launch flow can arrive short.

Coverage: all three entry points (approve, transfer, transferFrom) are marked holds. I added four more rows for the invariants and economic checks above.

What I didn't report, and why:

• The aderyn "large numeric literal" warning is just how the supply is written, not a defect.
• Two standard ERC-20 traits apply to every plain ERC-20, not to this code: an allowance change can be front-run, and tokens sent to the token contract itself stay there.
• Since there are no findings, I wrote no Foundry proof tests.
• I didn't run the protected floor tests. They import harness files (floor/OwnerChecks.sol, v4-core, LaunchLiquidity) that aren't in this tree.

A clean review doesn't prove the code has no defects. It means none could be reproduced within this area.

Created launch.json matching EarlyToken, its exact supply and constructor, and the required pool and economics.

Manifest and compiled ABI checks passed. forge build succeeded; all 30 local tests passed with the supplied fuzz seed. Only launch.json is changed for submission.

The review is complete and the findings file is in place and validated.

Result: the EARLY token's permission surface is clean. One low-severity defect, outside my assigned area, is recorded in .imd-findings.json with ten coverage rows.

What I checked

• EarlyToken is a plain OpenZeppelin v5.2.0 ERC20 whose constructor mints exactly one billion tokens to its caller. It has no owner, roles, initializer, hooks, overrides, proxy, or fee logic.
• The vendored ERC20 file is byte-identical to upstream v5.2.0, so approve, transfer and transferFrom run canonical code. Each was traced through its guards, state writes and revert paths and holds.
• Access Control, Trust Gap and Asymmetry checklists all come up empty. There is no privileged actor, no paired function with divergent accounting, no second writer of any storage slot, and no seam between authorization and economics.
• The launch flows deliver exact amounts because nothing overrides transfer. The project's 30 tests pass on the pinned compiler, including the stateful invariant runs. The static-analysis lead about the large literal is exactly the manifest supply and is not a defect.

The one finding (low)

The repository instructs operators to verify vendored dependencies with sha256sum --check dependencies.sha256, and DEPENDENCIES.md claims the files are unmodified. That command fails for seven forge-std files. The recorded hashes match upstream v1.9.7 exactly, so the vendored copies are what diverged. The difference is whitespace only, a formatter pass, so the test library is semantically intact and deployed bytecode is unaffected. The author should restore the pristine files or regenerate the hash file and correct the claim.

Not reached: the protected launch harness requires environment variables and Uniswap v4 libraries not present in this tree, so I could not execute it. Its token-level assertions are all satisfied by plain ERC-20 semantics, which the local launch test exercises.

The review is complete and the findings file is written. The tree has no changes other than the excluded findings file.

Outcome. The math audit of EarlyToken found no arithmetic, boundary or numerical-gap defect. One low-severity finding outside my area is recorded, and all three entry points are marked holds in the coverage record.

What I covered. The token is a 20-line wrapper over the vendored OpenZeppelin v5.2.0 ERC20, whose files all match their recorded checksums. I walked the three guides against every operation that touches a number:

• Math Precision. The only custom arithmetic is the constant one billion times ten to the eighteenth, a compile-time literal far below the uint256 limit. There is no division, rate, fixed-point scale, narrowing cast or decimal conversion anywhere, so the aderyn "large numeric literal" lead is cosmetic. The unchecked subtractions and additions inside the inherited update path are bounded by a prior balance check and by a total supply that never grows.
• Boundary. The contract makes no external calls, has no receive or fallback, decodes no bytes, and has no sentinel branches beyond OpenZeppelin's zero-address rejections. Plain ETH sends and value-bearing calls revert.
• Numerical Gap. With no truncating operation, no seam exists. Zero-value transfers run the normal path, and the infinite-allowance skip leaves the max value unchanged by design.

I confirmed these with a scratch Foundry test exercising the edges: exact-balance and balance-plus-one transfers, max-uint from an empty account, allowance exactly equal to the amount, one below infinite, infinite, and a fuzzed three-party sum-of-balances invariant. Every case behaved as specified, and the launch splits of ten, eighty-eight and two percent of the supply divide with zero remainder. The scratch file was removed afterward.

The one finding. The README lists a checksum step as part of the build check, and DEPENDENCIES.md states the vendored files are unmodified. Running that step fails for seven forge-std test-library files whose content differs from the hashes recorded in dependencies.sha256. This does not affect the production bytecode, since the OpenZeppelin sources match. It is a reproducibility and documentation defect, reported as low with the exact recorded and actual hashes.

Not reached. Nothing within the assigned area was left unexamined. Uniswap v4 seeding and price derivation happen in the deployer and the protected harness, not in this token, and were not reviewed beyond confirming that the token adds no fee that could short those flows.

Added 15 tests covering boundary values, authorization, and failure recovery. Expanded invariants to 32,768 randomized calls.

forge build and forge test pass with the supplied seed: 45 passed, 0 failed.

Only test/ changed. No implementation defects found.

Review complete. The findings file is written at .imd-findings.json with one finding and a six-row coverage record.

Outcome: the token is clean. EarlyToken is an unmodified OpenZeppelin v5.2.0 ERC20 with a no-argument constructor that mints the full supply once to the deployer. It exposes no mint, burn, owner, pause or blocklist entry points. The build, the 45-test suite with the assigned fuzz seed, and forge fmt --check all pass. Creation and runtime code are well under the size limits, and the manifest's name, symbol, decimals, supply and empty constructor arguments match the contract.

Specialist findings: both reports describe the same defect, so I merged them into one low finding and reproduced it myself.

• Dependency integrity check fails. DEPENDENCIES.md claims all vendored files are unmodified, and the README lists sha256sum --check dependencies.sha256 as a build step. On the committed tree that command fails for seven forge-std files. I fetched the seven from the upstream v1.9.7 tag: their hashes match the recorded entries exactly, and with whitespace stripped they match the vendored copies, so the vendored files were reformatted. The library is test-only and the vendored OpenZeppelin ERC20 is byte-identical to upstream, so deployed bytecode is unaffected. Fix is the author's, since lib/ is not reviewer-writable.

Leads dropped: the aderyn large-numeric-literal note is style only, since the literal already uses separators and an exponent.

Coverage: all three entry points (approve, transfer, transferFrom) hold, plus rows for the supply invariant, CREATE2 deployability, and the lib integrity finding.