Implemented Company.MD (COMD): 1 billion tokens, 18 decimals, minted once to the deployer.

Included vendored dependencies, success/failure tests, fuzz and invariant tests, and deployment documentation in README.md.

forge build, forge test, and forge fmt --check pass with Solidity 0.8.26. A clean offline run with an empty environment also passed and reproduced identical bytecode.

I found no defects in the permissions review of CompanyToken (COMD), so .imd-findings.json holds an empty findings list and a full coverage record.

What the code is. src/CompanyToken.sol is a plain ERC-20 built on the vendored OpenZeppelin v5.1.0 code. Its only additions are the INITIAL_SUPPLY constant (10^27) and a constructor that mints all of it to msg.sender. All six vendored files match SHA256SUMS, so the inherited code is unmodified. forge test passed: 29 tests, including the invariant suite.

Access Control. After deployment there is no owner, role, modifier, initializer, mint, burn, pause, blacklist, upgrade path or delegatecall. The compiled method list contains only the standard ERC-20 functions plus INITIAL_SUPPLY(). The factory ends up holding the supply and nothing else. _mint is internal and only the constructor calls it, so the supply cannot grow. A stranger, including the factory, cannot move a holder's tokens through transferFrom: the allowance is checked and reduced before the transfer runs.

Asymmetry. I compared the matching pairs (transfer against transferFrom, approve against spending an allowance) and found no write that one side makes and the other misses. Every sender and recipient goes through the same code path, with no fee, exemption list or special-cased address. The one special case is that an allowance of type(uint256).max is treated as unlimited, which is standard. Each written value has a matching reader.

Trust Gap. None of the four seams can occur here, because there is no privileged actor, no economic formula, and no setter that could redirect value already in transit.

Coverage rows:

• approve, transfer and transferFrom are each marked holds.
• I added three invariant rows, also holds:
  • no privileged role exists after deployment;
  • the supply cannot grow;
  • the launch transfers (factory to distributor to claimant, and in and out of the pool manager) move exact amounts.

Leads I set aside:

• The static-analysis "large numeric literal" warning is a style note on 1_000_000_000 * 10 ** 18, not a defect.
• The well-known ERC-20 approve front-running race is standard behaviour.

I didn't check the launch manifest, because there is none yet. I changed no tracked files. git status now shows several untracked dotfiles and folders in the repository root (.bashrc, .claude/, .vscode and others) that I didn't create. They look like environment artifacts, but you should remove them before anything is uploaded.

Created launch.json matching CompanyToken, its constructor, exact supply, and required pool/economics values.

Validation passed: manifest checks, forge build, and forge test—29 tests passed. Only launch.json changed outside permitted scratch files.

The review is complete. The findings file at .imd-findings.json holds an empty findings list and ten coverage rows. The scratch test directory has been removed and the working tree is otherwise untouched.

Outcome: no defects found in the economics area. The token is a 16-line fixed-supply ERC-20 over an unmodified OpenZeppelin v5.1.0 base. Nothing in it can leak, tax, freeze or grow value.

What I verified:

• Vendored dependency integrity. I fetched the ERC20 import closure from upstream OpenZeppelin at the pinned v5.1.0 commit and diffed it. Every file is byte-identical, so the inherited transfer and approval logic is the audited upstream code.
• Three entry points. approve, transfer and transferFrom are the unmodified OpenZeppelin implementations. I traced each through its guards, state changes and revert paths. All three are marked holds.
• Conservation and supply. The only mint is in the constructor, the compiled ABI exposes no mint, burn or admin selector, and transfers to the zero address revert. The supply is fixed at 1e27 forever. The project's own invariant suite and my scratch probe both confirm the sum of balances equals total supply.
• Launch flows. A scratch test simulated the factory deploying through CREATE2, the 10 percent swarm move, an allowance-based pool-manager pull for the 80 percent seed, the remainder forward, a distributor claim, and a buy and sell through the manager. Every leg moved exactly the stated amount and returned true.
• Privileged powers. None exist. Every admin-style selector reverts from the deployer and from strangers, and the deployer cannot pull a holder's balance without allowance.
• Static-analysis lead. The aderyn large-literal note is style only. The constant is a compile-time 1e27 that matches the manifest supply.

Two residual notes are recorded as coverage rows rather than findings. The standard ERC-20 approve front-running window is inherent to the token type the job requested and is documented in the README. Tokens sent to the token contract itself are stranded with no recovery path, which the README also states as intended.

The review is complete. The findings file is written, the scratch test is removed, and the working tree is clean apart from the gitignored output.

Result: no defects found in the math, boundary, or numerical-gap area. The findings list in .imd-findings.json is empty, with ten coverage rows.

What the token is. A single file, src/CompanyToken.sol, inheriting the vendored OpenZeppelin v5.1.0 ERC-20 unchanged and adding only a supply constant and a constructor mint to the deployer. The vendored library matches its recorded SHA256 sums.

Math Precision. There is no division, scaling, fee, cast, or shift anywhere in the token. The supply literal evaluates to exactly 10^27 and agrees with the 18 decimals, so the aderyn large-literal lead is not a defect. The constructor's checked addition starts from zero and cannot overflow. The three unchecked blocks are all in the OpenZeppelin _update and _spendAllowance functions, and each sits behind the revert that bounds it.

Boundary. The token makes no external calls, has no payable function, no receive or fallback, and decodes no bytes. ETH and unknown selectors revert. The only sentinel branches are the zero-address checks. I confirmed that transferFrom with a zero from cannot reach the mint branch for either a zero or nonzero amount, because the allowance of the zero address can never be set and spending it reverts first.

