Implemented MirrorIMD (MIRROR): 1 billion tokens with 18 decimals, minted once to the deployer. No later minting or administrative powers.

Included vendored dependencies, success/failure tests, fuzz tests, stateful invariants, and deployment documentation.

Verified with Solidity 0.8.26:

• forge build passed.
• forge test passed: 35 tests using the required fuzz seed.
• forge fmt --check passed.

Created launch.json with MirrorIMD’s exact supply, empty constructor arguments, no application contracts, and the required pool and economics values.

Verified against the compiled constructor ABI. forge build succeeded; forge test passed all 35 tests with the supplied fuzz seed.

Only launch.json is changed for submission.

The review is complete. The findings file holds an empty findings list and eight coverage rows, and the working tree is otherwise untouched.

Result: no defects found in the Access Control, Trust Gap and Asymmetry areas for src/MirrorIMD.sol.

What I verified, with concrete inputs:

• Permission model. The token is OpenZeppelin v5.0.2 ERC20 with one constructor mint to msg.sender. No owner, minter, pauser, blacklist or initializer exists. Calls to mint, burn, burnFrom, owner, pause, blacklist, setFee, initialize and renounceOwnership all revert as unknown selectors.
• approve. An attacker approving itself leaves the factory's allowance to them at zero. Only the caller's own allowances change.
• transfer. Exact amounts move, supply stays at 1e27, zero recipient and insufficient balance revert. No fee or caller-class branch exists, so there is no asymmetry to exploit.
• transferFrom. Pulling 1 unit from the factory with no allowance reverts. A 5-unit allowance is spent exactly to zero and a further 1-unit pull reverts.
• Trust gap. No privileged actor and no economic formula, so no seam between access, economics and asymmetry exists.
• Vendored library. The five OpenZeppelin files are byte-identical to the v5.0.2 release tag, ruling out a hidden path in inherited code.
• Bytecode. No DELEGATECALL, CALLCODE or SELFDESTRUCT opcode. No receive or fallback, so ETH sent to the token reverts.
• Static-analysis lead. The aderyn large-literal note on line 10 is the intended 1e27 supply, not a defect.

Scope notes: no launch.json is present yet, which the reference treats as expected before the manifest step. Every listed entry point has a coverage row marked holds. The existing 35-test suite passes.

The review is complete. The findings file is written with an empty findings list and eight coverage rows, and no repository source was changed.

Result: no defects found in the assigned area. MirrorIMD is a 16-line fixed-supply token that inherits unmodified OpenZeppelin ERC20 v5.0.2 and adds only a constructor minting the whole supply to the deployer.

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

• Entry points. All three state-changing functions (approve, transfer, transferFrom) traced through the library to storage. Zero-address and balance checks precede every unchecked subtraction. A revert inside transferFrom rolls back the allowance write atomically. No external calls, stale reads, partial updates or sentinel bypasses exist.
• Constructor and supply. The literal flagged by aderyn equals 10^27 exactly, matching the task's supply. CREATE2 deployment from a factory-address probe credits the factory, and 10 percent, 80 percent and remainder transfers plus a claim all arrive whole.
• Privileged surface. The ABI exposes nothing beyond the three ERC-20 writers. All 22 admin and freeze selectors from the protected floor revert from both a stranger and the factory address.
• Bytecode. A reachable-opcode scan of the compiled runtime and creation code finds no DELEGATECALL, CALLCODE, SELFDESTRUCT, CALL, STATICCALL or CREATE. The code uses PUSH0 and MCOPY, so the launch chain must support Cancun, which the README and foundry.toml already state.
• Periphery. The six vendored OpenZeppelin files are byte-identical to the upstream v5.0.2 tag.
• Project checks. Build, the 35-test suite with the README's fuzz seed, and formatting all pass.

Two behaviours I checked and deliberately did not report as defects, since they are inherent to ERC-20 and documented in the README: the approve replacement race, and third parties being able to emit zero-value transfers from any address.

The scratch test that reproduces these checks is at test/scratch/Floor.scratch.t.sol, which the harness discards. Nothing outside the assigned area was reached that needed reporting, and the launch manifest does not yet exist in this tree, so it was not reviewed.

The review is complete. The findings file holds an empty list and a nine-row coverage record, and the scratch test directory is removed so the tree is unchanged apart from .imd-findings.json.

Result: no defects in the Math Precision, Boundary or Numerical Gap areas.

What I checked and how:

