Implemented Pepe2Pepe (P2P): 1 billion tokens with 18 decimals, minted once to the deployer. No admin powers or additional minting.

Included vendored dependencies, 20 passing tests, and deployment/operational documentation in README.md.

Verified with Solidity 0.8.26:

• forge build
• forge test using the specified fuzz seed
• forge fmt --check

Wrote launch.json for the Pepe2Pepe (P2P) custom token launch. It is the only file added, and the tree is otherwise untouched.

What the manifest says, matched against the accepted source in src/Pepe2Pepe.sol:

• Token: contract Pepe2Pepe, name Pepe2Pepe, symbol P2P, 18 decimals. The constructor takes no parameters, so constructorArgs is empty. totalSupply is the exact constructor mint to msg.sender, 1,000,000,000 tokens in minor units, as a decimal string.
• Contracts: empty. The accepted tree contains only the token, so no application contracts are named.
• Pool: IMD pair address, fee 12500, tickSpacing 60, and the one-to-one initialPrice, exactly as the launch reference gives them.
• Economics: copied verbatim from the job.
• Notes: a short description of the fixed-supply token and the absence of fees, admin paths and application contracts.

Checks run:

• forge build compiles cleanly.
• forge test with the verifier's fuzz seed passes all 20 tests.
• A scripted read of the manifest confirmed only the schema keys are present, strings for every uint256 and address, numbers for fee, tickSpacing and decimals, lowercase addresses, and notes well under the limit.

The protected tests will deploy the token from its creation code with empty constructor arguments and expect the supply stated here, which the constructor mints to the factory once with no path to grow it.

The review is complete and the findings file is in place.

Result: no defects found. .imd-findings.json holds an empty findings list and six coverage rows, all holds.

What the token is. src/Pepe2Pepe.sol is a 15-line contract inheriting the vendored OpenZeppelin v5.1.0 ERC20. The constructor takes no arguments, makes no external calls and mints exactly 10^27 base units to msg.sender once. There is no mint, burn, owner, pause, blocklist, fee, hook, proxy or selfdestruct path.

What I verified.

• Traced approve, transfer and transferFrom through the vendored _approve, _spendAllowance, _transfer and _update: every revert path, state write and event matches the standard, and the unchecked arithmetic cannot wrap because supply is fixed.
• Read the five vendored library files line by line. The logic is unmodified v5.1.0 and _msgSender returns msg.sender. A byte-for-byte diff against the tag was not possible offline since the local mirror is v5.7.0.
• Ran the project suite (20 tests pass) and a scratch suite of my own: a factory contract deploying the token receives the whole supply and the origin nothing, decimals are 18, flows move exactly the requested amount, finite allowances decrement, max allowances persist, a holder cannot transferFrom its own balance without allowance, and sum of balances equals total supply under 2,000 fuzz runs.
• Scanned the runtime bytecode. It is 1,752 bytes with no DELEGATECALL, CALLCODE or SELFDESTRUCT.
• Checked the aderyn lead at line 10. The literal evaluates to exactly 10^27, matching the brief.

Not reached. The network's protected custom-token tests import factory sources and v4-core that are not in this tree, so I could not run them directly. Their checks were reproduced by equivalent scratch tests instead, and that limitation is recorded in the file's notes.

The scratch test directory was removed. No tracked file was changed.

The review is complete. The token is clean in the assigned area, and .imd-findings.json holds an empty findings list with a full coverage record.

What I checked

• The token is a two-line subclass of OpenZeppelin ERC20 v5.1.0. I diffed the five vendored library files and the license against the upstream tag; all are byte-identical, so the whole transfer path is stock code.
• Economic Security guide: no fee, burn, rebase, pause, blacklist, owner, or external call exists, so there is no dependency to break, no amount mismatch, no sentinel abuse, and no ERC-20 query that diverges from execution.
• Invariant guide: the only writer of total supply is the single constructor mint. I probed fourteen common mint, admin, freeze, and upgrade selectors from the factory address and every one reverts. Balance conservation held after every flow.
• Flow Gap guide: I simulated the launch as the factory performs it in a scratch test. The swarm share, the claim, a PoolManager-style pull of the pool share through transferFrom, the remainder transfer, and a buy and sell each arrived exact, with allowance consumed exactly.
• Floor requirements: the runtime contains no DELEGATECALL, CALLCODE or SELFDESTRUCT, is well under the EIP-170 limit, has no receive or fallback, and mints the full supply to the deploying contract rather than the transaction origin.
• The project's own 20 tests pass with the README's fuzz seed, and the source passes the formatter check.

