Implemented Company.md (COMD): 1 billion tokens, 18 decimals, minted once to the deployer, with no admin or later minting powers.

Added offline-ready dependencies, deployment documentation, and success/failure tests.

Passed:

• forge build with Solidity 0.8.26
• forge test: 34 tests, including fuzz and invariant checks using the requested seed
• forge fmt --check

The separate protected launch harness was not run locally.

The review is complete. The findings file holds an empty findings list and a full coverage record, and no tracked file was changed.

Result: no defects substantiated in the economic security, invariant, or flow-gap areas for Company.md (COMD).

What I checked

• Source and dependency. CompanyToken.sol is a 17-line contract: a constant and a constructor that mints 1e27 units to msg.sender over unmodified OpenZeppelin ERC20. The five vendored OpenZeppelin files match the repository's SHA256SUMS and are byte-identical to upstream tag v5.4.0, which I fetched and diffed.
• Economic Security guide. No external dependencies, oracles, callbacks, fees, rebases, blocklists or sentinel-address branches exist. Transfer to the zero address and approval of a zero spender revert. Balance delta equals the amount sent on both the push and pull paths, which is what the Uniswap v4 PoolManager's settle logic relies on. The 10/80/10 launch split of 1e27 divides with no dust.
• Invariant guide. The sum of balances equals totalSupply equals 1e27 with no writer to totalSupply after construction. There is no burn, mint, or override of the update hook. The existing 256x64 stateful invariant and the fuzz tests conserve the sum, and I confirmed this with a scratch fuzz over the whole supply range.
• Flow Gap guide. There are no periphery calls, hooks or multi-step flows inside the token, so no seam exists to exploit. The launch flows (factory to distributor, claim, seed, buy, sell) move exactly what they say because no transfer rule exists to exempt.
• Entry points and privilege. The compiled ABI exposes only approve, transfer and transferFrom as writers plus views. The runtime has no DELEGATECALL, CALLCODE or SELFDESTRUCT and no owner or admin path.
• Static analysis leads. Slither reported nothing. Aderyn's large-numeric-literal note on line 10 is style only; the literal is exactly 1e27.

Commands run

forge build                      -> compiled, no warnings
forge test (README seed)         -> 34 passed, 0 failed
forge test --match-path test/scratch/EconomicsScratch.t.sol -> 3 passed (then removed)
sha256sum -c SHA256SUMS; diff -r against upstream v5.4.0 -> identical

Not executed. The protected launch tests under .imd/reads/protected need v4-core, the LaunchLiquidity helper and the launch environment variables, none of which are in this tree, so I did not run the real seed-and-swap harness. The coverage row for the launch flow says so explicitly.

Done. I wrote and committed launch.json as the only change.

What the manifest describes. The accepted tree holds one contract, CompanyToken, whose constructor takes no arguments and mints the full supply once to msg.sender. The manifest records it with an empty constructorArgs list, 18 decimals, and a totalSupply of 10^27 minor units, matching the compiled ABI and the supply constant. There are no application contracts, so the contracts list is empty.

Fixed launch fields. The pool object uses the IMD pair address, fee 12500, tick spacing 60 and the one-to-one provenance price. The economics object is copied verbatim from the job. Notes run 854 characters and only describe the token actually present.

Checks run:

• A JSON check confirmed only the schema's six top-level keys, the verbatim economics, and the supply value.
• forge build compiled cleanly and the constructor ABI shows zero inputs.
• forge test with the verifier's fuzz seed passed all 34 tests.

Git status is clean apart from the new commit containing launch.json. The protected tests need the launch harness and environment variables, so they could not be executed locally.

The review is complete. The findings file is written and valid, the scratch tests are removed, and the only untracked artifact in the tree is the findings file itself.

Result: no defects found in the Math Precision, Boundary and Numerical Gap area. The file .imd-findings.json holds an empty findings list and eight coverage rows, all holds.

What the token is. One contract, src/CompanyToken.sol, inheriting the unmodified OpenZeppelin v5.4.0 ERC-20. Its only custom code is a supply constant and a constructor that mints that constant to the deployer. There is no fee, burn, mint, owner, callback, payable path, external call or bytes decoding anywhere.

What I checked, with evidence:

• Supply constant. The literal evaluates at compile time to exactly 10^27, below 2^90. Both the project tests and my scratch probe assert that value. The aderyn "large numeric literal" lead is style only.
• Transfer arithmetic. OpenZeppelin checks balance before the unchecked subtraction and bounds the unchecked addition by total supply. I probed a max-uint transfer, 1 wei, zero amount from an empty account, and a self-transfer of the whole balance. All behave exactly.
• Allowance arithmetic. Allowance is checked before the unchecked decrement. Max is the infinite sentinel and max minus one stays finite. A balance failure after the allowance is spent reverts atomically, so the allowance is restored.
• Launch split. Ten and eighty percent of 10^27 are 10^26 and 8·10^26 with zero remainder, and the bps multiplication cannot overflow. Transfers deliver the full amount, so the protected swarm, seed and swap flows receive exactly what they send.
• Conservation invariant. With no rounding or division anywhere, the sum of balances equals total supply by construction. The project's stateful invariant suite and my fuzz over arbitrary splits both hold.
• Boundary enumeration. No external call sites, no payable functions, no bytes inputs. The only sentinel branches are OpenZeppelin's zero-address reverts. Native value and unknown selectors revert.
• Dependency integrity. All five vendored OpenZeppelin files match the recorded checksums and are byte-identical to upstream tag v5.4.0 fetched from GitHub.

Test runs. The build succeeds and all 34 project tests pass with the README's fuzz seed. The formatter check passes. My nine scratch probes passed and were deleted afterwards.

