Approved workflow

Implemented the fixed-supply HX token, vendored dependencies, ABI export, tests, and deployment documentation.

Validation passed: forge build, forge test, forge fmt --check, 23 project tests, expanded fuzz testing, and all nine supplied protected tests.

Documented Ethereum mainnet deployment and the 88% ETH-pool allocation. Manifest generation, independent review, and deployment remain separate workflow stages.

Created launch.json for HX with native ETH pairing and no application contracts.

Validated schema, refinements, source metadata, and compiled ABI. Offline build, formatting check, and all 23 tests passed, including the second 1,024-run fuzz check.

Only launch.json is changed for submission.

The review is complete and the findings file is in place at the repository root. The working tree has no stray files. Only the build cache, the output directory, and the required findings file remain, all git-ignored.

Result: no defects found. The findings list is empty and the coverage record answers all three entry points plus six checked invariants.

What I verified in my area (Execution Trace, Periphery, First Principles):

• Entry points. I traced approve, transfer and transferFrom through the vendored OpenZeppelin code. Zero addresses revert, allowance is spent before the transfer and both roll back atomically, infinite allowance is never decremented, and no path touches total supply after construction.
• Periphery. The five vendored OpenZeppelin files match upstream v5.5 line by line, and the committed checksum file verifies. No mirror was available to diff against, so this rests on reading the content.
• First principles. The constructor takes no arguments, is nonpayable, and mints exactly one billion tokens at 18 decimals to the deploying caller. The compiled ABI exposes nine ERC-20 functions and nothing privileged. Runtime is 1785 bytes with no forbidden opcodes.
• Artifacts. The exported ABI in docs/abi is byte-identical to fresh compiler output. The project suite passes 23 of 23 tests. The supplied protected floor passes 9 of 9 tests against the real creation code with the policy supply, 18 decimals, chain 1 and zero application contracts.
• Brief conformance. Name, symbol, supply, no owner powers, ETH pairing and the 88% pool share in the README all match the approved workflow.

Not checked. No launch.json exists yet, so manifest conflicts could not be reviewed at this stage. The standard ERC-20 approval replacement race is present but is inherent to the unchanged token the brief requires, and the README documents it, so I recorded it as a note rather than a defect.

The findings file is in place at the repository root, excluded from git by the harness's own rule, and no source files were changed. The review is complete.

Result: no defects found in the math, boundary or numerical-gap area. The findings list is empty and nine coverage rows are recorded, all holds.

What was checked

• The token is a zero-argument OpenZeppelin v5 ERC-20 that mints one fixed amount to the deployer. The supply literal evaluates to exactly 10^27, which is the policy supply and about 2^89.7, so no balance, allowance or Uniswap v4 uint128 amount can saturate.
• Every unchecked block in the vendored library sits behind a guard that bounds it. The balance subtraction follows an explicit insufficient-balance check, the allowance subtraction follows an insufficient-allowance check, and the infinite-allowance skip triggers only at exactly the maximum value.
• Scratch probes covered max-uint transfers, supply plus one, one wei round trips, self-transfers, allowance exactly at and one below the spend, allowance of max minus one, infinite allowance with an over-balance spend, and a creation with ETH attached. All reverted atomically or moved the exact amount with no allowance drift.
• The token has no external calls, no payable or fallback path, no division, no decimals conversion and no bytes decoding, so the Boundary guide's call-site and payable checklists have no entries to fail.
• The 88/2/2/8 split sums to the supply with zero remainder. Equal division among worker and seat wallets is factory arithmetic outside this tree.
• The vendored library matched its recorded checksums, the exported ABI matched the compiler output byte for byte, and the project suite passed 23 of 23. Both supplied protected floors passed 9 of 9 with the policy supply, 18 decimals, chain 1 and an empty application list.

Static-analysis lead

The aderyn large-numeric-literal note on line 11 of the token is a style observation. The value it flags is correct and verified by test, so it was not promoted to a finding.

Not covered

Nothing in the assigned area was left unreached. Launch manifest review was not possible because no launch.json exists in this tree yet.

Review complete. .imd-findings.json is written with zero findings and a full coverage record; no tracked file was changed (git status is clean apart from the output file, which is ignored).

What I reviewed (Access Control · Trust Gap · Asymmetry)

Scope: src/LaunchToken.sol (13 lines — a zero-arg constructor over vendored OpenZeppelin ERC20 5.5.0), the vendored ERC20.sol/Context.sol/IERC6093.sol, docs/abi/LaunchToken.json, README/REVIEW parameters against .imd/reads/workflow.md. No launch.json exists yet, which is expected at this stage.

Access control. The permission model is empty by design: no roles, modifiers, initializer, owner, pause, mint, burn, or upgrade path. The only state writers are transfer/transferFrom → _update and approve/_spendAllowance → _approve; both pairs carry identical zero-address guards, so there is no weakest-guard writer to exploit. The compiled ABI (which I regenerated with forge inspect and compared — identical to docs/abi/LaunchToken.json) exposes exactly nine ERC-20 functions.

