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

Dependencies are vendored for offline builds. Deployment assumptions and operational responsibilities are documented in README.md.

Verified with Solidity 0.8.26:

• forge build passed.
• All 28 tests passed, including 4,000 fuzz cases using the supplied seed.
• forge fmt --check passed.

I found no math defects in COMD (Company.md). .imd-findings.json holds an empty findings list and a coverage row for each of the three entry points, all holds. It parses as valid JSON, and I changed no other files.

What the code is: src/CompanyToken.sol is a plain OpenZeppelin v5.0.2 ERC-20. The constructor mints INITIAL_SUPPLY = 1_000_000_000 * 10**18 to the deployer, and nothing else is added: no fees, no burning, no further minting, no admin roles. I downloaded the five OpenZeppelin files it imports from the official v5.0.2 tag, and they match the copies in lib/ exactly.

Precision, boundary and overflow checks:

• Supply: it is exactly 1e27, far below the uint256 limit (about 1.2e77). The analyser's "large numeric literal" warning only concerns how the number is written; the value is correct. Supply can never grow, because minting happens only in the constructor.
• transfer / transferFrom: the balance check comes before the subtraction, which skips Solidity's overflow checks. The addition to the recipient's balance also skips those checks, but it can't overflow because no balance can exceed the fixed 1e27 supply. Amounts of 0, 1, a whole balance and the whole supply all behave correctly.
• Allowances: an allowance is checked before it is reduced. The maximum value means "unlimited" and is never reduced, and a zero-amount transferFrom needs no allowance.
• approve: it stores the value as given and does no arithmetic.
• Launch flows: there is no division or rounding anywhere, so the 10% swarm share, the 88% pool seed and the remainder all arrive exactly. decimals() is 18, as the manifest requires.

The project's 28 existing tests pass. I didn't write a proof test, since there was nothing to reproduce. One point is outside the math area: the usual ERC-20 risk when an allowance is changed from one non-zero value to another is behaviour the standard defines, not a defect in this code, so I didn't report it.

The review is complete. The findings file at .imd-findings.json holds an empty findings list and seven coverage rows, and the working tree is unchanged apart from that file.

Outcome: no defects in the permissions area. The token is a thin subclass of OpenZeppelin's ERC20 with a constructor that mints the whole supply once to the deployer. There is nothing to escalate, no guard to bypass, and no asymmetric branch to exploit.

What I checked, following the Access Control, Trust Gap and Asymmetry guides:

• Permission map. The compiled ABI exposes exactly three state-changing functions: approve, transfer and transferFrom. There are no roles, modifiers, initializers, owner slots, mint or burn entry points, receive or fallback. Unknown selectors and ETH both revert.
• Vendored library integrity. I downloaded the pinned OpenZeppelin v5.0.2 release and diffed every vendored file. All five are byte-identical to upstream, so no hidden hook or backdoor exists in the inherited code.
• Asymmetry. transfer and transferFrom share the same internal path, so there is no fee, exemption or branch that treats one caller class differently. Zero-address checks and allowance spending behave as the ERC-20 standard and the README describe.
• Trust gap. The deployer, which will be the launch factory, keeps no power after it forwards the supply. A scratch test confirmed it cannot pull tokens back or impersonate holders, and a stranger approving themself gains nothing.
• Supply and launch flows. Supply is fixed at one billion tokens with 18 decimals and cannot grow. Every transfer moves the exact amount, so the distributor, pool seed and remainder flows arrive whole. The runtime contains no DELEGATECALL, CALLCODE or SELFDESTRUCT.

The project's 28 tests pass, the formatter check passes, and the Slither and Aderyn leads were only a large-literal style note. The standard ERC-20 approve ordering race is recorded in coverage as a trust note rather than a finding, since it is inherent to the standard and already documented in the README. The protected launch harness could not be run locally because its Uniswap v4 dependencies are not in this tree, so the actual pool seed and swap remain for the launch verifier.

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

forge build succeeded. All 28 tests passed with the supplied fuzz seed. Only launch.json is changed for submission.

Added 10 unit/fuzz tests and 3 stateful invariants covering failure rollback, allowance isolation, approval revocation, edge amounts, and supply conservation.

Validation passed: forge build, seeded forge test, and formatting checks. Invariants exercised 16,384 random handler calls.

Only added files under test/. No implementation defects found.

The review is complete and the findings file is written. Nothing further is needed from the tree.

Outcome: no defects found. The file .imd-findings.json holds an empty findings list and nine coverage rows, one for each of the three state-changing entry points plus the constructor, the fixed-supply invariant, the opcode invariant, the vendored periphery, the launch flows and the manifest.

What I traced in my area:

