The World Meme Token project is complete and verified.

What was built

• src/WorldMemeToken.sol: contract WorldMemeToken, a fixed-supply ERC-20 on OpenZeppelin v5.1.0. Name "World Meme Token", symbol "WORLD", 18 decimals. The constructor takes no arguments, makes no external calls, and mints 1e27 minor units once to msg.sender. There is no owner, mint, burn, pause, blacklist, tax or upgrade path, so the supply can never change and no privileged hand can touch a holder's balance.
• test/WorldMemeToken.t.sol and test/DeployWorldMemeToken.t.sol: 33 tests covering metadata, supply, deployer semantics through a factory-like contract, transfer and allowance success and failure paths, rejection of 14 common admin selectors from both a stranger and the deployer, an opcode scan for DELEGATECALL, CALLCODE and SELFDESTRUCT, the launch flows arriving whole, and four fuzz tests for conservation of supply.
• script/DeployWorldMemeToken.s.sol: reference deploy script with a deploy() function the tests call directly. It reads no environment.
• foundry.toml pins solc 0.8.26, optimizer on, bytecode_hash = "none", ffi off, no fs permissions.
• lib/forge-std v1.9.7 and lib/openzeppelin v5.1.0 are vendored as plain files, trimmed to sources and licenses, with no nested git metadata.
• README.md documents parameters, assumptions, launch economics, deployment, operational responsibilities and security notes.

Check results

Check	Result
forge build (clean)	pass
forge test with the verifier fuzz seed	33 passed, 0 failed
forge fmt --check	pass

One leftover to know about. The sandbox mounts any file named .gitmodules read-only, so an empty directory lib/openzeppelin-contracts/ containing only OpenZeppelin's upstream .gitmodules could not be deleted. It is gitignored, it is not a submodule, and nothing builds from it. The real library lives at lib/openzeppelin.

Slither was not available here and did not run, as the README states.

Created launch.json matching the accepted token, constructor, exact supply, pool settings, and economics.

forge build succeeded. All 33 local tests passed with the specified fuzz seed. Only launch.json changed.

The review is complete. No defects were found in the Access Control, Trust Gap or Asymmetry areas, and .imd-findings.json holds an empty findings list with a ten-row coverage record.

What was checked

• Permission model. The token has no owner, roles, initializer, receive or fallback. The compiled method table is exactly the ERC-20 surface plus five constant getters. The constructor mints the full 1e27 supply to msg.sender once, and the internal mint and burn helpers have no caller afterwards.
• Entry points. All three listed entry points hold. approve writes only the caller's own allowance slot, transfer moves only the caller's balance, and transferFrom is gated by the allowance the holder set. A deployer or factory pulling from a holder without approval reverts.
• Vendored library. The five OpenZeppelin files in the import chain were diffed against the npm 5.1.0 tarball and are byte-identical, so no privileged path hides in inherited code.
• Asymmetry and trust-gap seams. approve and spend write the same slot in mirror directions, the burn side is unreachable so supply cannot shrink, and decimals agrees with the constants and manifest. With no setters, fees or external calls, there is no access-times-economics seam.
• Static-analysis lead. The aderyn large-literal note on line 24 is style only. The constant evaluates to exactly 1e27 and is covered by an existing test.

Verification. The existing 33 tests pass, and five scratch access-trace tests I wrote also passed before being removed. The approve front-running race is inherent to plain ERC-20, documented in the README, and recorded as a note rather than a finding.

The review is complete and the findings file is written. No repository files were changed; only .imd-findings.json and the scratch test under test/scratch/ were created.

Result: no defect found in the economics area. The token is OpenZeppelin v5.1.0 ERC20 with a fixed supply minted once to the constructor's caller, and nothing else. I recorded one info-level note and eight coverage rows.

What I checked

• Vendored library integrity. The five OpenZeppelin files the token compiles against hash-match the upstream v5.1.0 release, so no hidden behaviour sits on any transfer path.
• Economic Security guide. The token has no oracle, external call, hook, receive or fallback, tax, burn, pause, blacklist or privileged role. None of the listed failure modes is reachable. Sentinel checks hold: transfer to the zero address and approve of a zero spender both revert.
• Invariant guide. Supply conservation held under a Foundry invariant run of 256 sequences of 50 random transfer, approve and transferFrom calls. The compiled ABI exposes only three state-changing functions, and a selector sweep for mint, burn, burnFrom, permit, increase and decrease allowance, initialize and owner all revert.
• Flow Gap guide. I reproduced the launch from a CREATE2 factory with the launch number as salt. The factory receives the whole supply, and the three legs of 10 percent, 80 percent and 10 percent arrive whole. The pool manager's settle path through allowance and transferFrom works.
• Launch economics. No launch.json exists in the tree by design. The opening cap of 4,300 IMD for the whole supply gives a tick well inside Uniswap v4 bounds in either currency order.

The one note recorded is the standard ERC-20 allowance race on the inherited approve, reported at info severity. The README already discloses it and it needs no code change. The reproduction is concrete: a spender approved for 100e18 front-runs the owner's lowering to 50e18 and ends up with 150e18.

Commands run and results

Check	Result
forge build	passed
forge test with the verifier's fuzz seed	33 passed, 0 failed
forge fmt --check on src, test, script	clean
scratch invariant, flow, race and selector tests	4 passed
Slither and Aderyn	not run here; the verifier's output listed only a low-impact numeric-literal note, which is not a defect

Passing tests do not prove the absence of defects. The surface here is small enough that the three entry points were traced in full.

The review is complete. The findings file holds zero findings and nine coverage rows, and the working tree is otherwise untouched.

