Implemented SwarmPepes.sol: 1 billion SPEPE, 18 decimals, minted once to the deployer.

Vendored dependencies support offline builds. README.md documents assumptions, deployment, and responsibilities.

Passed with Solidity 0.8.26:

• forge build
• forge test — 18 tests, including fuzz tests
• forge fmt --check

I found no math-precision, boundary or numerical-gap defects in Swarm Pepes (SPEPE). .imd-findings.json holds an empty findings list and a coverage record. All 18 tests in the existing suite pass, and I changed no other files.

What I checked:

• The token itself: src/SwarmPepes.sol is a plain OpenZeppelin v5 ERC20. Its only addition is a constant INITIAL_SUPPLY = 1_000_000_000 * 10 ** 18, which works out to exactly 1e27. The constructor mints that once to the deployer, and decimals are 18, matching the brief.
• transfer / transferFrom:
  • The balance is checked before the unchecked subtraction.
  • Adding to the recipient can't overflow, because all balances together equal the total supply (1e27, far below 2^256).
  • There is no fee, tax or rounding, so the amount sent is exactly the amount received.
  • An allowance is checked before it is reduced, and the maximum allowance stays unlimited, as standard.
• approve: It stores the value as given, with no arithmetic, and rejects zero addresses.
• Launch splits: 1e27 divides evenly by 10,000. So the swarm's 10% (1e26) and any pool share in basis points come out exact, with nothing lost to rounding.
• Supply growth: There is no mint or burn function after the constructor, so the supply can't grow.

Static-analysis lead: The aderyn "large numeric literal" warning at line 8 is about style only; the value is correct.

Coverage: All three entry points (approve, transfer, transferFrom) are marked holds, plus rows for the supply, exact-split and fixed-supply invariants.

Outside my area: The protected launch test imports src/LaunchLiquidity.sol, PoolInitializationGuard and HookFlags, and also uses Uniswap v4-core. None of these are in this tree: src/ has only SwarmPepes.sol, and lib/ has only OpenZeppelin. As written it couldn't compile here, so I didn't run it, and the seed and swap flow is unverified in this review. I assume the verifier supplies those files, but that's worth confirming.

Created launch.json with the exact supply, economics, paired currency, and empty constructor arguments.

Checked manifest constraints and compiled ABI. forge build succeeded; all 18 tests passed. Only launch.json changed outside permitted scratch output.

The review is complete. .imd-findings.json holds an empty findings list and seven coverage rows, and the only change to the tree is that file.

Result: no defects found. The token in src/SwarmPepes.sol is a thirteen-line contract inheriting an unmodified OpenZeppelin v5.0.2 ERC20, with a no-argument constructor that mints the whole supply to the deploying caller once. Every failure mode in the Execution Trace, Periphery and First Principles guides was checked against it and none applies.

What I verified

• Execution Trace. Traced approve, transfer and transferFrom through Context, _transfer, _update and _spendAllowance. Zero sender, zero recipient and zero spender revert. Insufficient balance or allowance reverts with no partial state. The allowance decrement sits in unchecked only after the bound check, and the infinite allowance path is the documented max-uint sentinel. No external calls, callbacks, stale reads or reentry points exist.
• Periphery. The six vendored OpenZeppelin files match upstream v5.0.2 byte for byte by sha256. There is no git submodule, and the build runs with no network.
• First Principles. The supply literal equals exactly 1e27, which the aderyn lead flagged only for size. Deploying through a factory contract leaves the entire supply with the factory. The ABI exposes only the ten standard selectors plus the supply constant. A bytecode scan found no DELEGATECALL, CALLCODE, SELFDESTRUCT, CREATE or CALL opcodes. The contract rejects ether, unknown selectors and empty calldata.
• Launch floor. The protected test could not run here because v4-core and LaunchLiquidity are not in this tree. I reproduced its token-side assertions in a scratch test, since deleted: the ten percent share arrives at the distributor whole, a claim leaves it whole, approve/transferFrom from an arbitrary address moves exact amounts, decimals is 18, and supply stays constant.

Noted, not reported. The standard ERC20 approve-overwrite race exists exactly as in every OpenZeppelin token and is documented in the README. It is a property of the requested standard design rather than a defect in this code, so it is not a finding.

Coverage. All three listed entry points are marked holds, with four additional rows for the supply, admin-surface, vendored-library and launch-flow invariants. Nothing was left unreached.

The review is complete. The findings file is written and valid, the scratch directory is removed, and the working tree is clean.

Result: no defects found in the economics area. The file .imd-findings.json holds an empty findings list and nine coverage rows.

What the token is. A single contract that inherits the unmodified OpenZeppelin v5.0.2 ERC20 and mints the whole supply to the deployer in an argument-free constructor. There is no owner, mint, burn, pause, blacklist, fee, hook, initializer or proxy.

What I verified

