Implemented WORLD with 18 decimals and exactly 1,000,000,000 tokens minted once to the deployer. Included vendored dependencies, success/failure tests, fuzz tests, invariants, and deployment documentation.

Verified:

• forge build — passed
• forge test with the supplied seed — 31 passed
• forge fmt --check — passed

The protected launch integration remains for the separate launch harness.

The review is complete. The findings file holds no defects and a full coverage record.

Outcome: no reproducible defects in the economics area. WorldMiningToken is the unmodified OpenZeppelin v5.4.0 ERC-20 with a single constructor mint to the deployer. The vendored OpenZeppelin files match the SHA-256 digests recorded in the repo. The ABI exposes only the three ERC-20 mutators, the views, and the supply constant.

What I checked against the Economic Security, Invariant and Flow Gap guides:

• Launch flows arrive whole. No fee, burn, rebase, exemption list or recipient callback exists. The swarm, pool and remainder shares of the supply divide exactly, and claims and sells back into the pool manager move the exact amount.
• Conservation. Sum of balances equals total supply before and after any sequence. The repo's invariant suite and a scratch fuzz both pass. Nothing can mint or burn after construction.
• ERC-20 compliance edges. Infinite allowance is not decremented, finite allowance is, a failed delegated transfer rolls back the allowance spend, zero-address transfers and approvals revert.
• Privileged power. None exists. No owner, pause, blacklist, upgrade, delegatecall or selfdestruct. The constructor makes no external calls.
• Static analysis lead. The aderyn large-numeric-literal note is a compile-time constant equal to 10^27, which matches the brief.

Coverage rows were written for all three listed entry points plus two invariants and the static-analysis lead, each marked holds. The existing test suite passes in full. My scratch test directory was removed, so the only new file in the tree is the findings file.

The review is complete. The findings file holds an empty findings list and a full coverage record, and the working tree is otherwise unchanged apart from that file.

Result: no defects found. World Mining Token is a 17-line wrapper over the unmodified OpenZeppelin v5.4.0 ERC-20. It mints exactly one billion tokens with 18 decimals to the deploying factory in the constructor and adds nothing else.

What I verified for the Execution Trace, Periphery and First Principles areas:

• All three entry points traced end to end through the vendored OpenZeppelin code. Transfers debit and credit exact amounts, every zero-address path reverts, allowance spending rolls back on any later revert, and the maximum allowance is treated as infinite. These hold.
• Supply is fixed. The only path that increases total supply is the mint branch inside the constructor. The compiled ABI exposes no mint, burn, pause, blacklist, owner or upgrade selectors.
• No external calls or callbacks. The compiled runtime contains no CALL, STATICCALL, DELEGATECALL, CALLCODE, CREATE or SELFDESTRUCT opcodes, so reentrancy and hook risks do not exist.
• Launch flows arrive whole. There is no fee, burn or exemption list, so the distributor share, the pool seed and trader swaps move exactly what they state. The manifest needs empty constructor arguments and a total supply of 10^27 base units.
• Periphery is unmodified. All six vendored OpenZeppelin files match the SHA-256 digests recorded in the dependency manifest. Context returns the plain sender.
• Checks run: build, formatting check, the project's 31 tests including the 256-run invariant suite and 1,024-case fuzz tests with the documented seed, and a scratch probe of edge paths. All passed. The scratch directory was removed afterwards.

Leads reviewed and not reported. The static-analysis line about a large numeric literal is cosmetic since the value fits comfortably in a uint256. The standard ERC-20 approve-replacement race and tokens sent to the token's own address are inherent to the requested standard design and are already documented in the README, so neither is a defect of this code.

Coverage was written as seven rows: one each for approve, transfer and transferFrom, plus the constructor mint, the supply-conservation invariant, the launch flow property and the periphery files. Nothing in the assigned area was left unreached.

The review is complete and .imd-findings.json holds the result: zero findings, with coverage rows for all three listed entry points plus the constructor and two invariants. The scratch test directory has been removed and no tracked file was changed.

What I covered. The Access Control, Trust Gap and Asymmetry guides against the only production contract, src/WorldMiningToken.sol, and the OpenZeppelin code it inherits.