• Execution Trace. Each of approve, transfer and transferFrom was followed through the OpenZeppelin v5 internals with concrete values. Zero recipient, zero spender, zero from, overdraw and over-allowance all revert with the expected ERC-6093 error and leave no partial state. A finite allowance is checked before it is decremented, and any later revert rolls the decrement back. The unlimited allowance is never decremented.
• Periphery. The five vendored OpenZeppelin files were read line by line and match the upstream v5.0.x text, with no edits to the update, approve or spend-allowance paths. A byte-for-byte diff against upstream was not possible because the network proxy refused the fetch, so that row says so.
• First Principles. The constructor takes no arguments and mints one billion tokens with 18 decimals once to the deploying address. A scratch test deployed the raw creation code through a CREATE2 factory probe, confirmed the factory held the whole supply, moved the 10, 88 and 2 percent shares whole, and confirmed that stray appended constructor words change nothing. Calls with value or unknown selectors revert. The compiled runtime has no DELEGATECALL, CALLCODE, SELFDESTRUCT, CALL or CREATE opcodes.

Checks run: forge build, the project's 28 tests with the README's fuzz seed, forge fmt in check mode, the scratch deployment test, and an opcode scan of the compiled runtime. All passed. The scratch test was removed afterwards and no repository file was changed.

Not reached: the protected Uniswap v4 seed-and-swap harness could not be executed here because its v4-core and launch helper sources are not in this tree. Since the token has no transfer rules at all, no code path exists that could make the seed or a swap behave differently from a plain transfer.

The review is complete. The findings file is valid JSON, and no tracked file changed. The scratch test lives in the gitignored test/scratch/ directory.

Outcome: no defects found. The economics review of the Company.md (COMD) token found nothing to report, and the findings file holds an empty list with ten coverage rows.

What the token is. CompanyToken is the stock OpenZeppelin v5.0.2 ERC20 with one constructor that mints 1,000,000,000 tokens at 18 decimals to msg.sender. It has no owner, no fee, no hooks, no external calls, and no constructor arguments. The compiled ABI exposes only approve, transfer and transferFrom as state-changing functions.

What I verified.

• The vendored OpenZeppelin files are byte-identical to the upstream v5.0.2 tarball from GitHub, so no modified library logic hides under the token.
• A scratch invariant suite ran random transfer, approve and transferFrom calls among seven actors for 256 runs and 128,000 calls with zero reverts. Total supply stayed constant and balances always summed to supply.
• A random-selector sweep of 1,000 runs confirmed no selector outside the three entry points changes supply. Boundary amounts of 1 wei and the whole supply moved exactly.
• The launch split of ten percent, eighty-eight percent and the remainder lands whole in any order, so the swarm share, pool seed and requester remainder cannot arrive short.
• The existing 28-test suite passes with the pinned fuzz seed.

Coverage. All three entry points are marked holds, plus rows for the supply and conservation invariants, the constructor mint, launch flows, external dependencies, privileged calls and opcodes. The Uniswap v4 protected harness itself was not executed because v4-core is not vendored. The token surface it depends on is plain ERC-20, so I recorded that flow as holds with that caveat stated.

Not reported. The ERC-20 approve ordering race and the missing Approval event on transferFrom are standard OpenZeppelin v5 semantics, documented in the README. The aderyn large-numeric-literal line is a style lint, not a defect.

The review is complete. The Company.md token has no defects, and .imd-findings.json records an empty findings list with a coverage row for all three entry points plus four invariants. Only the untracked findings file was written; the working tree is otherwise clean.

What I verified

• The contract is a stock OpenZeppelin v5.0.2 ERC20 with a parameterless constructor that mints the whole supply to msg.sender once. The minted value equals the manifest's totalSupply exactly, and decimals, name and symbol match launch.json.
• All five vendored OpenZeppelin files are byte-identical to the upstream v5.0.2 release archive, so the inherited transfer, approve and transferFrom logic is the audited upstream code.
• The three entry points behave as stock ERC-20: zero-address and insufficient-balance reverts, finite allowance decremented, infinite allowance left alone, and the deployer has no power to pull a holder's balance.
• A CREATE2 deployment from a stand-in factory held the entire supply, and the launch flows of factory to distributor to claimant arrived whole with the supply unchanged.
• Runtime code contains no DELEGATECALL, CALLCODE or SELFDESTRUCT. Creation and runtime sizes are far under the protocol limits. The ABI exposes no owner, pause, blocklist, mint or burn.
• The project's own 39 unit, property and invariant tests pass under solc 0.8.26.

Specialist and tool leads

All five specialist reports had no findings, so there was nothing to reproduce or merge. Aderyn's low-severity large-numeric-literal lead is a style note only. The literal is correctly digit-separated and evaluates to the exact manifest supply, so it was not kept as a finding.