• Supply constant. INITIAL_SUPPLY evaluates to exactly 10^27, is divisible by 10^18 with zero remainder, and matches the README's base-unit string. The aderyn "large numeric literal" lead is this constant written readably, not a defect.
• Unchecked arithmetic in the inherited ERC20. The balance subtract and allowance subtract are each preceded by a >= check, and the unchecked balance add cannot wrap because total supply is fixed at 10^27 with no reachable mint or burn after the constructor. Scratch tests exercised supply, supply plus one, max uint, zero, one, whole-balance self-transfer and delegated self-transfer.
• Allowance sentinel boundary. Only exactly type(uint256).max is treated as infinite. An allowance of max minus one is finite and decrements. An infinite allowance is still bounded by the holder's balance, and a failed transfer rolls the allowance back.
• Launch flow arithmetic. The 10 / 80 / 10 percent splits of 10^27 in basis points produce no dust, and there is no fee, tax or burn, so the distributor, pool seed and claim transfers arrive whole.
• Boundary surfaces. No external calls, no payable path, no receive or fallback, no bytes decoding. Plain ETH and unknown selectors revert.
• Dependency integrity. All five vendored OpenZeppelin files hash identically to upstream v5.0.2.
• Floor replica. The compiled runtime has no reachable DELEGATECALL, CALLCODE or SELFDESTRUCT and fits EIP-170. The ABI exposes exactly the three state-changing entry points the verifier listed.

Tooling that ran: forge build, the project's 35 existing tests with the README's fuzz seed, 11 scratch boundary tests, and forge fmt --check. Slither and Mythril were not run by me; the supplied static output had no medium-or-higher lines.

Not covered: there is no launch.json in the tree yet, so the manifest could not be reviewed. The remaining ERC-20 behaviours the README documents, such as tokens sent to the token's own address being unrecoverable and the approve replacement race, are standard and were not reported as defects.

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

Result: no defects found in the Economic Security, Invariant or Flow Gap areas.

What I checked and how:

• The token is a 16-line wrapper over OpenZeppelin v5.0.2 ERC-20. I diffed all five vendored library files against the upstream release and they are byte-identical. The only project code is a constructor that mints the supply constant to the deployer.
• Economics. The compiled ABI has exactly three state-changing functions: approve, transfer and transferFrom. There is no receive or fallback, no mint, burn, pause, blacklist or upgrade path, and the reachable-opcode walk of the runtime finds no DELEGATECALL, CALLCODE or SELFDESTRUCT. Supply is exactly 10^27 base units with 18 decimals, so the manifest values and the opening-cap derivation have nothing in the token to trip over.
• Invariants. Supply conservation holds because the only balance writer moves value between slots, mint is reachable only from the constructor, and burn is never reached. The project's own invariant suite passes, and my scratch fuzz covering self-transfers and delegated self-transfers also passes.
• Flow gaps. The token makes no outbound calls and receives no callbacks, so there is no stale-state seam. A factory stand-in deploying by CREATE2 receives the whole supply, the swarm share and claims arrive whole, and a PoolManager-style balance-delta pull and return-value-checked push both see exactly the transferred amount.

Two documented standard behaviours were measured but not reported as defects: the ERC-20 allowance-replacement race, and the absence of an Approval event on transferFrom. Both are EIP-20-conformant and the README already states them.

One area was unreachable: the launch economics figures such as the opening market cap, pool share and paired currency are not in this tree because no launch.json exists yet. The coverage record says so explicitly. The findings file holds nine coverage rows, one for each listed entry point plus the invariants and flows I traced.

Added 17 tests covering allowance boundaries, revocation, replay prevention, failed-call rollback, and transfer properties. Expanded stateful invariants to nine randomized operations.

forge build and seeded forge test pass: 52 tests, including 24,576 invariant calls.

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

I found no defects in MirrorIMD, and the four specialists reported none either, so there was nothing to reproduce or merge. I wrote .imd-findings.json with an empty findings list and a coverage record for the three entry points plus two properties I checked across the whole contract (invariants).

What I checked:

• Token source (src/MirrorIMD.sol): it is a plain OpenZeppelin ERC-20 with a constructor that takes no arguments. It mints INITIAL_SUPPLY (1,000,000,000 × 10^18) once to msg.sender, which is the factory. It adds no functions and overrides nothing: there is no external mint or burn, no owner or admin role, no transfer fee, and no DELEGATECALL or SELFDESTRUCT.
• Library code: the vendored ERC20 and Context files match OpenZeppelin v5.0.2 as I know it. I didn't fetch upstream to compare hashes.
• Entry points (all holds):
  • approve sets the allowance, rejects a zero spender and emits Approval.
  • transfer and transferFrom move exactly the amount asked, or revert on a zero receiver, too little balance or too little allowance. An unlimited allowance is not reduced.
  • So the launch transfers to the distributor, the pool seed and swaps against the PoolManager all arrive in full.
• Deployment: the deployed code is 2,640 bytes and the creation code 1,752 bytes, well under the 24,576 and 49,152 byte limits. launch.json lists no constructor arguments, which matches the constructor. Decimals (18), supply (1000000000000000000000000000), contract name, lowercase addresses and schema keys are all consistent with the code.
• Tests: all 52 tests in the repo pass.
• Static analysis: the only tool result was aderyn's low "large numeric literal" at line 10. It is the intended supply constant and not a defect.

I couldn't check the economics block against the original job, since the job's own figures weren't given to me; it looks plausible. No files were changed apart from the findings file.