The Paperclash token project is complete and verified. All three required checks pass: forge build, forge test, and forge fmt --check, with the compiler pinned to 0.8.26 and bytecode_hash = "none".

What was built

• src/PaperclashToken.sol is a fixed-supply ERC-20 named Paperclash with symbol PAPER. The constructor mints 1,000,000,000 tokens at 18 decimals once to the deployer, which is the launch factory. It inherits OpenZeppelin ERC20 and ERC20Permit only. There is no owner, mint, pause, blacklist, tax, burn-from or upgrade path, and the contract takes no constructor arguments.
• script/DeployPaperclash.s.sol separates a plain deploy() function from the broadcasting run(). It reads no environment variables.
• test/PaperclashToken.t.sol holds 33 tests: metadata and supply, exact transfers, allowance paths, permit success and failure (expired, wrong signer, replay), reverts for insufficient balance, zero receiver and missing allowance, a probe of 24 common admin selectors from both a stranger and the deployer, a bytecode walk for DELEGATECALL, CALLCODE and SELFDESTRUCT, launch-flow tests that the swarm share and the full split arrive whole, and four fuzz tests.
• README.md documents assumptions, the deployment parameters for the manifest step, the no-op "After launch" responsibilities and the security posture.
• lib/ vendors forge-std v1.11.0 and OpenZeppelin Contracts v5.4.0 as ordinary files, fetched from GitHub release tarballs. No submodules and no git metadata remain.

Verification

• Tests ran with an empty environment and the verifier's fuzz seed. All 33 passed, reproduced after a clean rebuild.
• The protected floor test's requirements are covered: supply minted whole to the deployer, decimals 18, no supply growth, no privileged hand over holder balances, and no forbidden opcodes in reachable runtime.

Not done and why

• Slither is not installed on this machine, so it did not run. The code avoids the six blocking detector patterns by construction.
• No launch.json or .imd-blocked.json was written. The manifest is IMD's step, and nothing in the brief required requester input.
• Nothing was committed, since the brief did not ask for a commit. The new files are untracked in the working tree, ready for the submission step.

Done. I wrote launch.json for the Paperclash (PAPER) custom token launch, and it is the only file changed in the working tree.

What the manifest says

• Kind is custom_token. The token contract is PaperclashToken, name Paperclash, symbol PAPER, 18 decimals.
• constructorArgs is empty, matching the accepted constructor, which takes no parameters and mints the whole supply to msg.sender.
• totalSupply is the 1,000,000,000 tokens in minor units exactly as the constructor mints them.
• contracts is empty. The accepted tree has no application contracts, only the token.
• pool and economics are copied verbatim from the launch terms: IMD pair at the given address, fee 12500, tick spacing 60, the one-to-one provenance price, and the requester's poolBps, opening cap and remainderTo.
• notes describe only PaperclashToken and come to well under the 4,000 character limit.

Verification

• The manifest parses as JSON with only the schema's top-level keys.
• The compiled ABI confirms zero constructor parameters, matching the empty constructorArgs.
• forge build succeeded, and the existing suite of 33 tests passed with the verifier's fuzz seed.
• A scratch test deploying the token from a stand-in factory confirmed name, symbol, decimals, supply and that the whole balance lands on the deployer.
• git status shows launch.json as the only new or changed path.

Private list: nothing remains. The report is written and validated, the ABI confirms exactly the four listed state-changing entry points, the full suite passes, and the tracked tree is clean, so no further tool calls are needed.

Review complete: no defects found in the assigned economics area. .imd-findings.json holds {"findings": []} plus eight coverage rows, all holds.

What I verified:

• Supply and conservation. The constructor's single _mint of 1_000_000_000 * 1e18 is the only supply-increasing path. _mint, _burn and _update are internal; no public mint or burn exists and probing the common admin selectors from stranger, holder and factory leaves totalSupply at 1e27. Fuzzed conservation across 256 runs and seven accounts holds.
• Launch flows. The 10/60/30 split is integer-exact (1e26 + 6e26 + 3e26 = 1e27), so the factory keeps zero dust. The token moves exactly the requested amount with no fee, rebasing, hook, or callback, so the swarm share, pool seed and remainder all arrive whole.
• Entry points. approve, permit, transfer and transferFrom are the only state-changing functions in the compiled ABI. The inherited OpenZeppelin code is pristine 5.4.0: zero-address rejection, allowance spend before transfer with atomic revert, low-s ECDSA, per-owner nonce, and an EIP-712 domain bound to "Paperclash", the chain and the contract address. Infinite allowance is not decremented, as documented.
• Manifest inputs. decimals() is 18 and totalSupply() is exactly 1000000000000000000000000000, matching the objective.

Evidence: the project's 33 tests pass, and my independent scratch invariant suite (4 tests, gitignored under test/scratch/) passes. Runtime is 3,829 bytes, well under EIP-170, and the tracked tree is unmodified.

