Done. The project is committed and all checks pass.

What was delivered

• src/LaunchToken.sol: the launch token, contract name LaunchToken, token name "bmc illuminati", symbol BMC. It is a plain OpenZeppelin v5 ERC-20 with 18 decimals and 10^27 minor units minted once to the deployer. It has no owner, mint, pause, blocklist, fee, or upgrade path, and no constructor arguments.
• test/LaunchToken.t.sol: 18 tests covering metadata, supply, a stand-in factory holding everything after construction, transfers and allowances, failure paths (insufficient balance, zero receiver, missing or exceeded allowance), rejection of ether and every common privileged selector, and an opcode scan for DELEGATECALL, CALLCODE and SELFDESTRUCT.
• docs/abi/LaunchToken.json: the ABI export, verified identical to the build output.
• foundry.toml and remappings.txt: solc pinned to 0.8.26, bytecode hash none, optimizer on, no ffi or filesystem permissions.
• lib/: forge-std v1.9.7 and the five OpenZeppelin v5.1.0 files the token needs, vendored as plain files with licences. No submodules.
• README.md: assumptions, deployment parameters for the manifest step, after-launch responsibilities, and trust notes.

Check results

One thing to flag. The brief asks for a custom Uniswap v4 hook that sends 1% of the IMD side of every swap to the address ending in 441B0. This launch cannot run it, so I built a token-only launch and did not write that hook. The pool's only hook is the factory's PoolInitializationGuard, the launch rules forbid fee logic in application contracts, and a hook deployed through the factory would lack the mined address bits v4 requires. The pool's built-in 1.25% launch fee already sends 1% of every trade to the wallet that paid for the launch, which matches the brief's intent if that wallet is the named address. The README states this assumption for the reviewer and notes that the website copy the brief specifies must be reworded at the frontend stage.

No launch.json was written. The manifest step should list LaunchToken with an empty contracts array and the pool values from the README.

The review is complete and written to .imd-findings.json. The working tree is unchanged apart from that file, and my scratch test copy is removed.

Outcome: LaunchToken itself has no defects in the Access Control, Trust Gap or Asymmetry areas. It is an unmodified OpenZeppelin v5.1.0 ERC-20 with no roles, no admin selectors, no constructor arguments, and a single mint of the full supply to the deployer. One low-severity policy finding is reported.

What I verified:

• Permission model. No owner, initializer, minter, pauser or upgrade path exists. Fourteen admin selectors revert and leave supply untouched. The runtime has no DELEGATECALL, CALLCODE or SELFDESTRUCT and no receive or fallback.
• Paired-function symmetry. The transfer and transferFrom paths apply the same balance and zero-address checks, and allowance is spent before funds move. No privileged variant of any user function exists.
• Dependency integrity. All five vendored OpenZeppelin files are byte-identical to the upstream v5.1.0 release. The exported ABI equals the build's output. There are no submodules.
• Tests. The 18 project tests pass. The protected token floor, run against the built creation code with the 10^27 policy supply and 18 decimals, passes all 7 of its checks.

The one finding, at low severity, is a trust gap between the approved brief and the delivered tree. The brief requires a hook that sends 1% of every IMD-side swap to a fixed address set as an immutable constructor argument. The tree contains no hook and cannot under the launch rules. The substitute, the pool's launch fee, pays 1% to whichever wallet paid for the launch and 0.25% to IMD, claimable rather than pushed. If the paying wallet is not the brief's named recipient, that recipient receives nothing. The finding names the evidence services need before admission: that the paying wallet equals the named recipient, that the requester accepts the claimable fee model, and that the policy row carries the 88% pool share the source and README publish as fact. No code change in the tree can resolve it.

Coverage covers all three listed entry points as holds, plus the constructor, three invariants, the fee-recipient constraint as the finding, and the manifest as unreached because no launch.json exists yet.

Review complete. The findings file is written and the working tree is unchanged apart from the gitignored output.

Outcome: no code defects in my area. The token is an unmodified OpenZeppelin v5.1.0 ERC-20 with a single constructor mint, and every economic, invariant and flow-gap check held.

What I verified:

• Vendored library integrity. All five OpenZeppelin files are byte-identical to upstream v5.1.0, so the ERC-20 logic is exactly the audited library code.
• Conservation invariant. A scratch fuzz harness driving transfer, approve and transferFrom among five actors kept the sum of balances equal to the fixed supply across all runs, and total supply never moved.
• Deployment flow. The constructor makes no external call and mints everything to the deployer, which matches the factory's supply check and the protected floor tests.
• ABI export. The committed ABI file is identical to the current build output, and the constructor has no inputs.
• Entry points. All three listed entry points are marked holds, with seven extra rows for invariants, the ABI, the manifest rules and the static-analysis lead.

