Implemented MirrorIMD (MIRROR): 1 billion tokens, 18 decimals, minted once to the deployer.

Added vendored dependencies, deployment script, documentation, and 33 passing tests. Build, formatting, deployment simulation, and second-seed fuzz checks passed.

The platform’s full AMM integration check remains for the network verifier. No transactions were broadcast.

Created launch.json with the exact token supply, constructor arguments, and verbatim economics. Only the manifest changed.

Validation passed against the supplied schema and compiled ABI. forge build succeeded; forge test passed all 33 tests.

The protected AMM harness requires platform dependencies unavailable in this tree.

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

Result: no defects in the assigned area. MirrorIMD is a 15-line wrapper over the vendored OpenZeppelin v5 ERC20 with a single constructor mint. It contains no division, no scaling, no narrowing cast, no external call, no payable path, no sentinel branch and no bytes decoding. Nearly every item in the Math Precision, Boundary and Numerical Gap guides is therefore structurally absent rather than merely unexploited.

What I verified concretely

• The supply constant evaluates to exactly 1e27 and is divisible by 10,000, so the swarm share, pool seed cap and remainder are all exact with no truncation.
• All three entry points hold at every edge the guides name: zero amount, one wei over balance, max uint, empty sender, self-transfer, delegated self-transfer, infinite allowance, max-minus-one allowance, allowance one wei short, and balance-short reverts that roll back the allowance decrement. A scratch Foundry test with ten cases, two of them fuzzed, passed and was then removed.
• Conservation of supply and sum of balances holds under the repository's invariant suite and my fuzz over arbitrary splits.
• The compiled runtime contains no DELEGATECALL, CALLCODE, SELFDESTRUCT, CALL or CREATE opcodes, and the ABI exposes no mint, burn, fallback or receive.
• The vendored OpenZeppelin files are byte-identical in body to upstream tags v5.5.0 and v5.7.0, differing only in import order and the non-draft name of the error interface. The repository checksum file verifies.

The one recorded item is informational. Replacing a non-zero allowance with a smaller one via approve can be front-run so the spender consumes both the old and the new amount. That is standard ERC-20 behaviour inherited from OpenZeppelin, requires no code change under the brief, and no launch flow depends on allowance adjustment. It is included with a concrete call sequence so the judge can see the only sharp edge found.

Coverage record has ten rows. The three entry points and six invariants are marked holds. One row is marked unreached: the protected launch test's PoolManager seed and swap could not be executed because v4-core and the launch helpers are not in this tree, though the token's behaviour in those flows is plain transfer with nothing in my area that could affect them.

The review is complete. The findings file is written at the repository root, no tracked file was changed, and the scratch tests were removed.

Result: no defects found in the assigned area. The token at src/MirrorIMD.sol is a 16-line subclass of OpenZeppelin ERC20 whose only custom behaviour is one constructor mint of the full supply to msg.sender.

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

• Permission model. There is no role, owner, initializer, modifier or inline msg.sender check anywhere. The compiled ABI has exactly three nonpayable functions and no receive or fallback. Storage is five slots, written only by those three functions and the constructor.
• Hidden entry points. A fuzz of 2000 random selectors with random tails, called from both the factory and a stranger, changed no storage slot. Known admin selectors (mint, pause, blacklist, upgradeTo, burnFrom and others) all revert for both callers.
• Residual deployer power. The factory, after deployment, cannot transferFrom a holder without allowance and holds no authority beyond an ordinary balance. Holders keep full control.
• Approve and transferFrom pairing. Allowances are scoped to the (owner, spender) pair, decrement by exactly the spent amount, preserve the infinite sentinel, and roll back atomically on any downstream revert. Zero-value transferFrom without allowance succeeds and moves nothing, which ERC-20 permits.
• Supply and external calls. _mint and _burn are internal and unreachable, so supply is written once. The deployed runtime contains no CALL, STATICCALL, DELEGATECALL, CALLCODE, CREATE, CREATE2 or SELFDESTRUCT opcodes.
• Dependency trust. The vendored OpenZeppelin ERC20 was diffed against an independent upstream copy. Code bodies are identical; only comments and import order differ. All 40 checksum entries verify.
• Launch flows. With no fee, exemption branch or callback, transfers from the factory, distributor and pool manager move exact amounts, so the protected test's whole-share, seed and swap checks have nothing in the token to trip on.

Trust assumptions documented rather than reported: the factory holds the whole supply at launch by design, and the standard ERC-20 approve-ordering race applies, as the README already states. The deploy script is a local rehearsal that is not part of the network launch path.

Coverage record: all three verifier entry points plus the constructor and five invariant rows marked holds. Nothing was left unreached. Existing suite: 33 tests pass. Tools run: forge build and test, forge inspect for ABI, storage layout and bytecode; the supplied Slither and Aderyn output contained only a large-literal style note, which is not a defect.

Added failure-path, boundary, and fuzz tests; strengthened invariants with independent balance and allowance tracking across random calls.

forge build and forge test pass: 48 tests, zero failures.

Only test/ files changed. No implementation defects found.

The review is complete and the findings file is written.

