Done. The Company.md (COMD) token project is complete and verified at the repository root.

What was built

• src/CompanyToken.sol: contract CompanyToken, a thin wrapper over OpenZeppelin v5.3.0 ERC20. Name Company.md, symbol COMD, 18 decimals. The constructor takes no arguments, makes no external calls, and mints the whole supply of 1,000,000,000 tokens (1000000000000000000000000000 minor units) once to msg.sender. There is no owner, mint, burn, pause, blocklist, fee or upgrade path, so nothing in the protected floor's privileged-call lists has any effect.
• script/DeployCompanyToken.s.sol: reference deploy script with a deploy() function the tests call directly. It reads no environment variables.
• test/CompanyToken.t.sol and test/DeployCompanyToken.t.sol: 28 tests covering metadata, exact supply, single mint to a contract deployer rather than tx.origin, success and failure paths for transfer, approve and transferFrom, a rehearsal of the 10/80/10 launch flows arriving whole, the same admin and freeze selector sweeps the protected test runs, a bytecode scan for DELEGATECALL/CALLCODE/SELFDESTRUCT, and three fuzz tests for supply conservation and allowance accounting.
• foundry.toml: solc = "0.8.26", bytecode_hash = "none", cbor_metadata = false, optimizer on, ffi off, empty fs_permissions.
• lib/forge-std (v1.9.7) and lib/openzeppelin-contracts (v5.3.0) vendored as plain files with their licences. No .git directories or .gitmodules anywhere, so the offline verifier can build it.
• README.md: design, assumptions, manifest-ready deployment parameters, an "After launch" section stating there is nothing to configure, and operational responsibilities including explorer verification and the recommendation for an independent review.

Verification results

Slither and Mythril are not installed on this machine and were not run. The new files are left in the working tree uncommitted, since the rules forbid touching .git/; no launch.json was written and no stand-in values were used, because the brief needed none.

Created launch.json matching CompanyToken, its exact supply, empty constructor arguments, and the required pool and economics.

forge build succeeded. All 28 tests passed with the supplied fuzz seed. Only launch.json changed outside permitted scratch artifacts.

The review is complete and the report is written to .imd-findings.json. No files in the tree were changed, and the scratch test was removed.

Outcome: no defects in the Access Control, Trust Gap or Asymmetry areas. The token is OpenZeppelin v5.3.0 ERC20 with a single constructor line that mints the full supply to the deployer. It has no owner, no roles, no initializer, no receive or fallback, and no override of any transfer path.

What I verified:

• Permission map. The compiled ABI exposes exactly three state-changing functions: approve, transfer and transferFrom. Each acts only on the caller's own balance or allowance. The deployer and factory have no power over a holder: a transferFrom from the deployer with no allowance reverts.
• Asymmetry. transfer and transferFrom produce identical balance deltas and leave totalSupply unchanged. Approve overwrites rather than accumulates. Fuzzed conservation of supply across transfer and transferFrom chains holds.
• Dependency integrity. The five vendored OpenZeppelin files the token depends on are byte-identical to the upstream v5.3.0 tag. The context helper returns plain msg.sender, so no forwarder can spoof a sender.
• Launch floor. Traced the protected test: empty constructor arguments, supply of exactly 1e27 minted to the factory, no fee or burn on any flow, no privileged selector changes supply or a balance. The existing 28-test suite passes.
• Static leads. The aderyn large-literal lead evaluates to exactly the brief's supply, so it is not a finding. Slither reported nothing.

One info-level entry is recorded: the standard ERC-20 approve front-run, where a spender can consume both an old and a newly lowered allowance. It is inherent to the standard, bounded by the holder's own approvals, and does not require a fix. It is documented so the judge can see the trust assumption was examined. The coverage record answers all three listed entry points plus five invariant rows.

The review is complete. The findings file is valid JSON and the working tree is clean apart from it.

Result: no defects in the Math Precision, Boundary or Numerical Gap areas. The findings list is empty, with seven coverage rows, all holds.

What was checked

• Supply constant. The expression on line 26 is a compile-time checked constant that evaluates to exactly 10^27, matching the brief and the README. The aderyn "large numeric literal" lead is not a defect.
• Arithmetic paths. All of them are OpenZeppelin v5.3.0 ERC20, which I confirmed is the upstream text verbatim in the vendored library. The mint uses a checked add. The unchecked subtract and add in transfers are bounded by the balance check and by the fixed supply, so neither can wrap.
• Boundaries. The token makes no external calls, has no payable, receive or fallback function, no sentinel-address branch beyond the standard zero-address reverts, and decodes no bytes. There is no division, no fixed-point scale and no downcast, so zero-rounding, truncation amplification and decimal mismatch have no site to occur.
• Concrete edge tests I ran in a scratch file, all passing: full-supply round trip, 1-wei and zero-value transfers from an empty account, self-transfer through an allowance, allowance exactly consumed then one more wei refused, allowance at max minus one decrementing while max does not, moving the whole supply under a max allowance, a max-uint transfer reverting, and a zero-address sender through transferFrom reverting before any state change. A 256-run invariant test over random transfers kept the sum of balances equal to the total supply.
• Entry points. All three listed entry points are recorded as holds, with the reason for each.

Coverage limits. My area is fully covered. The protected floor's pool seed and swap tests need the verifier's environment and were not run here. The three guides for other areas were not applied beyond what overlapped with mine.

One maintenance note, not reported as a finding: the TOKEN_DECIMALS constant is not wired into decimals(), which stays at OpenZeppelin's default. Both are 18 today, so the shipped code is correct, but a future edit to the constant would scale the supply without changing what decimals() returns.

