Implemented Paperclash with 1 billion CLASH, 18 decimals, minted once to the deployer. Includes the permanent social URL, vendored dependencies, and deployment documentation.

Validation passed: forge build, forge test with the required seed, and forge fmt --check. All 40 tests passed.

The README documents publishing the social link on the coin page; no deployment or external publication was performed.

Done. launch.json is written and is the only new file in the tree.

What the manifest describes

• Token contract Paperclash, name "paperclash", symbol "CLASH", 18 decimals, empty constructorArgs. The compiled ABI confirms the constructor takes no parameters.
• totalSupply is the constant the constructor mints to msg.sender: one billion tokens in base units.
• contracts is empty. The accepted tree has no application contracts, only the token.
• pool and economics are copied exactly as the launch gives them: native ETH, fee 12500, tick spacing 60, the one-to-one provenance price, and the requester's verbatim economics object.
• notes explain the plain fixed-supply ERC-20, that it needs no exemptions for the distributor, PoolManager or factory flows, and that the X link is served by the on-chain SOCIAL_URL() getter and must be copied into the coin page's social field.

Checks run

• forge build compiled cleanly with Solidity 0.8.26.
• forge test with the verifier's fuzz seed passed all 40 tests across both suites, including the invariant suite.
• A script compared the manifest against the compiled ABI and the job's economics: constructor arity, supply, economics and top-level keys all match, and notes are well under the 4000-character limit.
• git status shows only the untracked launch.json. No configuration, lib, or source file was touched.

The review is complete and .imd-findings.json is written with one info note and nine coverage rows. The tree is otherwise unchanged (the scratch test was removed).

Outcome: no permission defects in the Paperclash token. The access-control, trust-gap and asymmetry passes all come back clean.

What I verified:

• Permission map is empty. The constructor mints the full 1e27 supply to the caller and stores no owner, minter, pauser or initializer. The compiled ABI exposes only the ERC-20 functions plus two constant getters, with no receive or fallback.
• Guards are consistent. Balances are written only through _update, reached from transfer with from fixed to the caller, or from transferFrom behind the allowance check. Allowances are written only by the owner's own approve or by exact decrement on spend.
• No hidden privilege in the library. All five vendored OpenZeppelin files hash identically to upstream v5.0.2, so the inherited code is unmodified. The runtime contains no DELEGATECALL, CALLCODE or SELFDESTRUCT on any reachable path.
• Launch flows cannot be shorted. There is no fee, burn or exemption list, so the swarm share, pool seed and swaps move exact amounts. The existing 40 unit, fuzz and invariant tests pass with the pinned seed, and the formatter check passes.

The one item reported, at info severity, is the standard ERC-20 asymmetry between the two balance-moving paths. A caller with zero allowance can call transferFrom with value 0 against any holder and emit a Transfer event in that holder's name. No balance or allowance changes, and the README and the project's own test treat this as intended, so it does not need a fix before launch. I included it only to document the address-poisoning surface and a minimal optional override.

Coverage rows: all three listed entry points are answered, two as holds and transferFrom as finding 1. Six further rows record the constructor role handout, the absent admin surface, library integrity, opcode scan, launch flows and the not-yet-present manifest. The only thing not reachable here was the network's Uniswap v4 protected harness, which needs the factory and manifest environment the verifier supplies.

The economics review of the CLASH token is complete and .imd-findings.json holds the result.

Outcome: no economic defect found. The token is a plain OpenZeppelin v5.0.2 ERC-20 whose constructor mints the full 1e27 supply to the deploying caller. The six vendored OpenZeppelin files are byte-identical to the upstream v5.0.2 archive, which I downloaded and diffed. The compiled ABI exposes only approve, transfer and transferFrom as state-changing entry points, with no receive or fallback.

What I checked against the Economic Security, Invariant and Flow Gap guides:

• Supply invariant. The only mint is in the constructor. No burn, owner, admin or mint selector exists, so supply cannot grow after launch.
• Conservation. Sum of balances equals totalSupply under the project's invariant suite and my own scratch fuzz test.
• Launch flows. The 10% swarm, 80% pool and 10% remainder splits of 1e27 divide with no dust, and every transfer and transferFrom moves exactly the stated amount with no fee, callback or caller-dependent branch. Buy, sell and claim paths cannot arrive short.
• Token misbehaviour classes. No fee-on-transfer, rebase, pause, blacklist, void return or sentinel-address surprises. Zero-address sender, receiver and spender all revert.
• Runtime. An opcode-aware scan of the compiled runtime finds no reachable DELEGATECALL, CALLCODE or SELFDESTRUCT. Decimals are 18 and the social URL constant matches the brief.
• Static-analysis lead. The aderyn large-literal note is the supply constant, which equals exactly 1e27. Not a defect.

One informational finding was recorded, outside my area. The vendoring note in lib/VENDORED.md says sources are unchanged from upstream, but seven forge-std files were reformatted after vendoring and fail the repository's own checksum file. The differences are whitespace only and affect test tooling, not the token bytecode. Running sha256sum -c lib/SHA256SUMS reproduces it.

Coverage has rows for all three listed entry points, all marked holds, plus seven invariant and flow rows. The project suite of 40 tests and my 5 scratch tests all pass. I could not run the protected Uniswap v4 harness locally because v4-core is not vendored, which I noted in the coverage record. No repository files were changed. The scratch test lives in test/scratch/, which is not kept.

The review is complete and .imd-findings.json is written at the repository root with one finding and nine coverage rows. The working tree is otherwise unchanged.

Outcome. The Paperclash token is sound under all three control-flow lenses. It is a 20-line contract that inherits OpenZeppelin v5.0.2 ERC20 without overrides and mints 1e27 base units to the creating caller in its constructor. I found no defect in the token's code.

What I checked

• Execution Trace. Traced approve, transfer and transferFrom through the inherited code to storage. Zero-address checks, balance and allowance checks, and the unchecked arithmetic are all sound. transferFrom spends the allowance before moving the balance, and a revert in either step rolls back both. Infinite allowance never decrements, which is standard ERC-20 behaviour.
• Periphery. I downloaded the upstream OpenZeppelin v5.0.2 archive and confirmed all six vendored files, including the inherited ERC20.sol, are byte-identical to upstream. No libraries, external calls or callbacks exist in the token.
• First Principles. Name, symbol, 18 decimals, exact supply and the social URL constant all match the brief. The contract identifier fits the 32-byte manifest limit. The constructor is non-payable and takes no arguments, so there is no manifest ordering risk.
• Launch floor. A scratch test modelled the factory deploying via CREATE2, moving the 10/80/10 splits exactly, and scanned the reachable runtime for DELEGATECALL, CALLCODE, SELFDESTRUCT and external calls. None are present. ETH and unknown selectors revert. The project's own 40 tests pass with the pinned fuzz seed and forge fmt --check is clean.

The one finding (low). Seven vendored forge-std files fail the repository's own sha256sum -c lib/SHA256SUMS, contradicting the VENDORED.md statement that sources are unchanged from upstream. The differences are whitespace-only reflows and affect test tooling only, not the deployed bytecode. The fix is to restore the upstream bytes or regenerate the checksum file and reword the claim.

Not in the findings file. The README states the chain is Ethereum mainnet, which the job text does not specify. That is a documentation assumption with no failing input, so I left it out of the report and note it here for the judge.

Coverage. All three listed entry points plus the constructor are marked holds. Additional rows cover the fixed-supply invariant, the forbidden-opcode scan, the vendored-source check (marked finding), the metadata requirements and the aderyn literal lead. I could not run the protected Uniswap v4 harness because v4-core is not vendored here, so the actual seed and swap were modelled with plain transfers rather than executed.

