The MirrorIMD token is implemented, tested, documented, and committed on main.

What was built

• src/MirrorToken.sol is a plain OpenZeppelin v5.0.2 ERC-20 named MirrorIMD with symbol MIRROR and 18 decimals. Its no-argument constructor mints the whole supply once to the deployer and emits a SupplyMinted event. There is no owner, mint, burn, pause, blocklist, fee or exemption, so every launch flow (swarm share, pool seed, remainder) arrives whole.
• foundry.toml pins solc 0.8.26 at the repository root with bytecode_hash none and CBOR metadata off. I confirmed the runtime bytecode carries no metadata trailer. ffi is off and no filesystem permissions are granted.
• forge-std 1.9.7 and the ERC20 subset of OpenZeppelin 5.0.2 are vendored under lib/ as ordinary files. There is no submodule and no nested .git directory.
• script/DeployMirrorToken.s.sol exposes a deploy function that tests call directly. Its run entry reads nothing from the environment.
• The README documents the launch assumptions, the manifest parameters (contract name, name, symbol, decimals, empty constructor args, total supply in minor units), an empty "After launch" section since nothing is owner-settable, operational responsibilities, and the security checklist outcome.

Verification

Check	Result
forge build	passes, 28 files with solc 0.8.26
forge test	27 passed, 0 failed, including a 256-run fuzz
forge fmt --check	passes

The test run was repeated with an empty environment after a clean rebuild. Tests cover exact supply and recipient, metadata, constructor events, a contract deployer receiving and forwarding the supply, exact-amount transfers and allowances, typed revert failures (insufficient balance, insufficient allowance, zero-address receiver and spender), the same mint and privileged-call selector lists the protected floor test uses, a runtime scan for DELEGATECALL, CALLCODE and SELFDESTRUCT, and rejection of plain ETH.

Not done

• Slither and Mythril were not available on this machine and did not run. The README says so.
• No launch.json was written, per the brief. The manifest step owns it.

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

Validation passed: manifest checks, forge build, and all 27 tests. Only launch.json is changed.

The review is complete. The findings file at .imd-findings.json parses, holds zero findings and eight coverage rows, and no tracked file in the repository was changed.

Result: no defects found in the Access Control, Trust Gap and Asymmetry areas. The token is an unmodified OpenZeppelin 5.0.2 ERC-20 whose only addition is a no-argument constructor minting the fixed supply to the deployer plus an event.

What I verified, and how:

• Permission model. The compiled ABI contains exactly three state-changing functions, the standard approve, transfer and transferFrom. There is no mint, burn, owner, pause, blocklist, initializer or upgrade function, so no privileged actor exists after deployment.
• Each entry point traced. Every writer is guarded by its own caller semantics in the unmodified OpenZeppelin code. The deployer holds no pull right over any holder and cannot grow the supply. The infinite-allowance branch is the only asymmetric path and matches the documented ERC-20 convention.
• Supply and custody. The constructor mints exactly one billion tokens at 18 decimals to the creation sender, which is the factory under the launch's CREATE2 deployment. This matches the brief and the manifest expectations in the README.
• Bytecode. An independent opcode scan of the runtime found no call, delegatecall, callcode, staticcall, create or selfdestruct opcodes. There is no receive or fallback, so plain ETH is refused.
• Vendored libraries. The OpenZeppelin files are byte-identical to the 5.0.2 npm release. The forge-std sources are byte-identical to the v1.9.7 tag, so the project's 27 passing tests can be trusted as evidence.
• Build and tests. The project compiles cleanly on solc 0.8.26 and all 27 tests pass.

Coverage not reached: I could not run the protected launch floor test, which needs the Uniswap v4 sources and launch environment variables not present in this tree. Structurally the token meets it, since every transfer moves the exact amount with no exemptions needed. The standard ERC-20 approve front-running race is noted in the approve coverage row as an inherent property of the requested interface, not reported as a defect.

Review complete. No defects found in the math precision, boundary, or numerical gap area, and the report is written to .imd-findings.json with an empty findings list and seven coverage rows.

What the token is. src/MirrorToken.sol is OpenZeppelin 5.0.2 ERC20 with three public constants and one extra event. The constructor mints a compile-time constant of exactly 10^27 minor units to msg.sender. There is no fee, burn, mint, owner, pause, payable path, external call, or bytes decoding anywhere in the contract.

What I verified.