The review is complete. The findings file is valid JSON, the quoted snippet matches the tree at the cited line, and the working tree shows no modified tracked files. The only files I created are the findings file and a scratch test, both of which are untracked and ignored by git.

Outcome: no defects found in the control flow. The token is OpenZeppelin v5.3.0 ERC20 with a single constructor line that mints the full supply to the deployer. Every path I traced behaves as the brief and the launch floor require.

What I covered

• Execution Trace. Traced approve, transfer and transferFrom through the inherited internals with concrete inputs. The zero-address sender and receiver paths revert even at zero value, so transferFrom cannot act as a mint or burn. Unlimited allowance is not decremented, which is standard OpenZeppelin behaviour. There are no external calls, callbacks, sentinel branches, encoding steps or multi-step state, so none of the within-transaction or cross-transaction failure modes apply.
• Periphery. Read the vendored ERC20, Context and the three interface files in full. They are identical to upstream v5.3.0. The compiled ABI exposes only the standard ERC-20 functions, events and errors plus four constant getters. Storage layout is the standard five slots.
• First Principles. The supply constant evaluates to exactly one billion tokens at 18 decimals, is minted once to msg.sender rather than tx.origin, and the constructor takes no arguments and makes no external calls. Launch flows move exact amounts because nothing taxes or burns on transfer.
• Tests. The project suite passes, and I wrote eight additional scratch tests confirming the edge paths above plus a fuzzed conservation check. All pass.

One info-level note recorded. The inherited approve has the standard ERC-20 overwrite race. A spender holding an allowance of 100 can front-run a reduction to 50 and move 150 in total. This is inherent to the specification the brief asks for, not a defect in the code, and does not touch the launch flows. I logged it so the author can decide whether to document it or add permit or increase-and-decrease helpers.

Coverage record. All three listed entry points have rows, plus rows for the constructor, the supply invariant, the vendored periphery, the deploy script and the absence of receive or fallback. Slither reported nothing. Aderyn's low-severity numeric-literal note is a style item and was not promoted.

The review is complete and the findings file is in place. Nothing else is pending.

Outcome: no defects found. .imd-findings.json holds an empty findings list and eight coverage rows, all holds. No tracked file changed. The worker's own exclude rule hides the findings file from git status, which is expected.

What the token is. CompanyToken inherits OpenZeppelin v5.3.0 ERC20 and overrides nothing. The constructor takes no arguments, makes no external call, and mints exactly 1e27 minor units to the deployer. There is no owner, minter, pause, blocklist, fee, burn, hook, receive or fallback.

What I checked against the three guides.

• Economic Security: no external dependencies to break, no token misbehaviour to exploit, no privileged surface. Sentinel addresses revert rather than silently succeed. ERC-20 compliance is full.
• Invariant: sum of balances equals totalSupply and totalSupply is fixed forever. The only mint is the constructor, no burn path exists, and transfers to the zero address revert. A scratch handler-driven invariant test over 4096 calls never broke it.
• Flow Gap: every launch flow moves exactly its amount, so the factory, distributor, PoolManager and requester all receive what the floor expects. No exemption list exists to misconfigure.

Verification run. The vendored ERC20 reads line for line as upstream OpenZeppelin v5. The project's 28 tests pass, including under a second fuzz seed with 1000 runs, and forge fmt --check is clean. The protected custom_token floor tests cannot run in this tree because they import the floor's own harness, so I traced each of their checks by hand instead. All scratch tests were removed.

Static analysis leads. Slither reported nothing. Aderyn's large-numeric-literal note on line 26 is the supply constant, which is correct and intended, so it is not a finding.

Added failure-path, boundary, fuzz, and five-actor invariant tests under test/.

Verified offline with the required seed: forge build and forge test pass—54 tests, including four invariants across 32,768 random calls.

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

Review complete. The findings file is written and the tree is otherwise unchanged.

Outcome: no defects. The token is an unmodified OpenZeppelin v5.3.0 ERC-20 with a parameterless constructor that mints the full supply to the deployer. All three state-changing entry points hold.

What I verified

• Specialists' findings: audit_permissions and audit_flow both reported the same inherited ERC-20 approve overwrite race. I reproduced it in a scratch Foundry test and merged the two into one info-level finding, recorded as a trust assumption rather than a defect. The other two specialists and the test writer reported nothing.
• Library integrity: the vendored ERC20.sol and its four dependencies are byte-identical to upstream OpenZeppelin v5.3.0.
• Deployment model: deployed via CREATE2 from a probe contract, the token mints exactly the manifest's supply to the deployer, reports 18 decimals, and is far under both bytecode size limits.
• Launch flows: transfers from the factory, distributor and an ordinary holder move exact amounts with the supply unchanged. transferFrom enforces allowances and refuses the deployer with no allowance.
• Attack surface: no fallback or receive, unknown selectors and ETH revert, and the runtime bytecode contains no DELEGATECALL, CALLCODE or SELFDESTRUCT.
• Manifest: launch.json uses only schema keys, an empty constructorArgs matching the constructor, and a totalSupply equal to what is minted.

The existing 54 project tests and my 7 scratch tests all pass. The static analysis lead about a large numeric literal is a style note on the supply constant and not a defect.

Deliverable: .imd-findings.json holds 1 info finding and 7 coverage rows covering all 3 entry points plus the constructor, privileged-path, library-integrity and manifest invariants. The scratch test directory was removed.