Implemented CompanyToken: Company.md (COMD), 18 decimals, with 1,000,000,000 tokens minted once to the deployer.

Validation passed:

• forge build with Solidity 0.8.26
• forge test with the required fuzz seed
• forge fmt --check
• Clean offline build and tests with identical bytecode

Dependencies are vendored. Assumptions, deployment parameters, and operational responsibilities are documented in README.md.

I found no defects in the permissions area of CompanyToken, so .imd-findings.json holds an empty findings list and a full coverage record. No other files were changed.

What the token is: src/CompanyToken.sol is OpenZeppelin v5.4.0's standard ERC20 with nothing overridden. Its constructor takes no arguments and mints 1_000_000_000 * 10**18 once to msg.sender, which is the factory.

Coverage, all three entry points marked holds:

• approve: an account can only set its own allowances, and a zero spender is rejected. Nothing lets anyone set an allowance for someone else.
• transfer: it only moves the caller's own balance. There is no fee, pause, blacklist or exemption list, so the transfers to the factory, the distributor and the pool manager arrive exact.
• transferFrom: the allowance is checked and spent before the balance moves, and the call reverts if the allowance is too small. Nothing bypasses it, so nobody can move a holder's tokens without that holder's approval.

The three guides:

• Access control: the token has no owner, roles, mint, burn, pause or upgrade function.
• Trust gap: after deployment no address holds any power over the token.
• Asymmetry: every address is treated the same way.

The supply is fixed, because minting and burning can't be reached after the constructor runs.

Checks run: the vendored OpenZeppelin files match their recorded SHA-256 hashes, so the library code is unmodified. The project's own 35 tests pass. The static-analysis lead (a large number at src/CompanyToken.sol:11) is a style note; the value equals exactly 1e27, so it isn't a defect.

Outside my area: 7 of the vendored forge-std test-helper files don't match their hashes in DEPENDENCIES.sha256, although DEPENDENCIES.md says the vendored files are unmodified. This doesn't affect the deployed token. I didn't report it because it's outside my area and lib/ can't be changed by this task.

The deliverable is complete: launch.json is written, verified, and committed. No other file changed.

What the manifest describes. The accepted tree contains one contract, CompanyToken in src/CompanyToken.sol. Its constructor takes no arguments and mints the full supply once to msg.sender, so the manifest lists an empty constructorArgs and a totalSupply of 10^27 minor units. There are no application contracts, so the contracts array is empty. The pool block and the economics block are copied exactly as the launch reference gives them, with the IMD pair address, fee 12500, tick spacing 60 and the one-to-one provenance price. Notes run just over a thousand characters and describe only what is actually in the tree.

Checks run.

• A JSON check confirmed kind, the exact key set, the supply string, the verbatim economics object and the notes length.
• forge build compiled cleanly with Solidity 0.8.26.
• forge test with the verifier's fuzz seed passed all 35 tests across both suites.
• forge inspect confirmed the constructor ABI is constructor() with no parameters, matching the manifest.
• git status showed launch.json as the only change, now committed as 2611318.

The protected tests themselves cannot run here because they import the network's factory harness, which lives outside this tree. They will run during independent verification with the manifest's values resolved into environment variables.

Review complete. The findings file is written and valid, scratch files are removed, and git status --porcelain shows nothing outside the allowed output.

Outcome: the token has no economic, invariant, or flow-gap defect. One low-severity provenance finding is recorded.

What I checked

• The contract is a 16-line wrapper over OpenZeppelin v5.4.0 ERC20 that mints exactly 10^27 base units to the deployer in the constructor. I confirmed the six vendored OpenZeppelin files are byte-identical to the v5.4.0 release archive, so the transfer, approval and allowance semantics are the stock ones.
• Economic Security guide: no fee, rebase, pause, blacklist, callback or mint path exists. Sentinel-address calls revert rather than burning or silently succeeding. The whole supply fits under the Uniswap v4 int128 delta bound.
• Invariant guide: total supply is fixed after construction and the sum of balances conserves it. The project's 128x64 stateful invariant run and the privileged-selector probes pass with the README's seed.
• Flow Gap guide: I ran a scratch test that moves the 10% swarm share, seeds 80% to a manager both by direct push and allowance pull, forwards the remainder, performs integer-split claims for 3 wallets and 7 seats, and round-trips a trader buy and sell. Every leg arrives exact.
• All three listed entry points are marked holds with reasons, plus rows for the invariants, native ETH rejection and the not-yet-written manifest.

Finding (low): the documented check sha256sum --check DEPENDENCIES.sha256 fails on the clean checkout. Seven forge-std files differ from the recorded hashes and from upstream v1.9.7, but only in whitespace, consistent with a formatter pass over lib/. This is test-only code and does not affect the deployed token. The fix is either to regenerate the hash list and note the reformat, or to restore the seven files and exclude lib/ from formatting.

Not reached: launch.json does not exist yet, so its contents could not be reviewed. The README's stated manifest parameters are consistent with the source and ABI.

Review complete. Findings are in .imd-findings.json and no tracked file was changed. The scratch tests live under test/scratch/, which git ignores.

Outcome: the token is a 16-line wrapper over unmodified OpenZeppelin v5.4.0 ERC20 and holds across my three guides. Every entry point was traced and came back clean. Two items are recorded, neither affecting the deployed token.

Findings written