Limitations: the protected floor tests cannot run here because they import v4-core and read IMD_* environment variables that this workspace lacks, so I traced their flows statically rather than executing them. The aderyn "large numeric literal" lead at src/PaperclashToken.sol:25 is a false positive: 1e27 fits uint256 and is the intended supply. I could not cross-check the README's pool and economics values against the job, because the supplied objective states no economics and no launch.json exists yet; the manifest step copies those from the job, so that is not a contract defect.

The review is complete. The findings file is valid JSON and the working tree is clean apart from the ignored scratch directory.

Result: no defects found in the math, boundary or numerical-gap areas. .imd-findings.json holds an empty findings list and seven coverage rows, all holds.

What the token is. src/PaperclashToken.sol is 31 lines: OpenZeppelin v5.4.0 ERC20 plus ERC20Permit, a constant supply of 1e27 minted once to msg.sender, no owner, no custom arithmetic, no external calls, no payable functions.

What I checked, per guide:

• Math Precision. The only arithmetic the project adds is the supply literal, which the compiler folds to exactly 1e27. That is the aderyn large-literal lead, and it is not a defect. The supply divides every launch basis-point split with zero remainder, so swarm, pool and remainder shares are exact. Balance writes in OpenZeppelin's _update are bounded by the supply and cannot overflow.
• Boundary. Full-supply, supply-plus-one, max-uint, zero-value and self transfers behave as ERC-20 specifies. The allowance sentinel is exactly max-uint, and max-minus-one is decremented. Permit accepts a deadline equal to the current timestamp, rejects high-s and bad v values, rejects zero owner or spender, bumps the nonce only on success, and rebinds its domain separator on a chain-id change.
• Numerical Gap. The sum of balances equals the total supply under fuzzing, and no post-constructor path can change the supply.

Library integrity. I hashed every vendored OpenZeppelin file on the import graph against the upstream v5.4.0 release. Ten are byte-identical. ERC20Permit, ECDSA and IERC20Permit differ only in forge fmt line wrapping, which I diffed.

Evidence. The project's 33 tests pass, and my 15 scratch tests in test/scratch/MathBoundary.t.sol pass. That directory is git-ignored and nothing in it is submitted.

Not reported. Standard ERC-2612 permit front-running, where a third party submits a signed permit early and causes an integrator's bundled call to revert, is a known property of every OpenZeppelin permit token, causes no loss, and is outside the math area. The judge may want it noted as an integration caveat only.

The review is complete. The findings file is written and validated, the scratch test is removed, and no tracked file was changed.

Outcome: no permission defect in Paperclash. The token is OpenZeppelin v5.4.0 ERC20 plus ERC20Permit with a constructor that mints the fixed supply to the deployer and nothing else. The findings file holds one informational item and nine coverage rows, all four verifier entry points answered.

What I checked, per guide:

• Access Control. No role, modifier, initializer, setter, proxy, delegatecall, receive or fallback exists. The compiled selector list is exactly the ERC-20 and ERC-2612 surface plus three constants. The deployer has no bypass: a transferFrom from the deployer without allowance reverts. Internal mint, burn and approve paths are unreachable from outside.
• Trust Gap. The only privileged moment is the constructor, which mints to msg.sender, matching the brief. The deployer afterwards is an ordinary holder. permit is bound to owner, spender, value, nonce, deadline, chain id and contract address, and the library rejects high-s and zero-recovery signatures.
• Asymmetry. approve and permit both refuse a zero spender and write the same slot with the same semantics. transfer and transferFrom share one unmodified _update path with no tax, hook or exemption, so every launch flow moves exactly what it says.

Supply chain check. The vendored OpenZeppelin library is plain files, so I compared every file in the token's compile set against the upstream v5.4.0 tarball. All are byte-identical or differ only by the project formatter's reflow. The mocks directory was dropped and nothing was added.

The one reported item is informational. Anyone may submit a signed permit, so a front-runner can consume the owner's nonce first and make the spender's own bundled permit plus transferFrom revert. The allowance still lands and nothing is lost. This is standard ERC-2612 behaviour, so the token needs no change, but the README could warn integrators to wrap permit in try/catch.

Static analysis leads. Slither reported nothing. Aderyn's large-numeric-literal note on the supply constant is a style remark. The constant equals 1e27 and the project tests assert it.

Not reached. Nothing in my area was left unverified. Launch-manifest fields, pool economics and the factory's own code are outside this repository and were not reviewed.

Review complete. The control-flow audit of the Paperclash token found no defects; the findings file holds one informational note and full coverage.

What I checked (Execution Trace, Periphery, First Principles)

• All four entry points trace clean. approve, permit, transfer and transferFrom go straight into unmodified OpenZeppelin 5.4.0 code. Every guard is in place: zero-address checks, exact balance and allowance reverts, nonce consumption before signature recovery, high-s and bad-v rejection, deadline handling, and chain-id rebinding of the EIP-712 domain. Verified with 15 scratch tests plus the project's 33 existing tests, all passing.
• Periphery is pristine. The vendored OpenZeppelin tree differs textually from the npm 5.4.0 tarball, but only by forge-fmt reflow. Compiling the token against the pristine upstream library produced byte-identical creation and runtime bytecode.
• First principles hold. The constructor mints exactly 1e27 to msg.sender once, there are no constructor arguments, no owner, no mint or privileged path in the ABI, no receive or fallback, and no transfer hook. Every launch flow is an exact ordinary transfer.
• Static-analysis leads (aderyn large-numeric-literal) confirmed benign: the literal equals 1e27 as the brief requires.