Numerical Gap. The sum of balances equals the total supply exactly under any sequence of moves, confirmed by the tree's own invariant run and a scratch fuzz over arbitrary splits. The launch's 10/80/10 split of 10^27 divides with no residue, so no launch flow arrives short on the token side.

Verification run. The existing suite of 29 tests passes, formatting is clean, and nine scratch edge probes passed before I deleted them.

Trust assumption recorded, not a defect. Tokens sent to the token's own address are stranded. The README documents this as intended for an ownerless token, so it is noted in coverage rather than reported.

Added 18 boundary and failure-path tests, and expanded invariants covering supply, balances, allowances, and metadata across 24,576 random calls.

forge build and forge test pass: 47 tests reported, zero failures.

No implementation defects found. All changes are under test/.

The findings file is in place and valid, and the working tree is otherwise untouched. The review is complete.

Review complete: Company.MD (COMD) control flow

Result: the token is clean in my area. One low-severity periphery finding, written to .imd-findings.json with 11 coverage rows.

What the contract is. CompanyToken is 16 lines: it inherits OpenZeppelin v5.1.0 ERC20, sets name and symbol, and mints a constant to the deployer. There is no owner, no mint or burn entry point, no hooks, no external calls. The compiled ABI has exactly 10 functions. Seven are views. The other three are the listed entry points.

Execution Trace pass. I traced approve, transfer and transferFrom from selector to final storage write through the vendored _approve, _transfer, _spendAllowance and _update. Every sentinel path reverts before any write. The from == address(0) mint branch of _update is unreachable from outside, since transfer uses msg.sender and transferFrom reverts in _spendAllowance first. Allowance debit and balance move are one atomic step, so a revert on either restores both. Finite allowances are decremented exactly, type(uint256).max is sticky, and max - 1 is treated as finite. Launch legs (factory to distributor, pool manager and remainder; distributor to claimant; pool manager in and out) arrive to the wei.

First Principles pass. The supply constant evaluates to exactly 10^27, which is the manifest figure in 18-decimal minor units. One Transfer(0, deployer) event. Decimals is the OpenZeppelin default of 18. Supply cannot grow after the constructor, confirmed by walking the only two supply writes and by probing 12 admin, mint, burn, permit and initializer selectors from both deployer and stranger. Conservation held under a fuzzed transfer/transferFrom probe and the project's own stateful invariant suite.

Periphery pass. This is where the one finding lives.

• OpenZeppelin closure holds. All 6 vendored files match the shipped SHA256SUMS and are byte-identical to upstream commit 69c8def5. I fetched upstream and compared directly.
• forge-std does not match its provenance. The note says the sources are unmodified and the checksums record upstream contents. Running the shipped check fails on 7 of 28 files, including Vm.sol and StdAssertions.sol, which sit in every test's import closure. The recorded hashes are the correct upstream hashes. The files were reformatted after hashing. Whitespace-normalized contents are identical, so this is forge fmt output, not tampering. It is low severity because the deployed token's creation and runtime bytecode do not depend on forge-std at all, and I verified that independently.
• Bytecode. An opcode walk of both creation and runtime bytecode from the compiled artifact finds no DELEGATECALL, CALLCODE, SELFDESTRUCT, CREATE, CALL or STATICCALL. No immutables, no link references. Metadata confirms solc 0.8.26, Cancun, optimizer at 200 runs, bytecode_hash = none, matching foundry.toml.

The aderyn lead at src/CompanyToken.sol:10 is the supply constant. It is a compile-time literal equal to the intended supply. Not a defect.

What I could not reach. The protected harness imports src/LaunchLiquidity.sol, src/PoolInitializationGuard.sol, src/HookFlags.sol and v4-core, none of which are in this tree, so I could not run the actual Uniswap v4 seed and swap. I verified every token-side leg that harness exercises directly instead, and recorded the row as unreached.

Housekeeping. The scratch probe tests and the temporary upstream fetch directories are removed. git status shows a clean tree. The findings file is present and parses, and is hidden from git status only because .git/info/exclude lists it.

The review is complete. The findings file is in place and the working tree has no stray files.

Outcome: one low finding kept, nothing else found. The token is sound.

What I checked

• CompanyToken is a bare subclass of the vendored OpenZeppelin v5.1.0 ERC20 with a constant supply and a no-argument constructor that mints the full supply to the deployer. All six vendored OpenZeppelin files are byte-identical to the pinned upstream commit, so the three entry points are unmodified upstream code. I traced approve, transfer and transferFrom through OpenZeppelin's checks, state changes and revert paths and marked each as holds.
• The manifest matches the code: empty constructor arguments, supply string equal to the constructor mint, 18 decimals, lowercase addresses, schema keys only.
• Creation and runtime bytecode are far below the protocol limits, with no linked libraries and no forbidden opcodes, so the factory's CREATE2 deployment works.
• The build compiles and all 47 existing tests pass.
• The aderyn large-numeric-literal lead is a style note on a compile-time constant and was dropped.

Specialist finding kept, at low severity

The audit_flow finding reproduces. Running the shipped checksum file under lib/forge-std fails on 7 of 28 files, while the provenance note on line 9 of lib/forge-std/VENDORED.md claims the sources are unmodified. I re-fetched the 7 files from the pinned upstream commit. With whitespace stripped, each is identical to upstream, so the change is formatter re-wrapping only. forge-std is compiled only into tests and does not affect the token's bytecode, which is why this stays low. The fix is to restore upstream bytes or regenerate the checksums and reword the note.

Output

.imd-findings.json holds the finding and 7 coverage rows covering the three listed entry points plus the constructor, deployability, manifest consistency and the static-analysis lead. The file is excluded by the repository's git info exclude, which is why git status reports it as ignored rather than untracked. No proof file was needed since the only finding is low severity.