Outcome: no defects found. The findings file at the repository root holds an empty findings list and seven coverage rows, with all three verifier-listed entry points marked holds. The only file I touched outside of it was a scratch test, which I removed.

What I checked, in my assigned areas:

• Execution Trace. Traced approve, transfer and transferFrom through the vendored OpenZeppelin 5.5 code with concrete values. Zero-address sender and receiver revert, overdraws and overspends revert without state change, finite allowances decrement exactly, and the infinite allowance stays untouched. A scratch Foundry test deployed the token by CREATE2 from an etched factory address and walked every launch leg: swarm share to the distributor, seed into a pool-manager stand-in, remainder to the requester, a claim, a buy and a sell. Every leg moved the exact amount and supply stayed at 10^27.
• Periphery. The five vendored OpenZeppelin files match upstream text. The differences from other local copies are only docstrings, import order and the upstream change from != to < for the infinite-allowance check. All forty dependency checksums verify. The runtime bytecode contains no call, create or selfdestruct opcodes at all, and the contract has no receive, fallback or payable function.
• First Principles. The one assumption the token makes is that the constructor caller is the factory, which the protected harness guarantees by deploying from the factory address. Supply is a compile-time constant equal to 10^27, decimals default to 18, and the ABI exposes only the ten standard selectors, so nothing can mint, burn, pause or freeze after deployment.

Brief conformance. The product page describes a wallet-card service with a frozen on-chain eligibility snapshot and names no transfer mechanics, so a plain fixed-supply ERC-20 is the correct reading of the request.

Leads I checked and dropped. The Aderyn large-literal note is a style remark on a correct constant. The standard ERC-20 approve-ordering race is inherent to the interface and already documented in the README. Tokens sent to the contract address are stranded, which is true of every ERC-20 without a rescue power and is also documented.

Not reached. The platform's protected AMM test needs the launch contracts and manifest, which are not in this tree, so actual Uniswap v4 seeding and swap accounting remain for the network's integration run.

Review complete. No defects were substantiated in the MirrorIMD token, and the findings file holds an empty list with a full coverage record.

What I checked

• The token is a two-line extension of OpenZeppelin ERC20 with one constructor mint of exactly 1e27 units to the deployer. The vendored OpenZeppelin files are byte-identical to upstream master, and all 40 dependency checksums match. The only drift from the v5.7.0 tag is the renamed error-interface file and import order, with identical code.
• All three state-changing entry points hold. Approve never touches balances. Transfer and transferFrom move exact amounts, reject the zero address, and roll back on failure. A transferFrom from the zero address reverts before reaching the balance update, so no mint path exists.
• Invariants hold: sum of balances equals totalSupply equals INITIAL_SUPPLY forever, since the only writer is the inherited update function and no burn path is reachable. The shipped stateful invariant, the README's seeded 4096-run fuzz pass, and my 32-actor scratch fuzz all agree.
• Launch flows hold. I built a temporary Foundry project against the real Uniswap v4 PoolManager and reproduced the protected floor's token legs: swarm share and claim arrive whole, single-sided seed takes no more than the pool share in both currency orderings, an ordinary trader buys and sells back to zero, a router paying by transferFrom consumes the exact allowance, and the remainder leg empties the factory.
• The product site describes a wallet-card eligibility product and states no token mechanics, so the fixed-supply design contradicts nothing.

What I could not reach

The pinned protected test itself was not run verbatim. It needs the platform's LaunchLiquidity, PoolInitializationGuard and HookFlags sources plus launch environment variables, none of which exist on this machine. Its token-relevant assertions were reproduced as described above, and that row is marked unreached in the coverage record.

State of the tree

No repository file was changed. A stray untracked LICENSE file that my first download attempt dropped in the root was removed. My scratch test lives in the gitignored test/scratch directory, and the temporary simulation project outside the repository was deleted.

The review is complete. The findings file is valid JSON, the quoted snippet matches line 120 of the vendored ERC20 exactly, and the working tree shows no tracked changes.

Outcome: no defect in MirrorIMD. The token is an unmodified OpenZeppelin v5.5 ERC20 with one constructor mint of 1e27 to msg.sender, which matches the manifest's supply, decimals, name, symbol and empty constructorArgs.

Specialist findings judged

• The single specialist finding, audit_math's info note on approve replacement ordering, reproduced against the code. I kept it at info as the one merged finding, with my own reproduction stated. It is inherited ERC-20 semantics, not a MirrorIMD defect, and requires no code change.
• Economics, flow, permissions and the independent tester reported nothing. Nothing to merge.
• The aderyn large-numeric-literal lead was checked and dropped. The literal evaluates to exactly the manifest supply.

My own pass ran a scratch Foundry test with six checks, all passing on this code: CREATE2 factory deployment holds the whole supply, exact-amount launch legs, runtime bytecode free of DELEGATECALL, CALLCODE and SELFDESTRUCT, eighteen admin-style selectors and ether sends all revert, and failure paths leave state unchanged. The vendored lib/ has no submodule and all forty files match their pinned checksums. The repository's own 48 tests also pass.

Coverage answers all three entry points as holds, plus four invariant rows. Output is in .imd-findings.json at the repository root. The scratch test lives in the gitignored test/scratch/ directory and no tracked file was changed.