Leads I deliberately left out

• The ERC-20 approve front-running race is inherent to the standard and documented in the README. It is not a defect in this code.
• The aderyn large-numeric-literal note is a style lead with no behavioral effect. The constant equals ten to the twenty-seventh, which matches the stated supply.

Coverage

All three entry points are marked holds, with five further rows for the invariants and the manifest expectation. No launch.json exists yet, which is expected at this stage. When one is written, the constructor takes no parameters, so its constructorArgs must be empty and totalSupply must be exactly 1000000000000000000000000000. The scratch test directory was removed, leaving the tree unchanged apart from the findings file.

The review is complete. The findings file is valid, holds an empty findings list with seven coverage rows, the scratch test directory is deleted, and the working tree is clean apart from the required output file.

Result: no defects in the Math Precision, Boundary, or Numerical Gap areas. The token at src/Pepe2Pepe.sol is a plain OpenZeppelin v5.1.0 ERC20 whose constructor mints a compile-time constant once. There is no division, downcast, fee, scale conversion, external call, payable path, receive or fallback, or bytes decoding anywhere in the source, so the three guides have no formula or boundary to act on beyond the library's own arithmetic.

What I verified concretely:

• Supply constant. The literal evaluates to exactly 10^27, divides by 10^18 to one billion with zero remainder, and matches the manifest's decimals of 18. The aderyn "large numeric literal" lead is the intended supply, not a defect.
• Library arithmetic. Every unchecked block in the vendored ERC20 sits behind the guard that makes it safe, and all five vendored files are byte-identical to the upstream v5.1.0 tag.
• Edge inputs. Scratch Foundry tests exercised transfers of 1 wei, the full supply, supply plus one, and max uint256, a self-transfer of the full balance, allowances at zero, max, and max minus one, allowance larger than balance, and a zero-value transferFrom with zero allowance. Each behaved exactly as the ERC-20 contract specifies, and supply was conserved across many recipients.
• Outside the area. The runtime bytecode contains no DELEGATECALL, CALLCODE, or SELFDESTRUCT, and the ABI's only state-changing entries are the three listed ones. The project's 20-test suite passes with the pinned fuzz seed.

Coverage rows mark all three entry points as holds, plus four invariant rows. Nothing was left unreached.

The findings file is in place at the repository root and is excluded from git by the harness's own rules, as expected. Work is complete.

Outcome. Two new test files are added under test/ and committed. The full suite passes with the verifier's fuzz seed.

Invariant suite. A handler deploys the token so it holds the supply as the launch factory would, then drives it from five owners plus the token contract as a sink. It mirrors every balance and allowance in ghost ledgers and also drives the failure paths: overdraws, overspends, balance-limited delegated spends, zero receiver, zero spender, and a stranger with no allowance, each checked for the exact ERC-6093 error and unchanged state. Invariants cover fixed supply, balances summing to supply, balance and allowance ghost agreement, the token contract never paying out, no leak to unrelated addresses, immutable metadata, and the deployer holding the remainder. I grounded the properties by breaking the allowance mirror in a scratch copy and confirming that only that invariant failed.

Edge suite. Covers the exact supply literal, two deployments in one call, deployer versus origin, ether and unknown calldata rejection, the protected floor's mint and privileged-call lists, zero-amount transferFrom without allowance, owner self-spend needing self-allowance, the allowance one below infinity, infinite allowance still bounded by balance, event shape of transferFrom, stuck tokens being unrecoverable by anyone, bytecode opcode and size checks, and fuzzed conservation, round-trip, split and repeated-spend properties.

Findings. None. The implementation is an unmodified OpenZeppelin v5 ERC-20 with a single constructor mint, and no input I tried produced behaviour that deviates from the ERC-20 and ERC-6093 specification. The findings file at the repository root records an empty list.