• The five vendored OpenZeppelin files are byte-identical to the upstream v5.0.2 tag, so the arithmetic in _update and _spendAllowance is the audited library code.
• The supply constant equals 10^27 on chain, matches the manifest word and decimals() of 18, fits in uint128 and int128, and its square fits in uint256. The 10% swarm and 88% pool splits divide with no truncation.
• Transfer of type(uint256).max or supply plus one reverts with a typed insufficient-balance error, not a panic. Zero amounts, whole-balance self-transfers on both paths, and allowance edges at max, max minus one, and zero all behave per ERC-20 semantics. A failed balance check leaves the allowance untouched.
• Every path through transferFrom with a zero-address sender or receiver reverts, including the zero-amount case, so no caller can mint or burn through it.
• A fuzzed random walk of transfers over four holders keeps the sum of balances equal to total supply.
• The compiled ABI exposes exactly the three state-changing entry points the verifier listed, with no receive or fallback. The existing 27-test suite and forge fmt --check pass.

Static analysis lead. The aderyn large-numeric-literal note at line 23 is style only. The literal is underscore-separated and the checked constant product is verified to equal 10^27.

Scope limits. I ran only forge. Slither and Mythril were not available. The pool seed and swap flows live in the launch harness and depend on the deployer's derived price, which is outside this repository. Nothing in the token can tax or distort those flows, so they hold from the token's side. My scratch probe test was removed after running, leaving the tree unchanged apart from the findings file.

The review is complete and .imd-findings.json is written. The git tree shows no other changes, and the scratch tests were removed.

Outcome: no defects found in MirrorIMD. The token is OpenZeppelin v5.0.2 ERC20 with a constructor mint and three public constants. The vendored library files are byte-identical to upstream v5.0.2, which I confirmed by diffing them against the tagged release.

What I checked, against the Execution Trace, Periphery and First Principles guides:

• Execution trace. Traced approve, transfer and transferFrom through _approve, _spendAllowance, _transfer and _update. Zero-address sender, receiver and spender revert with typed errors. Insufficient balance and allowance revert before any write. Self-transfer and transferFrom with from equal to to preserve balances. The max allowance is sticky. Unchecked arithmetic is bounded by the preceding checks.
• Periphery. No assembly, no external calls, no receive or fallback. The runtime bytecode scan for DELEGATECALL, CALLCODE and SELFDESTRUCT passes. The compiled ABI has exactly 13 methods: the three state-changing entry points and ten views.
• First principles. The constructor mints exactly 10^27 minor units once to msg.sender. A CREATE2 factory deploy receives the full supply, matching how the launch factory works. There is no transfer rule, so the distributor, seed and swap flows move exactly what they request. Decimals are the fixed 18. Supply conservation held under fuzzing of transfer and transferFrom chains.

Single recorded item, info only. The standard ERC-20 approve race: a spender can front-run an allowance reduction and consume both the old and new amounts. I reproduced it with a concrete sequence. It is inherent to the ERC-20 design and not a MirrorIMD defect, so it opens no revision. The only suggestion is a one-line mention in the README's allowance note.

Coverage. All three listed entry points are marked holds, plus rows for the constructor mint, the supply invariant, the vendored libraries and the launch-floor assumptions. The one thing I could not execute is the protected launch test itself, since v4-core and the LaunchLiquidity helper are not in this tree.

The review is complete. The findings file is valid JSON, the quoted snippet matches line 15 of the token, and git shows no tracked changes other than the findings output (scratch tests live under the ignored test/scratch/ directory).

Outcome: no defects in the assigned area. MirrorToken is OpenZeppelin 5.0.2 ERC20 with one constructor mint of 1e27 units to msg.sender and nothing else. I recorded one info-level note and seven coverage rows in .imd-findings.json.

What I verified

• Library integrity. All five vendored OpenZeppelin files are byte-identical to the upstream v5.0.2 tag, so transfer, approve and transferFrom behave exactly as the library documents.
• Invariant guide. A handler-based invariant fuzz across seven actors held sum of balances equal to total supply equal to 1e27 across random transfer, approve and transferFrom sequences. Mint and burn are internal and unreachable after construction. The ABI is ERC-20 plus four constant getters.
• Flow Gap guide. A launch-flow simulation moved the swarm share, the pool seed and the remainder out of a contract deployer, settled a sync/transfer/settle probe to exactly the sent amount, pulled a sell via transferFrom with exact credit, and emptied the distributor with uneven claims. Every flow arrives whole.
• Economic Security guide. No fee, rebase, blocklist, pause, void return, hook, callback or external call exists. Creation code contains no call-family opcodes, no appended constructor arguments and no CBOR metadata. Decimals are fixed at 18 and the supply constant computes to exactly 1e27, so the deployer's price derivation is unconstrained by the token.
• Static leads. Slither reported nothing. The aderyn large-literal note on line 23 is a style remark on a correctly computed constant.