Two findings recorded, neither blocking:

1. Low: the approved brief's fee economics are not enforced anywhere in the tree. The brief requires a hook sending 1% of the IMD side as IMD to a fixed address. The delivered launch instead routes the pool's 1% share to whichever wallet paid, in both pool currencies, pull-based, plus 0.25% to IMD. The README documents this as a rule-driven deviation, but whether the brief's recipient receives anything depends on the paying wallet's identity, which nothing in the tree or its inputs establishes. The judge needs the launch record's payer wallet and explicit requester acceptance of the substituted model.
2. Info: the README's runtime size is wrong. It reports the hex string length rather than the byte count. The EIP-170 conclusion still holds.

Not covered: the remaining nine Pashov specialties beyond my three guides, and any check that needs the live launch record, such as who paid for the launch.

The review is complete. The findings file is in place, the scratch directory is gone, and the working tree is clean apart from the excluded findings file and build caches.

Outcome: no code defect in the control flow of the launch token. The one item I recorded is informational: a policy conflict between the approved brief and the launch rules that only the launch record can resolve.

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

• Traced all three state-changing entry points through OpenZeppelin's _approve, _spendAllowance, _transfer and _update. Zero-address guards, balance and allowance checks, residual and infinite allowances, self-transfers, and the from-equals-to path all behave as a plain ERC-20 should. A fuzzed supply-conservation probe over both transfer paths passed.
• Verified the periphery: the five vendored OpenZeppelin files match upstream v5.1.0 line for line, with no override of _msgSender or _update. The exported ABI in docs/abi is identical to the compiled one.
• Confirmed the constructor is the only mint, takes no arguments, makes no external calls, and that both protected floor suites pass against the real creation code with the policy supply. The aderyn numeric-literal lead is a style note only.

The informational finding: the brief requires 1% of each swap's IMD side sent to a fixed address, fixed in a constructor. No contract in the tree does this, and the launch rules forbid a custom hook, which the README explains. The 1% launch-fee share instead goes to the wallet that paid. The README itself flags that this only matches the brief if that wallet is the brief's address, and nothing in the tree confirms it. The failing state is any launch record whose paying wallet differs. The evidence needed is the launch's paying wallet or named owner, which is a service record rather than source.

Coverage record: nine rows, all three listed entry points marked holds, plus invariant, periphery, ABI and static-analysis rows. The manifest row is unreached because no launch.json exists yet.

The review is complete and .imd-findings.json is written and validated. No files in the tree were changed; the scratch tests I used were removed.

Result: no arithmetic, boundary or numerical-gap defect in the Solidity. The only contract is LaunchToken, a plain OpenZeppelin v5.1.0 ERC-20 minting 10^27 units once to its deployer. What I verified in my area:

• Supply constant 1_000_000_000 ether equals exactly 10^27, fits comfortably in uint256, and is minted in a single checked addition with no external call. The aderyn large-literal lead is this constant and is not a defect.
• Transfer and allowance arithmetic is the unmodified OZ _update and _spendAllowance. The unchecked subtractions sit behind explicit checks, the unchecked addition cannot exceed the fixed supply, and the infinite-allowance path is standard. I traced 0, 1 wei, whole balance, balance+1, exact allowance, allowance+1 and zero-address inputs for all three entry points.
• Vendored libraries are byte-identical to OpenZeppelin tag v5.1.0 and forge-std tag v1.9.7. The committed ABI equals the build output.
• Both protected floor suites pass against the built creation code with supply 10^27 and decimals 18. The fuzz test holds under two extra seeds at 2,000 runs. Slither with low and medium included reports nothing.
• Paired currency at the IMD address reports symbol IMD and 18 decimals on mainnet, so there is no decimal mismatch.

Three findings were recorded, none against contract code:

1. Low. The brief's single hook rule, 1% of the IMD side pushed to the fixed address on every swap, is not delivered. The README explains the platform reasons and substitutes the 1.25% claimable launch fee, which matches the brief only if the wallet that paid is that same address. Nothing in the tree evidences who paid, so I flagged the needed evidence rather than a code change.
2. Info. The README's manifest value for pool.initialPrice is 2^96, which is a price of 1 IMD per BMC and implies a 1,000,000,000 IMD opening cap against the brief's 2,500 IMD. The deployer derives the real price from policy, so this matters only if the manifest step copies it or a legacy policy honours it.
3. Info. The README states a 3,481-byte runtime; the pinned build produces 1,739 bytes.

The coverage record has 13 rows: all three listed entry points hold, the constructor, supply invariant, library integrity, ABI, paired currency and static-analysis leads hold, and launch.json is marked unreached because the manifest step has not yet produced one.