The Paperclash token project is complete, committed, and verified locally.

What was built

• src/PaperclashToken.sol: PaperclashToken, OpenZeppelin ERC20 v5.4.0 with name Paperclash, symbol PAPER, 18 decimals. The constructor takes no arguments and mints the whole supply once to the deployer. No owner, mint, pause, blacklist, burn-from, tax, upgrade path or external call.
• foundry.toml: solc pinned to 0.8.26, optimizer on, bytecode_hash = "none", ffi off, no fs permissions, remappings inline.
• lib/: forge-std v1.11.0 and the five OpenZeppelin ERC20 files vendored as plain files with licenses. No submodules.
• script/DeployPaperclash.s.sol: reviewable reference deployment. Its deploy function reads no environment and is tested directly.
• test/PaperclashToken.t.sol: 31 tests covering metadata, supply, success and failure paths for transfer, approve and transferFrom, exact launch flows through a factory stub, every mint and privileged selector the launch floor probes, bytecode scan for DELEGATECALL, CALLCODE and SELFDESTRUCT, and four fuzz tests for conservation and allowance semantics.
• README.md: assumptions, launch parameters, "After launch" (nothing to configure), operational responsibilities, security notes, and the manifest values the manifest step needs.

Verification

Check	Result
forge build	passes on solc 0.8.26
forge test with the verifier's fuzz seed	31 passed, 0 failed
forge fmt --check	clean

Slither and Mythril were not available on this machine and were not run. The code avoids all six rejecting detectors by construction.

Committed as one commit on main containing only the project paths above. The supply total for the manifest is 1000000000000000000000000000 minor units, and the token constructor takes no arguments.

I found no math defects in the Paperclash token. .imd-findings.json has an empty findings list and a coverage row for each of the three entry points, all marked holds, plus two rows for the supply and exact-amount checks. The file is valid JSON.

What I checked: src/PaperclashToken.sol is a plain OpenZeppelin 5.4.0 ERC20. It doesn't change any transfer or approval logic, and I read the library code to confirm it is the standard version. I covered the Math Precision, Boundary and Numerical Gap guides:

• Supply: TOTAL_SUPPLY = 1_000_000_000 * 10 ** 18 comes to exactly 1e27, which fits easily in a uint256. It is minted once, to the deployer, in the constructor, and no mint or burn function is exposed. The aderyn large-literal warning on line 28 is harmless.
• Edge cases: sending more than the balance or allowance, even by 1, reverts. The unchecked arithmetic can't overflow because no balance or allowance can exceed the fixed supply. Zero-amount, self, and full-balance transfers are exact. An unlimited (max) allowance is never decremented.
• Exact amounts: there is no fee, burn or rounding, so the transfers to the distributor, the pool seed and swaps all arrive whole.
• Tests: the project's 31 tests pass.

Not covered: I didn't count the known ERC-20 approve front-running race as a finding. It is standard ERC-20 behaviour, falls outside the math area, and isn't a defect in this code. There's no launch.json yet, so I had nothing to review there. Apart from the findings file, I changed no files.

I found no defects I could back with a reproduction, so .imd-findings.json has an empty findings list and a coverage record. That file is the only thing I wrote; no source, test or config file was changed.

What the code is: src/PaperclashToken.sol is OpenZeppelin 5.4.0's standard ERC20 with nothing changed. It adds a few constants and a constructor that mints 1_000_000_000 * 10**18 to msg.sender once. It has no _update override, no owner, no mint or burn functions, no pause, no assembly and no external calls. The library code under lib/openzeppelin-contracts has no local changes.

Execution Trace pass:

• transfer and transferFrom: both run straight through OpenZeppelin's _transfer → _update. They move exactly the amount asked for, and revert if the sender or recipient is the zero address or the balance is too small. There are no callbacks, so there is nothing to re-enter.
• Allowance: transferFrom checks and spends the allowance before moving tokens, all in one call. An unlimited allowance is not reduced.
• approve: this is OpenZeppelin's _approve. The "change an approval and get front-run" race is how every standard ERC-20 behaves, not a defect in this code.

Periphery pass:

• Launch flows: transfers from the factory, the distributor and the PoolManager arrive whole, because there is no fee or burn on transfer.
• Constructor: it takes no arguments, so the manifest's token.constructorArgs must be [].
• Deploy script: script/DeployPaperclash.s.sol is a reference script only and gives no one any special role.

First Principles pass:

• Supply: it can never grow after deployment.
• No privileged control: nobody can move or freeze a holder's balance.
• Forbidden opcodes: none of the code uses DELEGATECALL, CALLCODE or SELFDESTRUCT.

Static analysis: aderyn flagged a "large numeric literal" at line 28. The value is 1e27, which fits easily, so that note is about style and isn't a defect. slither reported nothing.

Checks I ran: the existing test suite passes, 31 of 31. I did not run the protected launch tests in .imd/reads/protected/ because they need the launch harness and its environment settings. I checked by reading the code what they test: the supply is minted to the factory, the launch flows arrive whole, and no admin call can mint or freeze balances.

Coverage: all three listed entry points are marked holds, plus two invariant rows (fixed supply, and no forbidden opcodes or special powers). Nothing was left unreached.

Done. launch.json is written and is the only file changed.

What the manifest says

• kind custom_token, token contract PaperclashToken, name Paperclash, symbol PAPER, 18 decimals.
• Empty constructorArgs. The accepted constructor takes no parameters, confirmed against the compiled ABI.
• totalSupply is 1,000,000,000 times 10^18 as a decimal string, exactly what the constructor mints to msg.sender.
• No application contracts, matching the accepted tree, which contains only the token.
• pool and economics copied verbatim from the launch terms: IMD pair address, fee 12500, tick spacing 60, the one-to-one provenance price, and the requester's economics object.
• notes describe the token's fixed supply and lack of privileged functions, at about 1,100 characters.

Checks run

• forge build compiled cleanly with solc 0.8.26.
• forge test with the verifier's fuzz seed passed all 31 tests.
• A scratch script checked the manifest's keys, types, lowercase addresses, name length, notes length, and that constructorArgs length matches the ABI's constructor parameter count.
• git status shows only the new launch.json as untracked. No other file was touched.

I've added two test files for the Paperclash (PAPER) token, and found no defects. The full suite passes with the verifier's fuzz seed: 45 tests across 3 suites. I left the existing test/PaperclashToken.t.sol (31 tests) as it was, and nothing is committed.

The token is a plain OpenZeppelin 5.4 ERC-20. It mints 1,000,000,000 × 10¹⁸ to whoever deploys it, and has no owner, mint function, tax or other admin control. So I didn't write .imd-findings.json.

test/PaperclashToken.invariant.t.sol is the invariant suite the acceptance criteria ask for:

• A handler drives random sequences of calls across five actors: the deployer, two holders, a pool and a distributor.
• It mixes normal calls (transfer, approve, transferFrom, including unlimited approvals) with calls that must fail: overspending a balance, overspending an allowance, pulling more than the owner holds, sending to the zero address, approving the zero address, and a stranger pulling tokens without approval.
• Each failing call must revert with the exact OpenZeppelin error, and the suite stops on any unexpected revert. So a call that succeeds when it should fail, or the reverse, breaks the run.
• The handler keeps its own record of every balance and allowance. After each step the checks confirm:
  • the total supply stays fixed and the zero address holds nothing;
  • the actors' balances add up to the total supply;
  • every balance and allowance matches the handler's record;
  • name, symbol and decimals never change.
• It runs 256 sequences of 64 calls (16,384 calls) with no failures; all nine handler functions were called.

test/PaperclashToken.edges.t.sol has 13 tests for edge cases the existing suite didn't cover:

• Transferring the whole supply, then trying to send 1 more wei; and a transfer of the maximum possible amount.
• A new approval replacing an old one rather than adding to it; revoking an approval; using an allowance up exactly, then failing on the next wei.
• A holder pulling from their own account needs an approval too.
• A zero-amount pull works without any allowance; pulls to or from the zero address revert, and a reverted pull leaves the allowance untouched.
• Spending against an unlimited allowance doesn't emit an Approval event.
• Fuzz tests (1,000 runs each): an approval sets exactly the amount given, and a random stranger can't pull from the deployer.

The permissions review of Paperclash (PAPER) is complete. The findings file is written and the working tree is otherwise untouched.

Outcome: no permission defect. The token is OpenZeppelin ERC20 v5.4.0 with a no-argument constructor that mints the whole supply to the deployer. It has no owner, role, modifier, initializer, proxy, hook, external call, receive or fallback. The compiled ABI exposes exactly three state-changing functions, each acting only on the caller's own balance or allowance row.

What I verified