Result: no math defects found. WorldMemeToken is an unmodified OpenZeppelin v5.1.0 ERC20 with a single constructor mint and a pure decimals() override. It contains no division, no scaling conversion, no downcast, no external call, no payable path and no bytes decoding, so the Math Precision, Boundary and Numerical Gap checklists have very little surface to bite on. I verified the surface that does exist rather than assuming it.

What I checked in my area

• Supply constant. TOTAL_SUPPLY evaluates to exactly 1e27, divides by 1e18 with zero remainder, and sits below both uint128 and int128 maxima, so Uniswap v4 liquidity and delta math cannot overflow on it.
• Launch split arithmetic. The 10/80/10 split and the swarm's 2/8 sub-split all divide 1e27 exactly in basis points with no dust and no intermediate overflow.
• Transfer and allowance edges. Max-uint and balance-plus-one transfers revert with the correct typed error. Self-transfer of the whole balance, zero-value transfers, infinite allowance, max-minus-one allowance, exact-allowance spend, and from-equals-to transferFrom all conserve balances and supply. A fuzz conservation invariant held under the verifier's seed.
• Dependency integrity. The five OpenZeppelin files the token compiles against are byte-identical to the upstream v5.1.0 tag. Other vendored files differ only by formatter line-wrapping and are never imported.
• Static analysis lead. The aderyn large-numeric-literal note on line 24 is a readability lint. The literal is the intended whole-token supply and its scaled value is verified.

Coverage record. All three listed entry points are marked holds, plus six invariant rows covering the supply constant, launch split, decimals, boundary enumeration, the static-analysis lead and dependency integrity. Nothing is unreached.

Outside my area. Nothing severe surfaced. The access-control story is trivially empty since the ABI exposes only the standard ERC20 methods and five constant getters. The protected launch tests will pass on this token given its exact transfers and 18 decimals.

Review complete. No defects found in the WORLD token; the findings file holds an empty list and a nine-row coverage record.

What I checked, by guide

• Execution Trace. Traced all three state-changing entry points through OpenZeppelin's _transfer, _update and _spendAllowance. Zero-address sender and receiver revert before any write. Balance and allowance checks precede state changes. The infinite-allowance path never decrements. No mint or burn path is reachable through transferFrom with a zero address on either side. Scratch probes confirmed whole-supply round trips, short calldata rejection, and that value sent to a nonpayable function reverts.
• Periphery. The six sources in the compilation unit are byte-for-byte identical to the published OpenZeppelin 5.1.0 package. The 64 other vendored OpenZeppelin files differ only by forge fmt line reflows and are never compiled into the token. The vendored forge-std copy could not be verified because every GitHub host was refused by the network filter and npm has no 1.9.7 release. It is test-only and does not affect deployed bytecode.
• First Principles. The constructor's only assumption is that msg.sender is the intended recipient, which matches the factory-deploys-via-CREATE2 launch flow. The supply constant resolves to 1e27 at compile time, there is no override of _update, and no privileged function or fallback exists in the compiled ABI. Runtime is 2224 bytes and passes the floor's reachable-opcode scan.

Checks that ran

• Full project suite with the verifier's fuzz seed, 33 tests passing.
• forge fmt --check clean.
• Ten scratch edge-case probes, all passing, then removed.

Not reproduced locally. The Uniswap v4 seed and swap legs of the protected floor test could not be executed because v4-core is not vendored. The token has no tax, burn or exemption logic, so every leg moves exactly the stated amount by construction.

Accepted design, not reported. The classic ERC-20 approve front-running pattern exists, as it does in every standard token. The README documents it and OpenZeppelin v5 intentionally omits increaseAllowance.

No tracked project files were changed. Only .imd-findings.json was written.

Added 22 unit/fuzz tests and four stateful invariants under test/, covering authorization, rollback, boundary amounts, and supply conservation.

Validation:

• forge build: exit 0.
• forge test with supplied seed: exit 0; 56 passed, none failed.
• Invariants: 32,768 random calls passed.
• slither .: exit 255; two inherited informational compiler/pragma warnings, no high-severity findings.
• Manifest check not applicable: no launch.json.

No implementation defects found.

The review is complete and written to .imd-findings.json. No repository file was changed. The scratch test directory was removed after use.

Result: one info-level finding, no defects. The token is a fixed-supply OpenZeppelin ERC20 with nothing added beyond constants and a decimals() override.

What I verified:

• Specialist finding reproduced and kept at info. The economics area's allowance-race report executes exactly as described. A holder who lowers a non-zero allowance can have both amounts spent by a front-running spender. This is the standard ERC-20 property, disclosed in the README, and needs no code change. It is the only specialist finding, so there were no duplicates to merge.
• Vendored library is genuine. The five OpenZeppelin files the token compiles against hash-match the upstream v5.1.0 release byte for byte, so the inherited transfer, transferFrom and approve paths are the audited ones.
• Launch floor properties hold. The constructor mints exactly 1e27 to msg.sender with no arguments and no external calls. The compiled ABI exposes only the ERC-20 surface plus constant getters. Privileged selectors and plain ETH calls revert. The runtime has no reachable DELEGATECALL, CALLCODE or SELFDESTRUCT, and is well under the size limit.
• Manifest agrees with the code. Only schema keys are present, addresses are lowercase, numeric and string types are correct, the contract name and notes are within limits, and totalSupply matches what the constructor mints.
• Project tests pass. All 56 existing tests pass, and my scratch reproduction of transfer, transferFrom, approve and their failure paths passed, including a fuzzed exact-delivery check.

Coverage: all three entry points answered, two as holds and approve linked to the info finding, plus three invariant rows.