• Low, dependency provenance. DEPENDENCIES.md tells the reader to verify the vendored libraries with a checksum file, and that check fails on seven forge-std files. I downloaded both upstream archives and confirmed the recorded hashes are the genuine v1.9.7 hashes, while the files in the tree were reformatted by forge fmt. The diff is whitespace only, and every OpenZeppelin file matches v5.4.0 byte for byte. Fix is to restore the seven files or regenerate the checksum file.
• Info, standard ERC-20 behaviour. Anyone can call transferFrom with a zero value and no allowance, emitting a Transfer event from any holder. Balances are unaffected. This is required ERC-20 behaviour and the address-poisoning vector, recorded so the author can mention it in the README. No code change recommended.

Coverage recorded, nine rows. The three listed entry points hold, as do the constructor mint, the no-growth and no-privilege invariant, exact launch flows, and the OpenZeppelin vendoring. The forge-std row points at finding 1. The manifest row holds because launch.json has not been generated yet and the README's parameters are schema-consistent.

What I verified beyond reading

• Build and the full 35-test suite pass with the README's fuzz seed.
• The supply constant evaluates to exactly 10^27, checked with node.
• The compiled ABI exposes only the ERC-20 surface plus the supply constant. The 1753-byte runtime contains no CALL, DELEGATECALL, CALLCODE, CREATE, CREATE2 or SELFDESTRUCT.
• A scratch suite reproduced the CREATE2 mint to an etched factory, the 10/80/10 launch split, atomic allowance restoration on every revert path, the zero-value event, and rejection of ETH and unknown selectors.

Not reached: the protected launch harness itself, since Uniswap v4 core is not vendored here. Plain ERC20 semantics satisfy each of its checks by inspection. Static-analysis lead from aderyn about the large numeric literal was checked and is not a defect.

Review complete. The findings file is written and the tree is clean apart from it.

Result: no math, boundary or numerical-gap defect in the token. The contract is the unmodified OpenZeppelin v5.4.0 ERC20 plus one constant and one constructor mint, so there is no division, rounding, scale conversion, downcast, external call, payable path or sentinel branch to fail. I checked every failure mode in the three assigned guides against the actual arithmetic and verified the edges with a scratch Foundry suite before deleting it.

What was verified concretely:

• Supply constant evaluates to exactly 10^27 at compile time. The aderyn "large numeric literal" line is style only. The 10/80/10 launch split divides it without remainder, and it fits in int128, so Uniswap v4 balance deltas cannot truncate it.
• transfer and transferFrom keep the checked guard before each unchecked subtraction. Zero, 1 wei, whole balance, self-transfer, max uint, exact-allowance-to-zero, max allowance, and max-minus-one allowance all behave as the standard says. A fuzzed two-hop transfer conserves the supply.
• approve is a plain store with zero-address guards. No ETH path exists. The existing unit, fuzz and invariant suites all pass.

One info-level note is recorded outside the assigned area. The project's own documented provenance check fails for seven forge-std files:

sha256sum --check DEPENDENCIES.sha256   ->  7 computed checksums did NOT match

I downloaded the upstream v1.9.7 archive and diffed. Every difference is forge fmt line wrapping in test helpers, and all OpenZeppelin files verify, so the token runtime is unaffected. The fix is to regenerate the hash file or restore the files byte for byte.

Coverage rows answer all three entry points as holds, plus four invariant rows. The findings file lists one finding, severity info, with no proof needed.

Added 12 edge/fuzz tests and strengthened invariants covering balances, supply, allowances, and failure rollback.

Offline build and tests pass with the supplied seed: 47 tests passed, including 16,384 invariant calls.

Changes are confined to test/. No implementation defects found.

The review is complete. .imd-findings.json is written at the repository root with two findings and a seven-row coverage record. No repository file was changed, and the scratch test directory was removed.

What I reproduced

• Dependency hash check fails (low, merged). The three specialist reports from audit_economics, audit_flow and audit_math describe one root cause, so they are one finding. Running the documented check from DEPENDENCIES.md fails on exactly seven forge-std files. I downloaded both release archives into a temporary directory. Their archive hashes match what DEPENDENCIES.md records, the recorded per-file hashes are the genuine upstream v1.9.7 values, and the seven vendored files are identical to upstream once whitespace is stripped. All five OpenZeppelin files are byte-identical to upstream v5.4.0, so the deployed token's only dependency is unmodified. Kept at low: provenance only, test helpers only.
• Zero-value transferFrom without allowance (info). The audit_flow finding reproduces with a scratch Foundry test using recorded logs. It is standard ERC-20 and OpenZeppelin behaviour, the README already says zero-value transfers emit, and no code change is needed. Kept as info so the author knows about the address-poisoning vector without reopening the work.

My own pass

The token is a bare OpenZeppelin v5.4.0 ERC20 with a no-argument constructor that mints once. I traced approve, transfer and transferFrom through the unmodified library and found nothing beyond the above. All 47 repository tests, including invariants, pass. Runtime code has no DELEGATECALL, CALLCODE or SELFDESTRUCT. Bytecode sizes are well under the limits, and launch.json is schema-valid with constructor arguments and supply matching the constructor.

What I could not do

The two protected test files import the platform's Uniswap v4 sources and factory helpers, which are not in this tree, so they cannot compile here. I read their assertions instead. A plain fixed-supply ERC20 satisfies every one of them.