Implemented PAPERCLASH with 18 decimals and exactly 1,000,000,000 tokens minted once to the deployer. No additional minting or admin powers.

Dependencies are vendored for offline builds. README documents assumptions, deployment parameters, and operational responsibilities.

Validation passed:

• forge build
• forge test: 34 tests, including fuzz and stateful invariants, using the supplied seed
• forge fmt --check

I found no math defects in PAPERCLASH, so .imd-findings.json holds an empty findings list plus a coverage record for every listed entry point. I changed no other files.

What the token is: src/PAPERCLASH.sol is a plain OpenZeppelin v5 ERC-20 with nothing overridden. Its constructor mints INITIAL_SUPPLY = 1_000_000_000 * 10 ** 18 once to msg.sender. It has no custom transfer logic, fees, burns, rounding or privileged functions.

Math Precision, Boundary and Numerical Gap passes:

• Supply: 10^27 fits easily in a uint256, and the 10^18 scaling matches decimals() == 18. No path mints or burns after deployment, so the supply cannot change.
• Unchecked arithmetic in _update: the subtraction is protected by a value <= fromBalance check. The recipient's addition is capped by the fixed total supply, so it cannot overflow.
• Allowances: _spendAllowance checks the allowance before its unchecked subtraction. The maximum uint256 value means "unlimited" and is never decreased, which is the intended behaviour.
• Edge inputs: zero-value transfers, self-transfers, transferring an exact full balance or allowance, and amounts one above them all behave as standard ERC-20. Transfers move exactly the stated amount, so the launch flows (factory to distributor, pool seeding, swaps) cannot arrive short.
• Static-analysis lead: aderyn's "large numeric literal" note at line 12 is a style note. The constant is correct, so I didn't report it.

Coverage: holds for approve, transfer and transferFrom, plus two invariants: the supply stays at exactly 1e27, and the sum of balances equals the total supply.

Checks run: the project's own suite passes, 34 of 34 tests including the invariant suite. I didn't run the protected floor tests. They import harness files (src/LaunchLiquidity.sol, the floor OwnerChecks.sol) that aren't in this tree, so the verifier's environment has to run them.

Outside my area: the token has no owner and no privileged calls, so the other specialists have little to examine there.

Done. I wrote launch.json for the PAPERCLASH custom token launch, and it is the only file changed.

What the manifest says

• Token: contract PAPERCLASH, name and symbol PAPERCLASH, 18 decimals, empty constructorArgs. The accepted constructor at src/PAPERCLASH.sol:15 takes no parameters and mints the whole supply once to msg.sender.
• totalSupply: 10^27 minor units, matching the constant INITIAL_SUPPLY and the one billion token brief.
• Contracts: an empty list. The accepted tree has no application contracts, only the token and local test fixtures.
• Pool and economics: copied verbatim from the launch reference. Native ETH pair, fee 12500, tick spacing 60, the provenance-only initial price, and the requester's economics object.
• Notes: a plain-language description of the token's behavior and the launch flows, well under the limit.

Verification

• A scratch script in test/scratch checked the manifest's keys, types, lowercase addresses, supply, and the verbatim economics object. It passed.
• forge build compiled cleanly.
• forge test with the verifier's fuzz seed passed all 34 tests across both suites.
• git status shows only launch.json as new. No configuration, lib, or workflow files were touched.

I added test/PAPERCLASH.adversarial.t.sol, which brings the suite from 34 to 46 tests. forge build succeeds and forge test passes all 46 when run with the verifier's fuzz seed.

What I found: no defects, so I wrote no .imd-findings.json. src/PAPERCLASH.sol is a plain OpenZeppelin v5.0.2 ERC20. It has a constant supply of 1,000,000,000 × 10¹⁸ minted once to whoever deploys it, and nothing else: no owner, no mint or burn, no pause, no way to receive ETH.

What was already there: an earlier contributor's 33 unit and fuzz tests and one invariant suite. I left them unchanged.

What I added:

• Fuzz tests on the paths that must fail:

  • Any caller pulling tokens without an allowance reverts, and so does any empty account sending a positive amount.
  • A pull above the holder's balance reverts even with an unlimited allowance.
  • approve sets exactly the value given, for any owner and spender pair.
  • Chained transfers keep the total equal to the supply.

• Pinned edge cases:

  • Transfers of exactly one wei, and a one-wei overspend that reverts.
  • Spending an allowance emits only a Transfer event, with no Approval.
  • An allowance of max − 1 is treated as finite and goes down when spent.
  • transferFrom from the zero address and approve called by the zero address both revert.
  • Two tokens deployed by the same factory are independent, and reusing a salt fails.

• An invariant suite over random call sequences. The token is deployed through the factory, as the launch does it. Six actors take part: the factory, a distributor, a pool manager, two traders and the token's own address. Ordinary transfers and approvals are mixed with calls that must fail:

  • spending above a balance or an allowance;
  • sending to, or approving, the zero address;
  • mint, burn, burnFrom, pause, blacklist and seize, which the token does not have.

  Each failing call is checked to revert. After every sequence, balances and allowances must match a separate record kept by the test, the balances must add up to the full supply, and the name, symbol, decimals and supply constant must be unchanged. It runs 16,384 calls with no unexpected reverts.

One test failed on my first run, and the fault was in my test rather than the token. A zero-amount transferFrom from the zero address reverts with ERC20InvalidApprover, not the ERC20InvalidSender I had expected. That's because OpenZeppelin 5.0.2 writes the allowance back even when the amount is 0. I corrected the expected error; the call reverts either way, which is the correct behaviour.