• Entry points. All three listed functions trace to stock OpenZeppelin code with no overrides. Each marked holds.
• Supply invariants. The only mint is in the constructor and equals exactly 1,000,000,000 tokens at 18 decimals. Sum of balances equals total supply under fuzzing. Privileged-signature probes from the factory address all revert and leave supply unchanged.
• Launch flows. A scratch Foundry test deployed the token through a CREATE2 factory probe, moved the ten percent swarm share, claimed it, had a manager probe pull the seed via allowance, forwarded the remainder, and ran a trader buy and sell. Every leg moved the exact amount with zero residual allowance, fuzzed across pool shares of 1 to 9000 basis points.
• Dependency integrity. The five vendored OpenZeppelin files are byte-identical to a tagged v5.0.2 git checkout found elsewhere on disk. No submodule is present.
• Existing suite. The project's 18 tests pass.

One row marked unreached. The runtime opcode scan for DELEGATECALL, CALLCODE and SELFDESTRUCT. It is outside the economics area, no scripting runtime was available to scan the bytes, and the protected test already performs that check. The source contains no assembly, delegatecall or selfdestruct.

Static analysis leads. Slither reported nothing. Aderyn's large-numeric-literal note is the supply constant, which matches the manifest supply exactly and is not a defect.

Not reported. The standard ERC-20 approve race and tokens sent to the token's own address are inherent to the standard, documented in the README, and not defects of this implementation.

The review is complete. The findings file is in place at the repository root, the scratch directory is removed, and no source or configuration file was changed.

Result: no defects in the Access Control, Trust Gap or Asymmetry areas. The file .imd-findings.json holds an empty findings list and 11 coverage rows.

What was checked

• Permission model. The token has no owner, roles, modifiers, initializer, proxy, receive or fallback. The compiled ABI exposes exactly three state-changing functions, all unrestricted by design of ERC-20. A bytecode scan found no CALL-family, DELEGATECALL, CALLCODE or SELFDESTRUCT opcodes.
• Entry points. approve, transfer and transferFrom were traced through the vendored OpenZeppelin code. Each writes only the caller's own balance or allowance, from == address(0) reverts even at zero value, and the factory cannot pull a holder's tokens without allowance.
• Constructor and launch flow. The argument-free constructor mints exactly 1e27 minor units once to msg.sender, which is the factory under CREATE2. With no transfer rules, the swarm share, a claim and pool flows move exact amounts. A scratch test confirmed this plus the revert of unknown selectors and any ETH sent to the token.
• Dependency integrity. All five vendored OpenZeppelin files hash byte-identical to upstream v5.0.2 and are tracked as ordinary git files, not a submodule.
• Static analysis leads. Slither reported nothing. The aderyn large-literal note is style only, and the existing test asserts the supply equals one billion tokens.

Trust assumption recorded, not a defect. The deployer holds the whole supply at construction. The token gives it no power beyond an ordinary holder's, so distribution correctness rests on the factory and launch policy.

Not reported as findings. The standard ERC-20 approve replacement race is inherent to the requested design and already documented in the README. The existing 18-test suite passes.

Added failure-path and fuzz tests plus three multi-actor invariants covering supply, balances, and allowances.

Offline verification passed: forge build and forge test, with 32 tests and 32,768 invariant calls.

No defects found. Only files under test/ were added.

The review is complete. The findings file holds an empty list and nine coverage rows, and the tree is otherwise unchanged. Nothing further is needed.

Outcome: no defects found. The five specialists reported nothing, and I reproduced nothing against the code either. .imd-findings.json is written with {"findings": []} and a coverage record answering all three entry points plus five invariant rows.

What the token is. src/SwarmPepes.sol is a 12-line contract: it inherits OpenZeppelin ERC20 and mints the fixed supply to the deployer in the constructor. It adds no functions of its own.

What I verified.

• The vendored OpenZeppelin files are byte-identical to upstream v5.0.2. I fetched the five files and ran a recursive diff, which was empty. No git submodule exists.
• A scratch test deployed the token from a contract and confirmed the supply equals the manifest's 1e27, the deployer holds all of it, decimals are 18, and name and symbol match.
• An opcode scan of the compiled runtime found no DELEGATECALL, CALLCODE, SELFDESTRUCT, or any external call. There is no fallback or receive, and mint and burn selectors revert.
• The project's own suite passes: 32 tests including a 256-run invariant campaign with no reverts.
• The manifest's initialPrice equals the exact integer square root of the cap-to-supply ratio scaled by 2^96, so the provenance figure is correct.

Static-analysis lead dropped. Aderyn's large-numeric-literal note is a style remark. The literal uses digit separators and evaluates to exactly the manifest supply.

Trust assumptions. There are none: no owner, no roles, no pause, no upgrade path. The standard ERC-20 approve front-running property applies, as it does to every OpenZeppelin v5 token, and is not a defect in this code.