• Access Control. The permission map is empty beyond the constructor's one mint. Balances are written only through the shared transfer path, allowances only by the owner's own approve or by a spender within its allowance. The factory has no pull right over holders, and the supply cannot grow or shrink after construction since burn is unreachable.
• Asymmetry. The approve and transferFrom pair mirror each other correctly, including the documented infinite-allowance branch. The mint and burn branches inside the update routine are reachable only from the constructor.
• Trust Gap. There is no economic formula inside the token and no privileged actor, so none of the four seams exist.
• Supply chain. The five vendored OpenZeppelin files are hash-identical to upstream v5.4.0, so the inherited code is what it claims to be.
• Tooling. The project builds and all 31 tests pass with the verifier's fuzz seed. The static analysis leads were a large numeric literal only.

One informational finding. The standard ERC-20 approve race is present because approve overwrites the allowance unconditionally. A spender the holder already approved can front-run an allowance reduction and spend old plus new amounts. I reproduced it with a scratch test, which I then removed. This is inherent to the plain ERC-20 the brief asked for and is not a privilege bypass, so it is recorded at info level with an optional additive mitigation.

Coverage. All three entry points have rows, plus five invariant and trust-assumption rows. Nothing in the assigned area was left unreached.

Review complete. The findings file is valid JSON with both snippets matching the tree, and the working tree reports no tracked changes (the findings file and test/scratch/ are ignored by git).

Outcome: no exploitable defect in the economics area. The token is OpenZeppelin ERC20 v5.4.0 with a single constructor mint of 1e27 units to msg.sender, and nothing else.

What I checked, across the Economic Security, Invariant and Flow Gap passes:

• Dependency integrity. All five vendored OpenZeppelin files hash identically to the upstream v5.4.0 tag, so no fee, blacklist or pause logic entered through the library.
• Conservation and exactness. A scratch StdInvariant run over six actors (factory, distributor, pool manager, requester, two holders) never broke sum of balances equal to total supply. Every launch flow moves exactly the requested amount, and the 10/80/10 split leaves the factory at exactly zero.
• Supply immutability. The compiled ABI has only approve, transfer and transferFrom as state-changing functions, no fallback or receive, no owner. Nothing can mint, burn, freeze or seize after deployment.
• Flow Gap seams. The token makes no external calls and has no hooks, so there is no periphery seam to cross. Constructor arguments are empty and the manifest supply figure matches the constant.
• Boundaries. Whole-supply transfer in one call succeeds, one wei more reverts, self-transfer nets to zero, infinite allowance is not decremented.

Two info-level notes were recorded, each with a concrete reproduction, neither a defect in the deployed state:

1. decimals() returns the inherited hard-coded 18 and never reads the DECIMALS constant that sizes TOTAL_SUPPLY. They agree today; a one-line override would bind them.
2. The standard ERC-20 approve race applies, since OpenZeppelin v5 dropped increaseAllowance/decreaseAllowance and no permit was added. Reproduced in the scratch test.

Coverage: all three listed entry points are marked holds, plus six invariant and dependency rows. Nothing in my area was left unreached. The aderyn large-literal lead on line 28 is the intended supply constant and was not promoted.

The review is complete and .imd-findings.json holds the result. No tracked file was changed.

Outcome: no defect in the Paperclash token. The three specialist findings were all reproduced and reduced to two info notes.

• Merged the approve-race reports from the economics and permissions specialists into one info finding. The race reproduces exactly as described in my scratch test. It is the inherent ERC-20 approve semantics of unmodified OpenZeppelin v5.4.0, exploitable only by a spender the holder already approved, so it stays info as a documented trust assumption.
• Kept the decimals coupling note at info. The inherited decimals() returns 18 from OpenZeppelin, and the constant that sizes the supply is 18 by convention. Deployed state is correct, so no action is required for this launch.
• Dropped the aderyn large-literal lead. The literal is exactly the required supply.

What I verified myself:

• The five vendored OpenZeppelin files hash byte-identical to the upstream v5.4.0 tag.
• The constructor takes no arguments and mints the whole supply to the deployer. The ABI exposes no mint, owner, pause or burnFrom path.
• Creation and runtime bytecode are far under the CREATE2 deployment limits, and the manifest's empty constructorArgs, supply, decimals, name length and field types are all valid.
• The repository's 45 existing tests and my 3 scratch tests pass.

Coverage: all three entry points answered as holds, plus three invariant rows. No proof files were needed since nothing reached high severity.