Not reached. Nothing in the assigned area was left unexamined. Pool price derivation from the opening cap happens in the deployer, outside this repository, so I did not audit it. With 18 decimals and a 10^27 supply, any plausible cap lands well inside Uniswap v4's sqrt-price range in either currency order.

The review is complete and .imd-findings.json is written. No tracked file was changed, and the scratch test was removed.

Result: no Access Control, Trust Gap or Asymmetry defect in the token. src/CompanyToken.sol is a 17-line fixed-supply wrapper over an unmodified OpenZeppelin v5.4.0 ERC-20, with the vendored files verified against their recorded checksums. The compiled ABI exposes exactly three state-changing functions and no receive or fallback.

What I traced for each entry point and the invariants around them:

• approve: owner is msg.sender through a plain Context with no forwarder. Zero spender reverts. Allowance is isolated per owner and spender pair.
• transfer: sender is msg.sender. Zero recipient and insufficient balance revert atomically. There is no fee, exemption or admin branch, so launch flows arrive whole.
• transferFrom: gated on the allowance of msg.sender for the source account. Infinite allowance is untouched, finite is decremented. A zero source address cannot mint even at value zero.
• Constructor and roles: no arguments, no owner, no minter. The whole supply of 10^27 units goes to the deployer, which is the factory under the launch. The deployer has exactly a holder's rights afterwards.
• Bytecode: no DELEGATECALL, CALLCODE, SELFDESTRUCT or any CALL opcode in the runtime. A 1,000-run fuzz over arbitrary selectors, payloads and callers never changed supply, balances or ETH balance.

The project's own 34 tests pass under the documented seed, including the stateful invariant suite.

One info-level finding is recorded. Seven vendored forge-std files do not match the checksums in lib/forge-std/SHA256SUMS, contradicting the "Unmodified" claim in its VENDORED.md and the provenance statement in the README. Diffing against upstream v1.9.7 shows the differences are whitespace only, consistent with a formatter pass. It is test-only with no runtime impact. The reproduction is the failing sha256sum -c command.

The coverage record has 11 rows: all three listed entry points hold, plus rows for the constructor, the absent receive and fallback, the no-privileged-role and supply-conservation invariants, the protected launch-flow and decimals checks, the Owners floor, and the provenance finding. Nothing in the assigned area was left unreached.

The review is complete and the findings file is written and validated.

Outcome: the production contract has no defects I could substantiate. The only reportable item is an informational provenance defect in the test-only forge-std vendoring.

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

• Traced the constructor and all three state-changing entry points through the inherited OpenZeppelin code with concrete values. The supply is minted once to the constructor's caller, which is the factory under the launch. Transfers deliver exact amounts, self-transfers net zero, the zero address is rejected everywhere, and no path mints, burns, pauses, freezes or seizes.
• Verified all five vendored OpenZeppelin files are byte-identical to the upstream v5.4.0 tag. The ERC20 implementation is unmodified and the token overrides nothing.
• Scanned creation and runtime bytecode independently. No CALL, STATICCALL, CREATE, DELEGATECALL, CALLCODE, SELFDESTRUCT or transient-storage opcodes exist, and the runtime is well under the EIP-170 limit.
• Built and ran the project's 34 tests with the README's seed, plus the invariant run and forge fmt --check. All pass. A scratch test under test/scratch/ exercising nested-constructor deployment, self-spender allowances, router-style pull flows, max-uint inputs and unknown selectors also passes.
• Checked the two static-analysis leads. The aderyn large-literal note is the intended 10^27 supply, confirmed equal by the existing tests. Slither reported nothing.

The one finding (info): lib/forge-std/VENDORED.md claims the library is unmodified from v1.9.7 and the README says its checksums verify, but sha256sum -c SHA256SUMS fails for 7 of 30 files. I downloaded the upstream archive and diffed them. Every difference is a whitespace-only reflow of function signatures, so test behaviour is unchanged. Repairing it needs a write budget that includes lib/, which this task does not have.

Coverage: all three listed entry points are marked holds, with six additional rows for the constructor, supply conservation, launch-flow exactness, bytecode restrictions, and both vendored libraries. The unverified items outside my reach are launch-side: the manifest, pool economics and the chain id named in the README are not in this tree and could not be checked.

Added 17 unit/fuzz tests and expanded invariants to cover rejected calls, allowance transitions, and independent balance accounting.

forge build and forge test pass offline with the supplied seed: 9,000 fuzz cases and 16,384 invariant calls.

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

The review is complete and .imd-findings.json holds the result.

Outcome: the token itself is clean. CompanyToken is a 17-line wrapper over the unmodified OpenZeppelin v5.4.0 ERC-20, with a no-argument constructor that mints the full supply to the deployer. I verified the five vendored OpenZeppelin files byte for byte against upstream, ran the project's 51 tests (all pass, with the README's seed), and ran my own launch-floor simulation: CREATE2 deployment from a factory, exact factory-to-distributor-to-claimant and pool-to-trader flows, allowance semantics, 14 admin and mint selectors reverting, native value rejected, no forbidden opcodes, and sizes well under the creation and runtime limits. All three entry points are recorded as holds, with three extra invariant rows.

Findings kept, both info:

• Vendored forge-std provenance mismatch. The two specialist reports were the same root cause and are merged into one finding. I reproduced it: 7 of 30 files fail sha256sum -c, and a diff against the upstream v1.9.7 archive (whose hash matches the one recorded) shows whitespace-only reformatting. Test-only, no token impact.
• README contradicts the tree. Line 28 says the repository does not supply a launch.json, but one is committed. The manifest itself agrees with the code and ABI.

Dropped: the aderyn large-numeric-literal line is a style note on a compile-time constant and not a defect. Slither reported nothing. No critical or high finding exists, so no proof file was attached, and the scratch test directory was removed.