Recorded

• One info note: a third party can relay a holder's permit signature first, so an integrator that bundles permit and transferFrom in one transaction reverts. This is standard ERC20Permit behaviour, not a token defect, and is recorded for integrator documentation only.
• Nine coverage rows, all holds: the four listed entry points plus the constructor, vendored-library integrity, opcode and fallback surface, launch-flow exactness, and the deploy script.

Scratch tests were removed and no repository file was changed. Findings are in .imd-findings.json at the repository root.

I've added two new test files for Paperclash (PAPER). forge build succeeds, and forge test passes 65 of 65 tests with the verifier's fuzz seed. I found no defects, so there is no .imd-findings.json.

The token is a plain OpenZeppelin 5.4 ERC-20 with gasless approvals by signature (permit). It mints 1,000,000,000 × 10¹⁸ once to the deployer and has no owner, mint, tax or freeze functions. The existing test/PaperclashToken.t.sol already covered metadata, the mint, the main transfer and allowance failures, permit basics, the absence of admin functions, and the launch split, so I left it unchanged and built on it.

test/PaperclashToken.invariant.t.sol: random call sequences over the token.

• A handler drives transfer, approve, transferFrom, permit (with real signatures, sometimes replaying an old nonce) and time jumps. It uses six actors, including the contract that deployed the token and holds the supply.
• Amounts sometimes go one wei past what is allowed, so calls that should fail are made too. The handler keeps its own record of expected balances, allowances and nonces.
• After every call these must hold:
  • the total supply never changes;
  • the actors' balances add up to the whole supply;
  • every balance, allowance and nonce matches the handler's record;
  • no call succeeded that should have failed, or failed that should have succeeded;
  • nothing ends up on the token contract or the zero address.
• An end-of-run check fails if no transfer succeeded, so a run that moves nothing can't pass. Settings: 256 runs × 64 calls, set in the file.
• I also confirmed in a throwaway copy that every run reaches the calls that should fail.

test/PaperclashToken.edges.t.sol: 31 edge-case unit and fuzz tests.

• Amounts: moving the whole supply in one transfer, then one wei more; the full supply plus one wei; the maximum uint256.
• Odd senders and recipients:
  • transfers to yourself, and pulling from yourself, which still needs an allowance;
  • the zero address as recipient or as owner;
  • zero-amount pulls, which need no allowance.
• Allowances: a new approval replaces the old one rather than adding to it; setting zero revokes; spending exactly to zero; allowances are per spender; an unlimited allowance is still capped by the balance.
• Permit:
  • the signing domain is the standard one, and it changes when the chain ID changes, so a signature from one chain doesn't work on another;
  • a permit works exactly at its deadline and fails one second after;
  • it rejects the high-s variant of a valid signature, an invalid v, any edited field, a future nonce, and nonces used out of order;
  • it rejects a zero spender (without using up the nonce) and a forged signature for the zero address;
  • fuzzed: the value set is exact, and a signature from any other key fails.
• Failed calls: a fuzz test checks that a failed transferFrom leaves balances and allowances untouched.

One test asserts behaviour you might not want: tokens sent to the token contract's own address are accepted and can never be recovered. That is normal for an ERC-20 and not a defect, but the test makes any change to it a deliberate one.

Not committed: git has no author identity set on this machine, so the commit failed. The two files are staged in test/ and nothing outside test/ was changed.

The review is complete and the findings file is written. Nothing else depends on further tool calls.

Outcome: the Paperclash token has no defects that block the launch. The findings file holds one merged info-level note and a nine-row coverage record, with all four entry points answered.

What I verified against the code

• The token is OpenZeppelin v5.4.0 ERC20 plus ERC20Permit with no overrides, no owner, and no mint, burn, pause or blacklist path. The constructor is the only mint and it mints exactly the manifest supply to the deployer.
• The vendored OpenZeppelin files hash-match upstream v5.4.0 for ERC20, EIP712 and Nonces. ERC20Permit and ECDSA differ only in line wrapping.
• Runtime bytecode contains no DELEGATECALL, CALLCODE, SELFDESTRUCT or CALL. Creation and runtime sizes are far below the protocol limits, and the constructor takes no arguments, so the factory's CREATE2 deployment works.
• The manifest uses only schema keys, correct value types, lowercase addresses, an empty constructor argument list matching the parameter list, and a supply equal to what the constructor mints.
• The project's 65 existing tests pass. The aderyn large-literal lead is a style note with no defect behind it.

Specialist findings: the audit_flow and audit_permissions reports described the same root cause, the inherent ERC-2612 permit relay behaviour. I merged them into one info finding, reproduced it with a scratch test that I ran and then deleted, and kept it at info because no funds are lost, misdirected or frozen. The math, economics and tester reports had no findings, and I found nothing they missed.

The working tree is unchanged apart from the findings file.