Asymmetry. transfer ↔ transferFrom differ only by _spendAllowance running first; a failed transfer reverts the allowance debit atomically. approve emits Approval, allowance consumption does not — upstream OZ 5.x behaviour, documented in the README. Infinite allowance uses < rather than !=; I diffed the vendored file against OZ 5.1 copies in sibling workspaces and every difference is an upstream 5.1→5.5 change, not an injection.

Trust gap. The only "privileged" position is the constructor's msg.sender holding the whole supply, which is the factory — the intended protocol trust assumption, not a defect. No economic primitive exists inside the token for any actor to exploit asymmetrically.

Verification run: forge build --offline, project suite 23/23, and the supplied protected floors re-run in test/scratch/ with the compiled creation code (factory 0x…fac7, chain 1, CREATE2 salt 1, 0 projects): 9/9 pass. Scratch removed afterwards.

Static-analysis leads: aderyn's large-numeric-literal at LaunchToken.sol:11 is 1_000_000_000 * 10 ** 18 = 10^27 exactly — correct, not reportable. Slither reported nothing.

Not reported on purpose: the standard ERC-20 approve front-running race. It is inherent to the "standard IMD fairlaunch token, unchanged" the brief mandates and is already disclosed in the README; flagging it would not open a legitimate revision.

The review is complete and .imd-findings.json holds the result. No tracked file was changed, and the scratch tests were removed.

Outcome: no defect in the token's economics, invariants or flow. The only entry is one info-level documentation note.

What I checked, in the assigned area

• Economic Security. The token has no external dependencies, oracles, callbacks or sentinel-address paths. It is not fee-on-transfer, rebasing or pausable, so the factory's 88/2/2/8 split and pool seeding deliver the amounts they assume. Zero-address approve and transfer revert rather than silently succeeding.
• Invariants. Total supply is exactly 10^27 and can never change: the only mint is in the constructor, and the internal mint and burn helpers are unreachable afterwards. A scratch StdInvariant run of 128,000 handler calls across transfers, finite and infinite allowances and overspend attempts found no conservation or allowance violation.
• Flow Gap. The constructor mints to msg.sender, which is the factory, and the token holds nothing itself. Both supplied protected floors pass against the compiled creation code with the factory stand-in, CREATE2 prediction, supply 10^27, decimals 18 and chain ID 1. The exported ABI in docs/abi/LaunchToken.json is byte-equal to the compiler's output, and all vendored OpenZeppelin files match the recorded hashes.

The one finding, info severity. The README table titled as manifest parameters lists chain ID and the 88% pool share next to real launch.json fields. Neither is a manifest field, and the schema rejects extra keys. The concrete failing input is a manifest copied from that table, which fails validation twice. The real exposure is the reverse: the 88% share is enforced only by the pinned policy row, so the final manifest reviewer must cross-check it there, not in launch.json.

Coverage. All three listed entry points are recorded as holds, with four additional invariant rows. The aderyn lead on the large literal is a compile-time constant equal to 10^27 and is not a defect. The standard ERC-20 approve-replacement race is inherent to the brief's demand for an unchanged standard token and is documented, so it is not reported.

Added failure-path tests, fuzz properties, and three stateful invariants covering supply, balances, and allowances.

Offline build, both test runs with different seeds, and formatting checks passed: 40 tests, zero failures.

Only test/ changed. No contract defects were reproduced.

The review is complete. The findings file is written and the working tree is otherwise untouched.

Outcome: the token launch is clean. The only finding kept is the economics specialist's documentation note, downgraded to info.

What I verified against the code:

• LaunchToken source is a bare OpenZeppelin v5 ERC20 with a zero-argument constructor minting exactly 10^27 minor units to the deployer. No owner, mint, pause, fee, upgrade or hook paths exist. All three entry points hold.
• Vendored libraries are unmodified. All 40 files match the committed checksums, and I read the ERC20 and Context sources in full.
• The protected token floor passes 7 of 7 against the compiled creation code with the expected supply and decimals.
• The project's own suite passes 40 of 40, including the invariant handlers.
• launch.json conforms to every LaunchManifest constraint, names the token correctly, pairs with native ETH, and carries no extra keys.
• The exported ABI is byte-identical to the compiled artifact.

The one finding, at README line 38, is that the table headed "Parameters for the separate manifest assignment" lists chain ID and the 88% pool share, neither of which the manifest schema accepts. The delivered launch.json did not copy them, so no defect materialized. The residual point for the admission reviewer is that the 88% pool share lives only in the pinned policy row, not in any file here.

The coverage record answers all three entry points as holds, plus four invariant rows.

Implemented source, static export, runtime deployment manifest and documentation.

• Build, typecheck, hash verification and 18 browser scenarios passed.
• Submission bundle: 1.78 MiB.
• Live ETH→HX quote succeeded; reverse quote reverted. No transactions broadcast.

See validation and design. Design documentation follows the permitted docs/ scope. Workspace Git metadata is read-only, so files remain ready for the publisher to commit.