The review is complete. The findings file is valid, the one cited snippet matches the tree line for line, and no tracked file was changed (only the ignored scratch test and the findings file were written).

Outcome: no math defects found in the Paperclash token. The contract is 20 lines over unmodified OpenZeppelin v5.0.2 ERC-20, and nothing in the Math Precision, Boundary or Numerical Gap guides has a surface to act on.

What I checked in my area:

• Supply constant and mint. The constant evaluates at compile time to exactly 1e27, which divides by 10^18 into one billion whole tokens with no remainder. The single checked _mint from zero cannot overflow, and no mint or burn path exists in the ABI.
• Transfer and transferFrom arithmetic. Both unchecked subtractions in OpenZeppelin's _update and _spendAllowance sit behind an explicit less-than revert. The unchecked credit cannot overflow because the sum of balances always equals total supply. I probed exact balance, balance plus one, max uint, zero, self-transfer of the whole balance, a max-minus-one allowance (it decrements and cannot wrap into the infinite sentinel), and revert atomicity.
• Launch split. The 10/80/10 split of 1e27 in basis points leaves no rounding residue and no intermediate overflow. The token has no tax, so each launch flow moves exactly what it says.
• Boundaries. There are no external calls, no payable path (plain and data-carrying ETH sends revert), no bytes decoding, no division, no downcast and no scale conversion.
• Tooling evidence. All five vendored OpenZeppelin files hash byte-for-byte to upstream v5.0.2. The project suite passes (40 tests, invariants across 8192 handler calls with zero reverts), as do my seven scratch probes. The aderyn large-literal lead is style only.

One info-level finding outside my area is recorded: seven vendored forge-std files fail the checksum list the README points to. They differ from upstream v1.9.7 only in whitespace, so this is a documentation and provenance nit with no effect on the deployed token. The reproduction is a single sha256sum -c lib/SHA256SUMS command.

Coverage: all three entry points are marked holds, plus five invariant and boundary rows. Nothing was left unreached.

Added 14 tests and strengthened stateful invariants covering failure rollback, allowance boundaries, and transfer properties.

Offline forge build and forge test pass with the required seed: 54 tests passed, including 32,768 invariant calls.

Only test/ changed. No contract defects found.

The review is complete and .imd-findings.json is written. The working tree is otherwise clean, with the scratch test removed.

Outcome. The token is a 20-line, unmodified OpenZeppelin v5.0.2 ERC-20 with no constructor arguments, no owner, and a single constructor mint. No specialist found a code defect, and my own pass agrees. Two findings are kept, both reproduced.

• Low, merged from three specialists. The vendoring statement in lib/VENDORED.md claims all sources are unchanged from upstream, but seven forge-std files were reformatted after vendoring. Running the checksum file from the repository root fails on those seven. I confirmed against the raw upstream file for Vm.sol that the difference is whitespace only. All six OpenZeppelin files hash to upstream, so the deployed bytecode is unaffected. This is a provenance defect in test tooling, not a token defect.
• Info, from the permissions specialist. A zero-value transferFrom with no allowance succeeds and emits a Transfer event naming another holder. I reproduced it with a scratch test. It is standard ERC-20 behavior, documented as intended in the README and the repo's own tests, with no balance or supply effect.

Coverage. All three ABI entry points are answered. Approve and transfer hold. TransferFrom points at the info finding. I also recorded the supply invariant, the opcode and size checks, the manifest, and the aderyn lead as holding.

Verification done. The repo's own 54 tests pass. A PUSH-aware scan of the compiled creation and runtime code finds no DELEGATECALL, CALLCODE or SELFDESTRUCT. The manifest matches the source: empty constructorArgs for a zero-parameter constructor, totalSupply equal to the minted constant, name and symbol identical. The protected floor tests could not run here because they import the launch harness that is not in this tree, so their result rests on the verifier's run.

No critical or high finding exists, so no proof test was required.