Done. The PAPERCLASH token project is complete and verified at the repository root.

What was built

• src/PaperClashToken.sol: contract PaperClashToken, a fixed-supply ERC-20 on the unmodified OpenZeppelin v5.1.0 ERC20. Name PAPERCLASH, symbol PCLASH, 18 decimals. The constructor takes no arguments and mints the whole supply once to the deployer. There is no owner, mint, pause, blocklist, fee, upgrade path or ether acceptance, so the supply can never grow and every launch flow moves exactly what it says.
• foundry.toml: pins solc 0.8.26, sets bytecode_hash to none, optimizer on, ffi off, no filesystem permissions. remappings.txt maps forge-std and OpenZeppelin.
• lib/: forge-std v1.9.7 and the five OpenZeppelin v5.1.0 files the ERC-20 needs, vendored as plain files with their licence. No git submodules remain.
• test/PaperClashToken.t.sol: 28 tests covering metadata and supply, CREATE2 factory deployment landing the supply on the factory rather than the caller, transfer and transferFrom success paths, failure paths with exact error selectors, a sweep of common admin selectors from a stranger and from the deployer, a runtime opcode walk for DELEGATECALL, CALLCODE and SELFDESTRUCT, and four fuzz tests on conservation and bounds.
• README.md: behaviour, assumptions, manifest deployment parameters, "After launch" (nothing to configure), operational responsibilities and the audit caveat.

Verification

Check	Result
forge build (solc 0.8.26)	pass
forge test with the verifier's fuzz seed	28 passed, 0 failed
forge fmt --check	pass

Supply in minor units is 1000000000000000000000000000, which is what the manifest step should record. No launch.json was written and nothing was committed, as the harness submits the tree on disk.

One note on the session: an early command that probed for pre-installed libraries outside the workspace was refused by the host guard, so I vendored both dependencies from GitHub instead.

I wrote launch.json for the PAPERCLASH launch. It's the only file I changed, and I haven't committed it. forge build succeeds, and forge test with the required fuzz seed passed all 28 tests. Those tests check the token contract, not the manifest; I checked the manifest by reading it and by parsing it as JSON.

What's in it, based on src/PaperClashToken.sol:

• Token: the contract is PaperClashToken, with name "PAPERCLASH", symbol "PCLASH" and 18 decimals. Its constructor takes no arguments, so constructorArgs is []. totalSupply is "1000000000000000000000000000", which is the 1,000,000,000 tokens with 18 decimals that the constructor mints once to msg.sender.
• Contracts: an empty list ([]), because the accepted code has no application contracts.
• Pool: native ETH (the zero address), fee 12500, tick spacing 60, and initial price "79228162514264337593543950336".
• Economics: copied exactly from the job: {"poolBps":8400,"initialMarketCapWei":"10000000000000000000","remainderTo":"0x863e974406764c8526b102c28a1e53906e032954"}.
• Notes: 460 characters (the limit is 4,000) describing the plain fixed-supply ERC-20, and saying it has no owner, minting, pause or fee, and that no application contracts are deployed.

I found no defects in the economics area, so .imd-findings.json has an empty findings list. It also has seven coverage rows, all holds: the three listed entry points, three invariants and the aderyn lead.

What was reviewed: src/PaperClashToken.sol is a 30-line contract built on OpenZeppelin's standard ERC-20. It adds nothing to how transfers or approvals work. Its constructor mints 1_000_000_000 * 10**18 tokens (1e27) to msg.sender, and that is the only mint. There is no owner, fee, burn, hook, pause or blocklist, and no external calls.

Checks, by guide:

• Economic Security: The contract depends on nothing outside itself. With no owner role and no fee, no one can extract value or set parameters. I also compared the five vendored OpenZeppelin files the token compiles against with upstream v5.1.0, and they are byte-identical. So the "plain ERC-20" claim holds, not just in the token's own source.
• Invariant: The total supply stays at 1e27 forever: nothing can mint or burn after the constructor, and calls to mint, burn and owner revert. Balances are conserved on transfer and transferFrom, including when someone sends to themselves. The allowance drops by exactly the amount spent, and an approval of the maximum value stays unlimited.
• Flow Gap: I simulated the factory deploying the token with CREATE2 and then paying out the swarm's 10% to the distributor, the pool's share (poolBps from 0 to 9000) to the PoolManager, and the rest to the requester. Every amount arrived exactly, the factory ended at zero and the supply was unchanged.

Tests run:

• The project's own 28 tests pass.
• I wrote three scratch tests in test/scratch/: the launch-flow and conservation tests (5,000 fuzz runs each) and a check that mint, burn and owner revert. All pass, and I deleted them afterwards, so the working tree is unchanged.

Static analysis: The one aderyn lead, a large number written at line 23, is style only. It evaluates to exactly 1e27, as the brief requires.

Not covered: I didn't run the protected floor tests. They need harness files (src/LaunchLiquidity.sol, floor/OwnerChecks.sol) that this tree doesn't contain. So I didn't check the real pool seeding or swaps through Uniswap v4 here; my flow test covered the plain token transfers only. There was no launch.json to review yet.

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