The one note (info). The inherent ERC-20 allowance race applies: a spender can consume both an old and a new non-zero allowance when the owner changes it. The reproduction is in the findings file and demonstrated by a passing scratch test. It is standard behaviour, affects no launch flow, and needs no fix. It is recorded so the author can document it for integrators.

Not reached. Nothing in the assigned area was left unchecked. The launch manifest does not exist yet, so manifest review was out of scope for this pass.

The work is complete. forge build and forge test pass with 64 tests across 4 suites, and only files under test/ were added.

What I added

• test/MirrorToken.invariant.t.sol holds a handler-driven invariant suite. Six actors move value through transfer, approve and transferFrom with bounded inputs, while four failure paths run inside try/catch and are asserted to revert with the exact typed error and leave state unchanged. A stranger-call handler fires privileged-sounding and random selectors from the deployer and an outsider. Ghost variables model balances, allowances, and per-actor sent and received totals. The invariants check a fixed supply, sum of actor balances equal to supply, balances and allowances matching the ghost model, nobody holding more than opening plus received minus sent, and immutable metadata. It runs with fail-on-revert enabled, so any escaped revert is itself a failure. A second open-mode contract fuzzes the token directly with arbitrary senders.
• test/MirrorToken.property.t.sol holds 35 stateless property and edge tests. These cover transfer round-trips, path independence, isolation, multi-step conservation, approve overwrite and idempotence, exact allowance spending, the max-minus-one allowance being finite, tight one-wei boundaries on balance and allowance, and the failure paths the existing suite lacked: transferFrom to or from the zero address, the zero address approving or transferring, zero-value transfer to the zero address, and arbitrary unknown selectors leaving all state untouched.

Grounding I ran the invariant suite in test/scratch against a planted token that burns one percent per transfer and exposes a public mint. The handler's postcondition caught it on the first affected transfer. That scratch file is removed.

Defects None found. The implementation is unmodified OpenZeppelin 5.0.2 ERC20 with a one-time constructor mint, and every property held. I wrote .imd-findings.json with an empty findings list. One behaviour is pinned rather than reported: tokens sent to the token's own address are accepted and stranded, which is standard ERC-20 and not a defect.

Two harness notes forge-std 1.9.7 has no fail(string), so the handler uses assertTrue(false, ...). Inline forge-config is per contract and is not inherited, which matters if anyone subclasses the invariant test.

The findings file exists and is excluded from the tree by the repository's own ignore rules. The working tree is otherwise clean, with only build caches present.

Outcome: the audit holds with no revision-opening defects. The review is written to .imd-findings.json with one merged info finding and a nine-row coverage record.

What I verified against the code

• The token is OpenZeppelin 5.0.2 ERC20 unchanged, plus three public constants and one event. The vendored ERC20 file reads as upstream verbatim.
• The constructor mints exactly 1e27 minor units to msg.sender and is the only mint path. The ABI has no mint, burn, owner, pause or blocklist surface.
• Launch flows arrive whole. A scratch test moved the 10% swarm share by transfer and the 88% pool share by exact-allowance transferFrom, and balances matched exactly.
• Failure paths revert with the expected ERC-6093 errors for zero receiver, zero spender, insufficient balance and insufficient allowance. Max allowance is not decremented.
• The runtime bytecode holds no DELEGATECALL, CALLCODE or SELFDESTRUCT, and plain ETH is refused. Creation and runtime sizes are well inside the protocol limits, so CREATE2 deployment with empty constructor arguments works.
• launch.json uses only schema keys, totalSupply matches the mint, decimals match, and remainderTo is lowercase.
• The existing 64 project tests pass, and the aderyn large-literal lead evaluates to exactly 1e27.

Specialist findings The economics and flow specialists both reported the standard ERC-20 allowance overwrite race. Same root cause, so I merged them into one info entry anchored at the contract declaration, reproduced with a concrete sequence where the spender ends with 150 after approvals of 100 then 50. It is inherent ERC-20 behaviour, affects no launch flow, and does not open a revision. The math, permissions and test-writing specialists reported nothing, and my own pass found nothing they missed.

The scratch test directory was removed after running, and the working tree is clean apart from ignored build output.