• Access control. There is no permission model to break. The token has no owner, roles, modifiers, initializer, proxy, forwarder or exposed mint and burn. The three state-changing entry points are guarded solely by the caller's own identity through an unoverridden Context. The constructor hands out no role, only the supply, to its immediate caller.
• Trust gap. No privileged actor exists, so none of the access-times-economics seams apply. I confirmed by test that the deployer cannot pull a holder's balance and that the supply cannot shrink through a transfer to the zero address.
• Asymmetry. transfer and transferFrom both funnel into the same internal update with identical validation. The only difference is the allowance spend, which is restored atomically on any revert. The approve versus allowance-spend event asymmetry is OpenZeppelin v5 design and already documented in the README.

Evidence. The vendored ERC20.sol and Context.sol match genuine OpenZeppelin v5.4.0 content on full read. The project suite passed with its pinned seed, 31 tests and 16,384 invariant calls with zero reverts. A seven-case scratch test I wrote for edge paths also passed, including zero-sender transferFrom, self-transferFrom, ETH refusal and origin-versus-caller minting.

Not reported. The classic ERC-20 allowance replacement race is inherent to the standard, not a defect in this code, and the README gives holders the mitigation. The aderyn large-literal note is style only.

Nothing in the assigned area was left unreached.

The review is complete and .imd-findings.json is written.

Outcome: no math, precision, boundary or numerical-gap defect in the token. One info-level provenance note outside my area.

What I checked

• The token is a bare OpenZeppelin v5.4.0 ERC-20 whose only custom code is a compile-time constant and a constructor mint. All six vendored OpenZeppelin files match their recorded SHA-256 digests, so the arithmetic under review is unmodified upstream code.
• Math Precision guide: there are no divisions, fixed-point scales, casts or decimal conversions. The supply constant evaluates to exactly 10^27, fits comfortably in uint256 and uint128, and the mint uses a checked add. The unchecked subtract and add in the OpenZeppelin update path are bounded by the balance check and the supply.
• Boundary guide: no external calls, no payable, receive or fallback paths, no bytes decoding. Sending ether with or without calldata reverts. The only sentinel branches are the zero-address checks, which revert for both zero and nonzero amounts.
• Numerical Gap guide: zero-amount transfers, self-transfers of the full balance, allowance exactly equal to the amount, allowance of max minus one, infinite allowance against an empty balance, and the 10/88/2 percent launch split all behave exactly as specified with no dust or drift. I ran scratch tests for each edge plus the existing fuzz and invariant suites, and everything passed. The scratch files are removed.

Finding reported (info): seven vendored forge-std source files do not match the digests recorded in lib/DEPENDENCIES.md, contradicting the README claim that all 36 files matched. This affects only the test harness, not deployed code, and the reproduction command is in the findings file.

Coverage: all three entry points are marked holds, with four extra invariant rows.

Added 18 failure-path, boundary, and fuzz tests. Expanded stateful invariants to 32,768 calls across four actors, checking supply conservation, balances, allowances, and transfer liveness.

Offline forge build and forge test with the required seed passed: 49 tests, zero failures.

Only test/ changed. No implementation defects found.

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

Outcome: the token has no code defects. The one specialist finding reproduced and is kept at info severity.

What I verified

• The contract is a 17-line wrapper over OpenZeppelin v5.4.0 ERC20 with a zero-argument constructor minting the full supply to the deployer. The ABI exposes only the standard ERC-20 functions plus a constant.
• The six production OpenZeppelin files are byte-identical to the upstream v5.4.0 archive, whose hash matches the one recorded in the dependency manifest.
• All three entry points (approve, transfer, transferFrom) trace to unmodified OpenZeppelin code and are marked holds. The suite of 49 tests, including the three invariants, passes with the README's seed.
• The manifest is schema-valid, and the paired currency on chain 1 has code and reports symbol IMD with 18 decimals.

The kept finding (info): the README states all 36 vendored files match their recorded digests, but seven forge-std files fail the check. I confirmed against the upstream v1.9.7 archive that each differs only by line wrapping from forge fmt, so this is provenance documentation drift, not a bytecode issue. I folded in a related drift on the same README section, which reports 31 tests where the tree now runs 49.

Not run: the protected launch harness, since v4-core and the floor's helper contracts are not in this tree. The token's behaviour against that floor was confirmed by inspection instead.