What was reviewed. The deliverable is a single contract, src/PaperClashToken.sol: an unmodified OpenZeppelin v5.1.0 ERC20 with a one-line constructor that mints the full supply to the deployer. I applied the Execution Trace, Periphery and First Principles guides from the Pashov reference, read the Senior Auditor's Mindset first, and checked the two protected floor tests the launch will run.

Entry points. All three state-changing functions hold:

• approve goes straight to the library's _approve. Zero spender reverts, the allowance is overwritten, and no external call is made.
• transfer goes to _transfer and _update. Zero receiver reverts, short balance reverts with the exact error, the amount moves whole, and nothing calls back into sender or receiver. A reentrant receiver probe saw zero hits.
• transferFrom spends the allowance, then transfers. Max-uint256 allowance is left alone, max-minus-one is decremented, from equal to to is conserved, and no allowance means no movement. Nobody can pull a holder's balance without that holder's approve.

Periphery. This is where a token this thin could still fail, so I checked the dependencies against upstream. The five vendored OpenZeppelin files are byte-identical to the v5.1.0 tag. The vendored forge-std differs from v1.9.7 in seven files, but only by formatter whitespace. After stripping whitespace every file matches, so the test harness cannot hide a failure.

First principles and launch flow. The constructor takes no arguments and ignores trailing calldata, so a mistaken manifest entry cannot brick deployment. A scratch walk of factory to distributor, pool and remainder, then a trader selling back by approve plus transferFrom, delivered exact amounts at every hop. A fuzzed sum-of-balances invariant held across 256 runs. The compiled ABI exposes nothing beyond the three listed functions and view getters, with no receive or fallback.

Static analysis. The aderyn large-numeric-literal lead at line 23 is a style note. The constant evaluates to exactly 1,000,000,000 with 18 decimals, confirmed by the project's tests and mine.

Not a finding, worth knowing. Standard ERC20 approve has the well-known front-running race between two approve calls. This is a property of the specification the requester asked for, and OpenZeppelin v5 deliberately dropped the increase and decrease helpers, so I did not report it.

The project's own 28 tests and my 6 scratch probes all pass. The scratch directory has been removed.

The review is complete. No defects were found in the permissions area, and the findings file at the repository root records an empty findings list with eight coverage rows.

What was reviewed. The token is a 30-line contract inheriting the OpenZeppelin v5.1.0 ERC20 with a one-line constructor that mints the full supply to the deployer. I checked it against the Access Control, Trust Gap and Asymmetry guides and the Senior Auditor's Mindset in the Pashov reference, plus the Trail of Bits entry-point inventory.

Evidence the permission model holds:

• The compiled method table has exactly thirteen selectors: ten views and the three ERC-20 writers listed as entry points. There is no receive, fallback, owner, initializer, mint, burn, pause or blocklist path.
• All five vendored OpenZeppelin files are byte-identical to the upstream v5.1.0 tag, confirmed by downloading and diffing them. Context has no trusted forwarder, so msg.sender is the only identity read.
• The mint branch of the internal update function is reachable only from the constructor. Transfers reject the zero address on both sides, so supply can neither grow nor be burned after deployment.
• Approve writes only the caller's own allowance row. TransferFrom spends the owner-scoped allowance and debits the owner, never the spender. Infinite allowance is the documented OpenZeppelin behavior.
• The deployer holds no residual power once it pays the supply out. The factory is an ordinary holder afterward.
• The existing 28-test suite passes. A six-test scratch suite I wrote exercised owner-scoped allowances, contract callers, deployer residual power and foreign selectors with concrete values. All passed, and the scratch directory was removed so the tree is clean.

Trust Gap seams. There is no admin setter, fee, price formula or recipient, so none of the four seams has a surface here.

Observations not reported as findings, because neither has a failing input on this code:

• The TOKEN_DECIMALS constant is not wired into decimals(). Both are 18 today, so they agree, but a future edit to the constant alone would not change the token's decimals.
• The standard ERC-20 approve race applies as it does to every plain ERC-20. OpenZeppelin v5 removed the increase and decrease allowance helpers, and the brief asked for a plain token.

Static analysis leads. Slither reported nothing. Aderyn's large-numeric-literal note on line 23 is the supply constant, written with digit separators and an exponent, and matches the brief exactly.

Coverage. All three listed entry points plus the constructor and four invariants are marked holds. Nothing in my area was left unreached.

The math review is complete and found no defects. The findings file is written with an empty list and eight coverage rows, and the working tree is otherwise unchanged.

What I checked, against the Math Precision, Boundary and Numerical Gap guides:

• The token is a one-line constructor over the unmodified OpenZeppelin v5.1.0 ERC20. I confirmed all five vendored library files are sha256-identical to upstream, so the arithmetic under review is upstream's.
• Math Precision. There is no division, no fixed-point scale, no downcast and no scale mixing anywhere. The supply constant on line 23 is a compile-time checked expression equal to exactly 1e27, which resolves the aderyn large-literal lead as a non-defect. The only unchecked blocks subtract a balance or allowance already checked to be at least the value.
• Boundary. No external calls, no payable function, no bytes decoding. The only sentinel branches are the zero-address checks, and each reverts on both entry points, including a zero-amount transferFrom whose sender is the zero address.
• Numerical Gap. The invariant that balances sum to total supply is exact rather than approximate, since nothing rounds and no mint or burn path survives construction. The launch flows of ten and eighty-four percent are exact integers and the pool share fits a Uniswap v4 uint128.

How I verified it. I wrote a scratch suite of 16 probes covering whole-supply moves, supply-plus-one and max-uint amounts, allowance exactly consumed, max-minus-one allowance decrement, infinite allowance against an insufficient balance, self transfers via allowance, and a fuzzed random-transfer chain checking conservation. All passed. The project's own 28 tests also pass under the verifier's fuzz seed at 2000 runs. The scratch directory was removed afterwards.

Coverage. All three listed entry points are marked holds, with five additional rows for the constructor constant, the supply invariant, external boundaries, launch-flow arithmetic and dependency integrity. Nothing in the assigned area was left unreached.

I added invariant tests and edge-case tests for PAPERCLASH, and found no defects, so there is no .imd-findings.json. forge build and forge test pass with the verifier's fuzz seed: 47 tests in 3 suites, none failing. The work is committed as f4e9033. Only the two new files under test/ changed.

The code under test: src/PaperClashToken.sol is the vendored OpenZeppelin v5.1.0 ERC20 plus a constructor that mints 1,000,000,000 × 10¹⁸ to the deployer. I read the vendored ERC20.sol and it matches stock v5.1.0, so a token this simple leaves little room for a bug.

test/PaperClashToken.invariant.t.sol (new): a test contract drives the token with random sequences of calls from five accounts, including the deployer, and keeps its own record of every balance and allowance. The calls are transfer, approve, transferFrom, transfers to the zero address, and tries at mint, burn, pause, blacklist, freeze and seize functions, which don't exist. Amounts lean towards the edges: 0, 1 wei, the whole balance, the balance plus one, the full supply and the largest possible number. These hold after every call (256 runs × 64 calls):

• The total supply never changes, and the five accounts always hold all of it.
• Every balance and allowance matches the expected record.
• Every call either succeeds and moves exactly what it says, or fails with the exact expected error.
• No mint, burn or seize call ever succeeds.
• Name, symbol and decimals never change.

Two plain tests check that the starting balances are recorded correctly and that the random calls really reach both the success and the failure branches.

To confirm the suite can catch a real bug, I ran it against a throwaway copy of the token with a 1-wei fee on each transfer, and it failed at once. That copy is not in the commit.

test/PaperClashToken.edges.t.sol (new), failure paths the existing suite didn't pin down:

• transferFrom to or from the zero address
• an unlimited allowance doesn't let a spender take more than the balance
• a holder needs an allowance to use transferFrom on their own tokens
• a transfer of the largest possible number fails
• the whole supply moves in one transfer
• a zero-amount transferFrom needs no allowance
• an approval set to 0 cancels it
• allowances apply to one direction and one spender only
• transferFrom logs no Approval event
• the constructor logs only the mint
• a failed call never uses up allowance
• three random-input tests (1,000 runs each): a stranger can't move someone else's tokens, a transfer and its return leave balances as they started, and an unlimited allowance moves exactly the amount asked

Git had no identity set on this machine, so I made the commit under the same "IdentityMD Worker" name and address as the earlier commits. I passed it on that one command and didn't change any git settings.

The review is complete and clean. .imd-findings.json holds zero findings and seven coverage rows, and the working tree is otherwise unchanged.

What I checked

• Specialist input. All four specialists and the independent tester reported nothing, so there was nothing to reproduce or merge. I traced every entry point myself rather than relying on their holds.
• Source. src/PaperClashToken.sol is a one-line constructor on top of OpenZeppelin ERC20: it mints the constant supply to msg.sender and adds nothing else. The compiled ABI has exactly three state-changing functions and no receive or fallback.
• Dependency integrity. All five vendored OpenZeppelin files hash byte-for-byte to upstream v5.1.0, so transfer, approve and transferFrom are the audited library paths. I traced each one's checks and revert reasons and confirmed them with a scratch Foundry test, since deleted.
• Launch floor. Supply constant equals the manifest string exactly, decimals are 18, the constructor takes no arguments matching the empty constructorArgs, runtime and creation code are far under the size limits, and the disassembled runtime contains no DELEGATECALL, CALLCODE or SELFDESTRUCT. Launch flows move exactly what they say because there is no fee, hook or burn.
• Manifest. launch.json uses only schema keys, correct types, a lowercase remainder address, and a contract name within the 32-character limit.
• Static analysis lead. The aderyn large-numeric-literal note points at the supply constant, which evaluates to the correct value. Not a defect.

Build, format check and the repository's 47 tests all pass. Nothing blocks this launch from the token's side.