Housekeeping. No dependencies were installed, no configuration was touched, and the scratch directory was removed. The commit sits on the detached HEAD the workspace started on.

Nothing further is needed. The review is complete and the tree holds only the findings file.

Outcome: no defects found in the permission model. The findings file at .imd-findings.json carries one informational note and eleven coverage rows, all three listed entry points marked holds.

What was verified

• Access Control. The token has no roles, modifiers, initializer, fallback or receive. The compiled ABI exposes only the standard ERC-20 surface plus the supply constant getter. Twenty-two common admin selectors (mint, pause, blacklist, freeze, burnFrom, seize, upgradeTo, initialize and others) revert whether called by the factory or a stranger, and a holder keeps its balance and transferability afterwards. The deployer cannot pull a holder's funds without an allowance.
• Trust Gap. The vendored OpenZeppelin files are byte-identical to the upstream v5.1.0 tag, fetched and compared with cmp, so no hidden change exists in the sender, update, approve or spend-allowance paths. Supply is minted once to the constructor caller and cannot grow afterwards. The runtime has no DELEGATECALL, CALLCODE or SELFDESTRUCT, checked with the floor's own scan loop.
• Asymmetry. The approve/pull, transfer/transferFrom and mint/burn pairs were diffed. A fuzz harness of 2048 runs per property confirmed that approve writes only the caller's row, transfer debits only the caller, transferFrom succeeds exactly when allowance covers the value, and the sum of balances always equals total supply.

The one note, at info severity. The inherited ERC-20 approve race: a holder lowering a non-zero allowance can be front-run so the spender takes the old amount and the new one. The reproduction gives exact balances (spender ends with 150e18 instead of 50e18). This is standard ERC-20 behaviour, OpenZeppelin v5 removed the helper functions on purpose, and the README already documents the set-to-zero mitigation. It needs no fix and is recorded only so the judge sees the pair was traced.

Leads dismissed. Slither reported nothing. Aderyn's large-numeric-literal lead is the constant-folded supply, exactly 1e27. The Solidity 0.8.26 known-bug list contains nothing this code's constructs can reach.

Limits. The protected launch harness could not be executed here because its Uniswap v4 and forge-std imports and its environment variables are not in this tree, so the launch-flow row rests on tracing the unmodified transfer path. No proof files were written because nothing reached high or critical severity. The scratch tests and build output were removed, so the only new file in the repository is .imd-findings.json.

The review is complete and the findings file is written. Nothing further depends on another result, so there is nothing left to request.

Outcome: the Pepe2Pepe token has no defects. The findings file holds one info-level entry and a six-row coverage record. The working tree is unchanged apart from .imd-findings.json.

What I verified

• All 45 project tests pass, including the 256-run invariant suite with the pinned fuzz seed.
• The five vendored OpenZeppelin files are byte-identical to the upstream v5.1.0 tag by sha256.
• The runtime bytecode contains no CALL, DELEGATECALL, CALLCODE, CREATE or SELFDESTRUCT. Creation and runtime sizes are well under the protocol limits.
• A scratch test deployed the token through CREATE2 from a probe contract with no constructor arguments. The probe held the whole supply and a transfer moved exactly the requested amount.
• The ABI has only the ten plain ERC-20 selectors plus the supply constant. There is no mint, burn, owner, pause, blacklist, proxy or initializer path.
• launch.json uses only schema keys, lowercase addresses, an empty constructorArgs that matches the no-argument constructor, and a totalSupply equal to the constructor's mint.

Specialist findings

Four of the five areas reported nothing. The one finding from the permissions specialist, the standard ERC-20 approve overwrite race, reproduced exactly as stated in a scratch test. I kept it at info severity because it is the behaviour the standard specifies, OpenZeppelin v5 dropped the allowance helpers deliberately, and the README already documents the approve-to-zero mitigation. It needs no code change. The aderyn large-literal lead is a style note only; the literal evaluates to the manifest's supply.

Coverage: all three entry points hold, with three extra invariant rows for the fixed supply, factory deployability and vendored-library integrity.