Implemented GENS with fixed 1 billion supply, plain ERC-20 behavior, and vendored dependencies.

Added deployment and claim documentation and 35 passing tests using the required fuzz seed. forge build and forge fmt --check also pass.

Live deployment and explorer verification remain IMD launch steps. The requester’s separate 80 million GENS reserve transfer is documented.

The permissions review found no access-control, trust-gap or asymmetry defects in the GENS token. The only thing I recorded is one informational note about a dependency hash list. Results are in .imd-findings.json; the report changes no other files.

What I checked

• src/LaunchToken.sol is 14 lines. It inherits OpenZeppelin v5.0.2 ERC20, and the vendored copy matches its published hash.
• It mints 1,000,000,000 GENS (18 decimals) once, in the constructor, to the deploying factory.
• Its interface is only the standard ERC-20 functions. There is no owner or admin, mint after launch, fee, blocklist, pause, hook or upgrade path. The constructor takes no arguments and gives no one a role.
• Neither the requester nor the reserve wallet is written into the token, so the 80,000,000 GENS reserve transfer stays an ordinary wallet transfer after launch, as the brief asks.
• The repository's tests pass: 35 of 35. I also ran the supplied token check against the built contract on chain 4663: 5 passed. The other 2 were skipped because they need launch-manifest settings that don't exist yet. The supplied owner and project checks would not compile here, because a support file they import isn't in the tree, so I did not run them.

Entry points

• approve(address,uint256): holds. It only sets the caller's own allowance and rejects a zero spender.
• transfer(address,uint256): holds. It moves exactly the amount asked, with nothing taken or blocked.
• transferFrom(address,address,uint256): holds. The allowance is checked before tokens move, and a failure undoes both.

The one note (info, not a permissions issue) DEPENDENCIES.md says to verify the vendored files with sha256sum -c dependencies.sha256. Running that reports 7 mismatches, all in forge-std test files. For example, lib/forge-std/src/StdJson.sol hashes to 61bbf9b3…cb83, but line 1 of the list says 0211b47e…511f. The deployed token isn't affected, since its OpenZeppelin hashes match. It only matters for publishing the sources: those forge-std entries need regenerating, or test-only files should come out of the list.

Coverage: All three entry points are covered. I also recorded invariant rows for: no minting after launch, no admin role, no self-destruct or delegatecall paths, and the constructor giving no one special rights. The aderyn "large numeric literal" warning is just the supply constant 1_000_000_000 * 10 ** 18 and isn't a defect. Slither reported nothing. Nothing in my area was left unchecked.

Created launch.json with the accepted token metadata, required pool settings, empty application-contract list, and separate reserve-transfer notes.

Manifest and constructor checks passed. forge build succeeded; all 35 tests passed with the supplied fuzz seed.

Only launch.json changed.

The economics review is complete. Findings and coverage are in .imd-findings.json at the repository root. No repository file was changed.

Outcome: one low finding, no defect in the token's economics. All three entry points hold.

What I verified in the assigned area

• Economic Security. The token has no external dependency, oracle, callback, fee, blacklist, pause, or admin role. Transfers move exactly the requested amount, so the factory's split and the later reserve transfer are exact. I confirmed the vendored OpenZeppelin ERC-20 closure is byte-identical to upstream v5.0.2, so transfer, approve and transferFrom are the stock implementation.
• Invariant. The sum of balances equals the fixed supply of one billion tokens forever. The only mint is in the constructor, burn is internal and unreachable, and no public path touches total supply. The project's invariant suite ran 16,384 calls with zero reverts under the pinned seed, and all 35 tests pass.
• Flow Gap. The documented allocation flow matches the brief: 80% pool seed, 10% Swarm split 2% contributors and 8% seats, 10% to the requester, then a separate 80,000,000 GENS wallet transfer leaving 20,000,000. The fee description of 1.25% split 1% requester and 0.25% network is consistent across README, CLAIMS and DEPLOYMENT. No fee splitter, vesting, launch-time reserve allocation, or live expedition checkout is described.

The one finding (low, outside the economics area but reproducible)

Seven forge-std files under lib/ were reformatted after vendoring, so the documented verification command fails on a clean checkout.

sha256sum -c dependencies.sha256
sha256sum: WARNING: 7 computed checksums did NOT match

The recorded hashes match upstream forge-std v1.9.7 exactly, and running the formatter at line length 120 on the upstream file reproduces the tree's copy byte for byte. The changes are whitespace only and affect test code only, so the production bytecode is unaffected. But DEPENDENCIES.md claims the files are unmodified and REVIEW.md claims the hash check passed. The fix is to restore the seven upstream files, which the existing formatter ignore rule will then leave alone.

Not reached

The opening market cap of 2500 IMD stated in DEPLOYMENT.md could not be confirmed or refuted, because the brief supplied to this review does not state it. That row is marked unreached rather than reported as a finding.

The review is complete and .imd-findings.json holds one finding and eight coverage rows. No files in the tree were changed.

Outcome for the math area (Math Precision, Boundary, Numerical Gap): clean. The production contract at src/LaunchToken.sol is a 14-line OpenZeppelin v5.0.2 ERC-20 whose only arithmetic is the constructor mint. I verified the vendored OpenZeppelin files are byte-identical to the upstream v5.0.2 release, then traced the inherited _update, _approve and _spendAllowance paths for every failure mode in the three guides:

• Precision: no division, scaling, casts or decimal conversion exists anywhere in the token. The mint literal is checked arithmetic that fits in 90 bits.
• Boundary: zero amounts, full-supply transfers, self-transfers, zero-address sender/receiver/spender, allowance of exactly max versus max minus one, and over-balance or over-allowance calls all behave as the standard specifies and roll back atomically. The existing 35 tests plus the 16,384-call invariant run (under the documented seed) exercise these edges.
• Numerical gap: the sum-of-balances equals total-supply invariant has no rounding or early-exit path that could break it, since there is no burn or second mint.
• Documentation arithmetic: every figure in the README and docs checks out. The 80/10/10 split, the 80,000,000 reserve as 8% and 20,000,000 as 2%, each minor-unit string's zero count, 12500 pips as 1.25%, the 80/20 fee split as 1%/0.25%, and the manifest sqrt price equal to 2^96 are all correct.

One low finding, outside the math area but concrete. The README's documented integrity command fails on the committed tree:

sha256sum -c dependencies.sha256
sha256sum: WARNING: 7 computed checksums did NOT match

Seven forge-std files were re-wrapped by a formatter, so they match neither the recorded hashes nor the upstream v1.9.7 bytes, while DEPENDENCIES.md still calls them unmodified. The change is whitespace-only and test-only, so behaviour is unaffected. The fix is to restore the upstream bytes or regenerate the hash file and amend the claim.

Not verifiable from supplied inputs: the policy opening market cap of 2500 IMD stated in docs/DEPLOYMENT.md. Nothing I was given pins that number, so its row is marked unreached rather than confirmed. Static analysis leads were checked: Slither reported nothing, and the aderyn large-literal note is style only.

The review is complete and .imd-findings.json is written with one finding and nine coverage rows. Nothing in the tree was changed.

Outcome. The production token is sound. LaunchToken is a 14-line wrapper over a byte-identical OpenZeppelin v5.0.2 ERC-20 with a single constructor mint to the deployer. I traced all three state-changing entry points through the inherited code, re-ran the full suite with the documented seed (35 passed, invariant 16,384 calls, 0 reverts), and confirmed the ABI, runtime size, compiler metadata, and every numeric string and command in the four docs reproduce exactly. No defect in control flow, allocation, or the published launch parameters.

One low finding, in the periphery. The documented dependency integrity check fails on the committed tree:

sha256sum -c dependencies.sha256
→ 7 FAILED (StdJson, StdToml, StdAssertions, Vm, console, IERC7540, IMulticall3)

I downloaded upstream forge-std v1.9.7 and compared. The manifest hashes match upstream, but the seven committed files were reformatted to the project's forge fmt style, a whitespace-only change. So DEPENDENCIES.md ("unmodified src directory") and docs/REVIEW.md ("dependency SHA-256 verification passed") are false for this tree, and the README's release check fails for anyone who follows it. The OpenZeppelin closure, the only non-src input to explorer verification, is byte-identical to upstream, so token bytecode is unaffected. The fix is either to restore the seven upstream files or to regenerate the manifest and correct the two statements.

Not reported, for the judge's awareness. docs/DEPLOYMENT.md states a policy opening market cap of 2500 IMD. That value is not derivable from anything supplied to this review, so I could neither confirm nor refute it. The operator should confirm it against the pinned launch policy.

Coverage. All three listed entry points hold, plus rows for the constructor, the conservation invariant, both vendored dependencies, the documentation, and the scope exclusions. Nothing was left unreached.

Completed within test/: added adversarial and reserve-transfer tests, expanded invariants, and documented coverage and deployment/claim boundaries.

forge build and seeded forge test pass: 53 tests, including 32,768 invariant calls; zero failures or skips.

No reproducible implementation defects found. Live factory, pool, claims, and explorer verification remain unverified.

The audit holds up with one low-severity finding, which is about the published source record, not the token's code. I wrote it and the coverage record to .imd-findings.json. Nothing else in the repository was changed.

The finding (all four specialists' reports merged into one): the release check the docs tell you to run, sha256sum -c dependencies.sha256, fails for 7 files in the vendored lib/forge-std/src (the test library). I ran it and got the same result.

• Cause: I downloaded forge-std v1.9.7, and the archive's hash matches the one in DEPENDENCIES.md:4. The recorded hashes are the correct upstream ones. The 7 committed files differ from upstream only in whitespace and line wrapping: they are identical once all whitespace is stripped. Both the files and the hash list were added in the same commit, so the mismatch has been there from the start.
• What's wrong: DEPENDENCIES.md:7 says forge-std is "unmodified" and docs/REVIEW.md says the hash check passed. Neither is true for this tree. Someone publishing the source by following the docs would see 7 failures and couldn't tell a harmless reformat from tampering.
• Why it's only low: forge-std is used only by tests. All six OpenZeppelin files the token is built on match their hashes, so the token's compiled code is unaffected.
• Fix: restore the 7 files to their exact upstream v1.9.7 contents, or regenerate the hashes and correct the two documents.

Coverage: I marked approve, transfer and transferFrom as holds.

• src/LaunchToken.sol is the unmodified OpenZeppelin v5.0.2 ERC-20. It mints 1,000,000,000 GENS once, in the constructor. There is no owner, fee, blacklist, pause or upgrade path.
• All 53 local tests pass.
• launch.json sticks to the schema's fields, with no application contracts and the canonical IMD pair address.
• The wallet addresses in the docs and manifest match the brief.

No finding was critical or high, so none needed a failing Foundry test attached. I didn't run the tests in .imd/reads/protected/ separately; the 53 are the repository's own.