The new file is in the working tree but not committed.

The review is complete and written to .imd-findings.json. No tracked files were changed; the only writes were the findings file and a scratch test under test/scratch/, which is ignored by git.

Result: the permission model holds. PAPERCLASH is an unmodified OpenZeppelin v5.0.2 ERC20 with a single constructor mint of 1e27 to msg.sender. I found no access control, trust gap or asymmetry defect.

What I checked in the assigned area:

• Access control. The compiled ABI exposes exactly approve, transfer, transferFrom and views. There are no roles, modifiers, initializers, owner, upgrade path, delegatecall, receive or fallback. A scratch test fired 22 admin-style selectors from both the deployer and a stranger. All reverted and supply and balances were unchanged.
• Trust gap. The deployer, which is the factory at launch, has no standing over a holder's balance once transferred. A transferFrom without allowance reverts for the deployer like anyone else. There is no fee, oracle, setter or exemption list for any seam to live in.
• Asymmetry. transfer and transferFrom share the same internal path. Finite allowances decrement exactly and the max allowance is infinite. The vendored OpenZeppelin files, including Context's msg.sender resolution, hash-match the pinned release.
• Supply. The project's 34 tests, its stateful invariant suite, and my 5 scratch tests all pass. The aderyn large-literal lead is a style note only.

Two info-level items are recorded, neither a blocking defect:

1. The documented provenance check fails. Running sha256sum --check DEPENDENCIES.sha256 reports 7 forge-std files as mismatched. Those files are test-only and not in the token bytecode, but the hash file or vendored copy should be refreshed so the instruction holds.
2. The standard ERC-20 approve race exists, as inherent to the requested design and already documented in the README. It is listed so the trust assumption on approved spenders is explicit.

Coverage rows answer all three listed entry points as holds, plus rows for the constructor, the access surface, the trust gap seams, asymmetry pairs and the supply invariant.

The review is complete and the findings file is written and valid. The working tree is unchanged apart from the findings file and my scratch test, both of which are not part of the submission.

Outcome: no economic defect found in the token. PAPERCLASH is an unmodified OpenZeppelin v5.0.2 ERC-20 with a single constructor mint, and every failure mode in the Economic Security, Invariant and Flow Gap guides either has no surface here or is guarded by code I traced and exercised.

What I checked and how:

• Economic Security. No external dependencies, oracles, callbacks or fee/rebase/blacklist/pause behaviour exist. Sentinel paths were probed: transfer to the zero address, transferFrom from the zero address with zero and nonzero value, and approve from the zero address all revert without touching state.
• Invariant. The sum of balances always equals the total supply of 1e27, because only the internal update function writes supply, the only mint is in the constructor, and burn is unreachable from the ABI. The project's stateful invariant suite and my scratch probe both confirm it. Allowance boundaries hold: the maximum allowance is sticky, a finite one cannot underflow, and failed transfers restore allowance.
• Flow Gap. The launch legs move exact amounts: factory to distributor, distributor to claimant, pool manager to trader and back through approve plus transferFrom. The opening economics of 80% single-sided at a 10 ETH cap sit comfortably inside Uniswap v4 price, tick and liquidity bounds, and nothing in the token can distort them.
• Outside my area, cheaply verified. The compiled runtime has no DELEGATECALL, CALLCODE or SELFDESTRUCT on reachable paths, the ABI has no privileged function, and the five vendored OpenZeppelin files are byte-identical to the upstream v5.0.2 tag fetched from GitHub.

One informational finding was recorded. The repository's own provenance check, sha256sum --check DEPENDENCIES.sha256, fails on seven forge-std files that were reformatted after the hash file was written. The difference is whitespace only, forge-std is test-only, and the token bytecode is unaffected, so it is a documentation defect rather than a security one.

Coverage: all three listed entry points are marked as holding, with six additional invariant rows. The protected floor tests could not be executed locally because v4-core and the harness environment are not vendored, so that row rests on tracing rather than a run.

I found no defects in PAPERCLASH that block the launch. I kept one info-level finding about the documentation and dropped the rest. Everything is written to .imd-findings.json and no other file was changed.

The token itself. src/PAPERCLASH.sol is a plain OpenZeppelin v5.0.2 ERC20 with nothing added. Its constructor mints 1,000,000,000 tokens (1e27 smallest units) once to the deployer. There is no owner, mint, burn, fee, pause or external call. I compared the vendored ERC20.sol with the upstream v5.0.2 file and they are byte-identical. forge build succeeds, the contract is small (1,814 bytes deployed, 2,708 bytes creation code), and all 46 existing tests pass. launch.json agrees with the code: no constructor arguments, the same total supply, 18 decimals and a valid contract name.

Specialist findings:

• Kept, merged into one (info): three specialists reported the same problem. DEPENDENCIES.md line 30 says the bundled third-party files are unmodified, but sha256sum --check DEPENDENCIES.sha256 fails for 7 forge-std files. I re-ran the check and got the same 7 failures. The specialists found that the only differences are line-wrapping from a formatter. forge-std is only used by tests, and every OpenZeppelin file passes, so the deployed token is unaffected.
• Dropped: the approve front-running note. Spending the old allowance before a new one lands is how every standard ERC-20 behaves, it's what the brief asked for, and the README documents it.
• Dropped: aderyn's "large numeric literal" warning. The literal is the intended supply constant, not a defect.

Coverage: I traced all three entry points (approve, transfer, transferFrom) myself and each holds. I also recorded two invariants as holding: the fixed supply minted to the deployer, and that the factory can deploy the contract. I didn't write a Foundry test as proof, since that is only required for critical or high findings.